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

In my current role I had what I consider the best interview I have had to date. I had a brief non technical video interview with the software director. Then I was assigned a programming task, essentially to create a site focused on a specific task using a given set of technologies. Once done, I sent the interviewer the url to the site and a link to the code on git. The next day I had a code review and video interview with the original director and several Sr. engineers to review my code and answer relatively technical questions on my design decisions and code.

I thought this was perfect, they did not waste much time on the original interview, essentially just determined I was not insane and would be an ok fit for the team. Then via the assignment they were able to see me build something from start to deployment including database development and server deployment. One of the required technologies was a javascript framework I had never used before, they knew that but I spent 8 hours (I really wanted the job) reading a book on it before starting the project and they appreciated it. I had a couple of options on server side stack and they were able to observe and question my decisions. In the code review they were able to see how I handled criticism and reacted to stress.

Whole process from scheduling the first interview to the job offer took 4 days. No white boarding, no obscure technical jargon. They met me (virtually), learned if I could code to their standards and made a decision. In my mind it was great. Via the same process they interviewed someone else I recommend and very professionally and politely turned them down, someone who in my mind was a pretty solid engineer but he just lacked the specific skill set they wanted. While creating the requested application, he knew he was not going to get the offer, which is great as you as a developer are then able to determine for yourself if you are a good fit for the role. No mess no fuss.

I've considered this approach, but I worry that it consumes too much of the candidate's time. That it ends up favoring people who have the time and the financial freedom to do a full day of unpaid work.

This is a valid criticism; however, they did not specify I had to turn it in the next day, I could have kept it over the weekend and not taken a day off of work. Several people kept it over a weekend with no penalty. I also could have worked on it at night after work. I definitely preferred this option as opposed to having to take a full day off for an in person interview and another for the follow up. I only took an hour off for the first interview as it was at 5 and I just ran home and threw on a suit jacket and a couple hours for the final interview as it was close to the same time.

If I had already worked in the js stack they asked me to use the entire project build would have been 5 or 6 hours and that's only because I really wanted to impress, I could have knocked it out once my kids went to sleep.

But as in everything it depends on the person and their life circumstances, we all have different things going on.

- Clear timelines on the interviewing process. Some companies show no respect for your time. Telling me to pop by the office to "chat" at a specific time and then telling me your agenda for a 4 round technical interview on the spot is not going to inspire any sort of trust.

- Ask me questions that actually apply to the job. If I'm building an iPhone app, please don't ask me to run through a gauntlet of white-boarding/coding challenges that don't apply to the job. Have me walk through something I've built or talk about how I would build a theoretical iPhone app. Most of us aren't building software for self driving cars so please quit acting like we are.

- If I'm writing code or solving problems, give me an ideal scenario to do my best. Let me use my own computer (not one that you just handed me setup to your preferences.) Potentially let me do it at home (where I am comfortable and not in an unfamiliar place.)

- Gauge confidence on the technical stack

- Don't say we'll be in touch shortly and then ghost. You can say goodbye to someone without false promises. I'm likely to tell fellow developers about how the process went.

- Have people with decent social skills interview

- If I ask questions like, "What should I be prepared for?" please give me a basic agenda or guidance. It'll go much better for both of us.

No whiteboard code, no algorithms questions. If you want them to code, let them do it on their own time in a comfortable environment. The industry needs to stop the bullshit leetcode meme that millenials are propagating.