“What the hell do I ask the candidate?”
Probably the most common and immediate problem that engineers have when they start interviewing candidates is, “What the hell do I ask them?”
I’ve read innumerable books, talked to dozens of hiring managers/recruiters/fellow engineers, and tested a whole bunch of my own questions in candidate interviews. I’ve come to believe there are only a handful of questions you need to assess an engineering candidate thoroughly.
Question: What happens when you type a URL into your browser and hit enter?
This is an age-old question, and it can be quite effective for some roles (backend engineering and devops, especially). The usefulness of the question is that the answer can go in any number of directions and depth. I once interviewed a candidate who spent twenty minutes answering before I stopped him–and he hadn’t yet got outside of the local machine!
Your typical candidate will usually start their answer with DNS and move on to web servers, which is an excellent starting point for anyone working on webapps. The real answer starts when you begin asking questions, though. For example, let’s say your candidate is talking about web servers: ask them how the answer changes with SSL enabled/disabled, how HTTP keepalives play into it, and what the impact of a CDN or caching layer would have on the request/response. You can use this question as a jumping-off point to discuss when things go wrong and their ability to troubleshoot, as well: what might be going wrong if we’re seeing intermittent HTTP 500 errors? Where should we look?
Be aware that some candidates have studied the question, given how common it is. There is even a Github repo that attempts to answer the entire question in its entirety, so be sure to dig into the candidate’s answer.
Question: Thinking back on everything you’ve done in your career, what stands out as the most significant? Tell me about it.
Inspired by Lou Adler, Hire With Your Head
This is a variation on “tell me about a project,” but sets you up for better followup questions. If a candidate struggles to think of an answer here, chances are good that you have a dud candidate.
The candidate will usually think for a bit, then explain the project in whatever way comes to mind. When you sense they’ve answered it and are struggling for more words, it’s time to start asking your followup questions.
Pick and choose any/all of these as you see fit:
- What were some of the big challenges in the project that you had to work through?
- What impact did the project have on your team and company?
- How did you get this project? Were you chosen, or did you volunteer? Why you? What was your role in the project?
- How long did the project take to complete?
- What skills were necessary to get the project done? Did you learn any new skills?
- Give me some examples of you coaching or helping others during the project.
- Did you have to influence or persuade anyone to change their opinion during the project? Tell me about that.
- What was the biggest interpersonal conflict you had during the project? How did you resolve it?
- What did you like the most about the project? The least?
- Personally-speaking, how did you change or grow as a result of the project?
- In retrospect, what would you have done differently?
The follow-up questions allow you focus on the facts and judge the candidate’s accomplishments on merit, rather than their ability to tell a story.
Asking these series of questions a few times for multiple accomplishments is a great way to determine talent and growth of a candidate. If the candidate can only think of one accomplishment to talk about, or if the other accomplishments are a little weak, be wary.
Question: How would you solve X?
Use an actual, real problem. Try to go for open-ended problems that don’t necessarily have a right/wrong answer, as you want to see how they approach problems and reason about them. Avoid any problems that require leaps-of-insight or any knowledge about the specifics of your environment. When in doubt, pick a different question.
Some example questions:
- It’s important to us to ship a new feature by $somedate. From an engineering perspective, how would you go about ensuring we hit that deadline?
- Here is an architecture diagram of a new app we’re working on. Do you see any potential issues, risk factors, or ways to improve it?
- We’re considering ways to improve our code review process. How would you design a code review process for a quickly-growing, multi-disciplinary team?
- We’re considering a migration from AWS to GCP. What would be your questions about such a move? What should we be concerned with? How would you handle the migration without any downtime?
- We’re considering breaking our monolith into microservices. How would you approach that problem?