Many founders and HR heads have to hire engineers without being engineers. It feels like judging a surgeon without medical training. But most of what makes an engineer good in a team is visible to anyone who asks the right questions and listens carefully. You need help with one part only: the code itself.
Split the interview in two
There are two things to find out. Can this person write good software? And will this person be good to work with, here? The first needs a technical reviewer. The second is yours, and it matters just as much. Many engineers who fail in a job fail on the second.
Borrow technical judgment for the code
If you have a senior engineer on your team, they do this part. If you do not, borrow one: an adviser, a trusted engineer from another company, an investor’s technical partner, or a paid reviewer for an hour.
Give the reviewer a clear task. Ask them to do one of two things:
- A walk-through. The candidate shows something they built and explains the choices they made. The reviewer asks why.
- A small, realistic exercise. An hour of work close to what the job involves, followed by a conversation about it.
Then ask the reviewer for three answers in writing: would you be happy to work with this person’s code, at what level are they, and what worries you. A plain “yes, mid-level, no worries” is worth more than a score out of ten.
Five questions a non-engineer can ask
You do not need to understand the technical details of the answers. You need to listen to how the person answers.
- “Explain the last thing you built as if I were a customer.” Good engineers can say what a thing does and who it is for. If the answer is all tools and no purpose, they may not have known the purpose.
- “What went wrong on that project, and what did you do?” Everyone has a story. You want one with detail and with their own part in it, including mistakes.
- “Tell me about a time you disagreed with a decision.” Listen for how they raised it and what happened after. You are hiring someone who will disagree with you too.
- “What did you do yourself, and what did the team do?” Ask this more than once. “We” hides a lot. A strong candidate is precise about their own part and generous about others.
- “What would you want to know before you started here?” The questions a candidate asks show how they think about work. Questions about the product, the users and how decisions are made are a good sign.
What to listen for
Clear over clever. If a candidate cannot explain their work in simple words, your team will have the same trouble with them every day.
Specifics. Real experience comes with details: what broke, how long it took, who was upset. Vague answers often mean the person was near the work, not doing it.
“I don’t know.” An engineer who says this easily, and then says how they would find out, is safer than one who has an answer for everything.
Interest in the user. Especially in a small company, you want engineers who care whether the thing they build is used.
Three common mistakes
Hiring on the brand of the last employer. A big name tells you the person passed that company’s interview once. It does not tell you what they did there, or whether they can work without the support a big company provides.
Hiring on confidence. Confident speakers interview well. Some of the best engineers are quiet and careful. The work sample protects you here, which is why it should never be skipped.
Testing puzzles instead of work. Brain-teasers and trick questions measure practice at brain-teasers. Use tasks that look like the job.
Putting it together
After the interviews, put the two halves side by side. The reviewer’s three answers on the code. Your notes on the five questions. Agree in advance what you will do when they disagree. A useful rule: a clear “no” from either side is a no. Strong code does not make up for someone the team cannot work with, and a pleasant person who cannot do the work will not stay pleasant for long.
Write your notes before you speak to the reviewer, so neither of you is swayed by the other. It takes ten minutes and makes the decision much easier to trust.
