What’s your experience with coding challenges, technical tests, tasks? (e.g. codility, hackerrank or various custom “homeworks”) as an applicant and as an evaluator as well?

As a interviee: I get nervous when doing timed tests with people watching me. Every mistake suddenly seems magnified hundred-fold. It's definitely not representative of my true capability - like you said, the vast majority of the time you are in a environment where you can reference docs and think at your own pace.

As a interviewer: I don't have much experience here - I've only interviewed one person. But it was a interesting experience being on the other side. You give out a relatively simple question to a person with decades of experience and they can't even being to solve it. But we have all been there - I'm not only looking for a solution (although that would be nice), I'm looking for how they approach the problem. In this instance they got angry, complained about it being a unfair question, and left without shaking my boss's hand. No go.

Do you think it properly evaluates if an applicant is a fit for the job?

There's no golden bullet for properly evaluating a candidate - it depends on how you use it. Ideally you would ask questions directly relevant to the job at hand. If the questions are tricky theoretical ones then you would ask just to see the thought process, not necessarily for a solution.

What is a viable alternative that works for you as a hiring manager?

I haven't tried it, but some companies invite you to their office and pay you to work a full/half day like a real employee. That would be nice as a employee and as a employer it would give you a much better idea of how the employee performs than theoretical CS questions.

Let me approach this from the interviewer/employer's point of view.

You advertise a web programming position and get dozens or hundreds of applicants. Everyone's claiming to be just awesome in their resumes. But when you start interviewing people, many of them aren't remotely qualified. We don't have time to interview everybody to such a degree that we can be absolutely sure we have an accurate picture of their capabilities--if we had that much free time we wouldn't need to hire anybody.

So we need to streamline the process somehow. But where do we set the bar? There are two kinds of errors we can make:

1. Pass on a qualified candidate (unfortunate but not a big deal)
2. Hire an unsuitable candidate (potentially disastrous, especially in a small business)

This is the situation potential employers find themselves in. And the rational thing to do is filter out the weak candidates as quickly and cheaply as we can, even if it means potentially culling an excellent candidate. Hence, little tests and coding exams. Are they perfect? Hell no. But they do thin the list of candidates substantially.

From there, we try to gain the most information about the remaining candidates for the least cost. So we start with short phone interviews. Then in-person interviews. Perhaps followed by another in-person interview. And finally a small paid project.

If it helps, we focus on asking questions that are applicable to the position--we don't ask candidates to do puzzles or big O notation.

I don't know of a better way to do it but I can totally appreciate how challenging and tedious this process can be for applicants who are having trouble getting hired.

If I can offer a tip to people trying to get a job: be well prepared for the interview. It's shocking how bad people do in interviews. Yes, people get nervous. But even taking that into account, most people are shockingly unprepared. Get a friend to ask you questions. Do little coding challenges. Do mock interviews with a friend if you can't get your nerves under control. Prepare and rehearse answers to likely questions beforehand. Give the interviewer a reason to advance you to the next level.

My experience is that if you skip coding challenges, about half of the candidates that otherwise seem fit for the job will not be able to program effectively. Unfortunately most of these will also not be able to learn it within an acceptable time span, even if they feel motivated.

The point of a coding challenge is not to find out if the candidate solves the task in exactly the way the interviewer expects. There are often many different approaches and solutions.

The point is not even to find out if the canditate can solve the task at all.

The point is to give the candidate a chance to show how she approaches a programming task. The solution itself is not important.