We have always complained about the developer interview process being broken. According to you, what does an ideal process look like?
Ask HN: What should an ideal developer interview process look like?
1–10 of 289 posts
Re: Ask HN: What should an ideal developer interview process look like?
#2[deleted]
Re: Ask HN: What should an ideal developer interview process look like?
#3Re: Ask HN: What should an ideal developer interview process look like?
#4That depends on the needs of the company doing the hiring.
Re: Ask HN: What should an ideal developer interview process look like?
#5I've often thought about this, and based on my own experiences this is the process I would like:
1. Test language-specific knowledge - it's not a bad thing to not know all the small quirks or details of a language since they're generally not too useful, but when someone does know them it tends to be a good sign that they really enjoy coding and learning. And of course there is a certain minimum amount of knowledge that should be required - listing Java as "proficient" on your resume while not knowing the difference between abstract classes and interfaces might indicate a problem.
2. Design question - just a simple toy problem like "how would you design the book management system for a library?". It's easy to use such a problem to probe into some different aspects of programming like concurrency and databases, just to see how much the person knows.
3. A not-crazy-hard algorithms questions - people often say algo questions are irrelevant to actual work, and I agree with that. But I think algorithms are really a core part of the CS curriculum at every school, so getting completely stuck on a medium-difficulty algorithm question should raise some flags.
4. Resume-specific things - it's always nice for an interviewer to show that they've actually read your resume, and it can be a good way to convey some strengths that aren't otherwise evident.
I guess my philosophy is to interview in a way that can test the depth of a candidate's knowledge while not being obnoxiously tedious or memorization-focused. i.e. someone who has written a lot of production code should do better in an interview than someone who's just memorized every problem in Cracking the Coding Interview. So, ideally with the screening round clearing the first part (language-specific knowledge), and then 2 or 3 subsequent interviews that cover design and algos.
Re: Ask HN: What should an ideal developer interview process look like?
#6It should be clear about what they're looking for, should be collaborative (I want to see if I can work with them), it should be respectful (ending it early for not a good fit is not a good reason), they should allow for you to talk to your strengths and not let it be a we are pushing you to failure.
Re: Ask HN: What should an ideal developer interview process look like?
#7I like asking candidates to give me a code review on a pull request. Because of IP concerns, I normally do this with an OSS project I’m involved with.
Sure, they don’t know the codebase, but they won’t know the codebase that they’ll be working on in a month if hired either. I want to see how they think about creating software and whether they notice potential defects or tricky areas.
Re: Ask HN: What should an ideal developer interview process look like?
#8I like asking candidates to give me a code review on a pull request. Because of IP concerns, I normally do this with an OSS project I’m involved with. Sure, they don’t know the codebase, but they won’t know the codebase that they’ll be working on in a month if hired either. I want to see how they think about creating software and whether they notice potential defects or tricky areas.
How long do you expect them to spend on this?
Re: Ask HN: What should an ideal developer interview process look like?
#9I have had good success with an assignment based interview process. I have written about it in length here - https://abhyrama.com/2018/11/17/startup-hiring/.
Re: Ask HN: What should an ideal developer interview process look like?
#10Most interviews have asymmetric costs. There’s a potential payoff for both parties, but costs are higher for the interviewee (time off, prep, work done).
I recommend trying to make the cost/benefit more symmetric. One way of doing this, is offering compensation for real work. Essentially, hire interviewees to do a small amount of useful (a day?) and evaluate them based on that.
This isn’t going to work for all interviewees, but where possible it feels like a better way of doing things to me.