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

I guess it's also an issue of what you want. Are you fine with just any job, or do you want something specific, or something challenging? Do you want to be the smartest person in the room or do you want competent co-workers?

In my experience, these sort of tests do often seem to be used by the more interesting, more competent kind of companies. The first company where I encountered this (14 years ago), had only highly competent developers, many of them committers to various open source projects. About the recent one where I wrote a customised version of A* (because of the presence of wormholes, which made it not remotely rote for me or for most people, I'd expect), I of course don't know how it would have turned out had I taken the job, but if they select for this kind of thinking, I see that as a very positive signal about the kind of work they do and the kind of people they hire.

At companies that didn't have this kind of test, the quality of their developers was a lot more hit-and-miss.

At least for permanent employees; I've never encountered this for freelancers.

> I am yet to hear any story of any candidate that was interested in the position but walked away due to the way that the process is conducted.

Thank you for making my point. Why would you ever hear about it?

This is the "British Rails" fallacy in action. (A long time ago, the British Rail organization had heard complaints that residents of a local community weren't satisfied with the once-daily train service it received. Its response was there was no need for a second train, because at the times considered, no one was standing on the platform waiting to board it).

Nice coconut earmuffs.

These were just example questions, for example pair programming might be irrelevant, if it's not a significant part of team culture. I admit some questions here are tricky. It's hard to predict how candidate will interact with the whole team: maybe they're very respectful to me, but they will look down on junior developers?

Here are a few things I do that help me better predict whether candidate will fit the team:

- ask candidate to do coding task at home and later discuss the solution during face-to-face interview. While discussing the solution and suggesting improvements I can see how candidate reacts to feedback, whether they can explain why they came up wit this particular implementation, what do they say when I suggest an idea for refactoring etc.

- I like having another team member with me during interview. That person is an observer and they help me review candidate's performance (e.g. it happened that I had an impression that candidate did quite well, but my observer told me that I was often helping candidate with their task, which I had not noticed)

- lunch with candidate might be helpful. I take 2 team members with me and 4 of us grab some food out of the office. This helps candidate meet potential teammates and talk in a more relaxing atmosphere, so both sides can see how they feel about each other.

- one more thing I do is during initial phone call when I tell candidate about company, at first I give a very brief introduction, then before I say more, I ask whether candidate has any questions. This gives me a lot of insight: some candidates ask advanced questions, some ask very basic ("so what does your company do?" happened a few times!), some focus on product, some ask whether they'll be able to learn a particular skill. Some candidates don't have any questions, which is usually a red flag. These questions themselves are not enough to decide that candidate won't fit, but they're helpful.

- I ask candidates what they would like in their new job to be different than in the previous one. One candidate tells me they want to focus on one particular JS framework. If in my company we chose libraries and languages on per-project basis, she might not like it. Counter example: candidate that wants to learn multiple new frameworks might not feel well in a place that is conservative when it comes to introducing new libraries

Nah, you're right. It was unclear.

Ideal, though unrealistic, would look like this.

Phone call from interested employer to ask a few questions back and forth. If things seem good set up an interview.

At interview, show potential employee where they will be working, what they would work on, then sit at a table for the interview. Potential hire knows their ability level and is honest with the employer about it. Employer knows exactly what they need in the hire and is honest with them about it. They come to a mutual decision about whether they are a good fit for employment there.

Interview done, and both parties know what to expect from each other afterwards.