I have interviewed over 100 candidates for developer positions over the last decade. In that time, there has been one consistant refrain on twitter: “Interviewing is broken”. And as someone who has been on the other side of the interview, I agree. I’ve evolved my developer interview questions with this in mind.
I’ll note that this is what I’m using now and will likely evolve. My questions aren’t tricks, they aren’t academic, and they don’t necessarily have right and wrong answers. My goal with them is to start some conversations and try to learn how a candidate thinks and reacts.
I’m a bit worried that putting these out here will “ruin” them, but I also think part of what is broken about interviewing is the idea that things need to be a surprise and we need to see how people think on their feet. The majority of the time, this isn’t how we work so why interview with that in mind?
Most interviews, I use just two questions as my base. For more experienced people, I have a third I use as well if I’m trying to understand if they are truly senior. I also am generally looking for people who will work throughout the stack, even if they have a specialty. I also don’t expect candidates to be experts at the entire stack. My developer interview questions are thus general and not generally language specific.
How do you ensure you write quality code?
What I’m looking for here is that they have a definition of quality and they put in some sort of process to make sure it happens. I’m trying to weed out people who won’t write tests, while also learning if someone is going to be overly cocky or has lone wolf tendencies.
Some of the best responses to this are questions along the lines of “How should I define quality code” as it shows they don’t just rush to solutions, they try to define the problem better.
I usually end up having follow up questions here depending on how they answer. If they mention automated tests, I might ask how they decide what should be a unit test and what should be a functional test. If they mention code review, I might ask what are the big things you look for when doing code review.
Hypothetical situation: The CEO says the homepage is slow
For this one, I put on my old Simulation Director hat from Model UN and we go through a hypothetical situation where you get an email from the CEO saying the homepage seems slow and asking you to look into it. Totally hypothetical, no one has ever gotten this email at any job ever.
I’m trying to see how people approach being given minimal information and needing to debug. I’m trying to see if they look for tools, such as asking me what metrics they have available. I want to know if they can identify backend performance issues vs. front end performance issues.
This question goes in a different direction every time as I tend to follow the path the candidate leads me on. Thankfully, I’ve written and encountered a lot of slow code in my life, so I am able to go in many different directions.
In this question, I might ask them for ideas for how they would fix some issue. I might see how familiar they are with concepts like RUM, Server Push, and using EXPLAIN in sql.
*Programming Language You know* has changed a lot, what’s your favorite new feature?
This is my experienced developer question. I’m trying to make sure they stay current and continue to learn. I’ll follow up often with “What do you like about it” and then I’ll ask them to explain why it is better than some older alternative and then I’ll ask them how they would explain it to a more junior colleague.
I always pick the language that their resume seems to most emphasize and I only use this for people who have been coding in it for at least 7 years. I’m hoping to see someone that stays current, that has opinions, and can share them.
The candidates I am usually looking for are people who like to learn, people who can debug, and people who aim for greatness, but know that often perfect is the enemy of complete. I hope my developer interview questions help me find them and I hope they want to work with me after the conversation. I hope to always work at places that pass the Jorbin Test so people will want to work with me.
Do you think my questions could be better? Do you see flaws in them? I would love to hear your feedback so I can itterate. To paraphrase Akin’s Third Law:
Interviewing is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.