Ask HN: What should an ideal developer interview process look like?

You're right. We ask fizzbuzz simply because it eliminates a shockingly high percentage of applicants. We then ask more challenging and open ended questions to evaluate actual competence if they get that question. Fizzbuzz is there as a shibboleth of sorts. But I don't see it as a waste of time even for qualified candidates. For many qualified applicants, getting them to relax and speak naturally is the greatest challenge. Starting with a softball question helps eliminate some of the natural interview anxiety and lets us see how they really communicate. Then once in a while, it highlights the really arrogant pricks who think it's beneath them, which is another category of candidate we want to filter out.

This is what I am wondering. The process at my company is a personal interview, coding challenge, then technical interview.

So essentially about 4 hours of time. What makes this different from a company that wants 4 interviews from different managers, which likely takes up more time plus all of it being fixed time slots, versus having one hour of work that you can work on at your own pace?

Yes. It really is. A couple weeks ago I interviewed a self-described C# expert who claimed to know everything about C# but couldn't even begin to describe the difference between methods and fields and properties, and did not seem aware that methods have return types. I'm not sure he had ever written a line of real code in C#, or any other language for that matter. This was a recent CS grad from a reasonable quality engineering school, so I'm not sure how he even got through college.

And for the record, I try to interview people on their strengths, giving them the opportunity to show off what they know about the area where their greatest interest or experience lies. A shocking percentage of people (>50%) nevertheless fail to demonstrate even basic knowledge of syntax or language features in the language of their own choice. This is without even considering actual workplace skills like git, PR review, tickets, etc. as discussed above.

I find the move to take home tests extremely unfair. Anyone with dependents will typically need to block out most of a day of a weekend, or risk doing it in intervals through their week.

Got a decent CV? Good luck trying to juggle applying for more than 2 interesting opportunities at once.

We mostly hire full stack web devs. IMO It's impossible to really test the abilities of each candidate across the changing landscape of front end, back end, DB & devops tech within an interview process that doesn't use a vast amount of time for everyone.

Instead, we don't whiteboard or code at all in our process at the moment, and try and get it all done in a face to face hour or two by:

* Taking their experience at face value. Examples: If they have been coding for a couple of years, don't waste everyone's time with fizzbuzz. Assume they will be able to adapt to our source control system, if they have been using a different one.

* Insisting on real world examples when asking competency questions.

* Asking generic questions about code, such as "What is clean code?", "what should you take into account for password security for a web app?", and looking for their ability to communicate as much as their actual answer.

* Looking for areas of strength and weakness to compare across candidates, rather than trying to catch them out.

* Scoring highly for enthusiasm, flexibility and a willingness to learn over pure technical knowledge.

I appreciate this approach wouldn't work for all organisations but we've done really well out of it.

In theory there shouldn’t be any, assuming it’s limited to an hour, both in description and in reality.

In practice there’s a pervasive phenomenon called asymmetry of effort. The hiring manager may crib a task set either from a perfunctory google search or their own body part. The sum total of time spent on their part is often five minutes, including coming up with the problem and their review of your code.

This follows no industry standard, and I can count multiple experiences where they were too inept to “grade” the homework assignment, thinking it didn’t work when it did, or that the problem set was impossible.

The reason senior engineers in particular turn down homeworks is because they’ve been burned by them before, and the average hiring engineer tends to know less than they do (but as the hiring manager, can’t assess it, mistaking competence for arrogance or ineptitude).

When a company is not willing to invest the same amount of time to interview as they ask of the candidate, it’s a strong signal of how serious they are as a quality employer.

When job hunting as a senior, hearing about take homes (esp. early stage ones) is the young person’s dating equivalent of considering a relationship with someone divorced twice and a felony. You just get conditioned to pass up kissing frogs.