Insight
Technical Interviews That Don't Lose Great Engineers
The interview is part of the offer
Engineers judge your company by your interview long before they judge it by your codebase. A loop that respects their time and tests real work reads as a team that has its act together. A loop built on whiteboard trivia and week-long take-homes reads as a team that doesn’t, and the best candidates, the ones with options, act on that signal.
Having sat on both sides of the technical interview, first as a software developer and now screening engineers every week, I see the same design mistakes come up constantly. Most are fixable without adding a single stage.
Test the job, not the puzzle
The goal is prediction: will this person do the actual work well? So the exercise should look like the actual work. If the role is building and evolving services, have them reason about a service, extend a small codebase, review a realistic pull request, debug something genuinely broken. Inverting a binary tree under time pressure predicts almost nothing about that, and senior engineers know it.
A useful test for every exercise: could a strong performer in this role six months from now do this comfortably? If not, you’re selecting for interview practice, not engineering ability.
Respect the candidate’s time, visibly
- Cap take-homes at two to three hours, say so, and mean it. Better still, make them optional against a live pairing session. Strong candidates with busy jobs will often take the live option, and you’ll learn more watching them think.
- One technical deep-dive, done well, beats three shallow ones. Repeated coverage doesn’t add signal; it adds attrition.
- Always pay it back. Whatever they built or discussed, give substantive feedback, both directions. Engineers remember the companies that did.
Structure beats vibes
Unstructured technical chats feel rigorous and aren’t. The interviewer’s favourite topics become the bar, and two candidates end up measured against different tests. Structure is straightforward: agreed dimensions (say, problem decomposition, code quality, communication, judgement under ambiguity), a shared scoring rubric, and calibration between interviewers so a “strong yes” means the same thing across the loop.
Structure also makes the process defensible and fair: the loop measures the work, not the candidate’s resemblance to the current team.
Let them see the real team
Somewhere in the loop, candidates should meet the engineers they’d actually work with and hear honest answers about the stack, the debt, the roadmap and the on-call reality. Polished pitches lose to candid conversations every time. The candidates you most want are precisely the ones weighing several offers, and candour is a differentiator that costs nothing.
Decide like you measured
A structured loop is wasted if the debrief is a mood. Collect scores before discussion (anchoring is real), weigh the dimensions you agreed up front, and decide in the room. “Let’s see a few more people” after a strong loop is how teams lose their best candidate of the quarter to a company that simply said yes.
What this looks like from our side
We technically screen every candidate ourselves before they reach a client: real conversations about real work, run by people who have done the job. It’s why the shortlists are short. If you want help pressure-testing your loop, or you’d rather start from a screened shortlist, see how we work or browse the roles we’re running. And if you’re rebuilding your process from scratch, our guide to hiring your first engineers covers the ground before the interview.