Interview questions to ask software engineer candidates

Eight questions to ask software engineer candidates

1. What part of your current codebase would you change if you had a free week, and why that part?
2. Walk me through the architecture of something you built. Where would it break first under 10x load?
3. Tell me about the worst bug you have debugged. How did you find it?
4. When did you last choose the boring, obvious solution over a better one?
5. How do you handle a code review comment you disagree with?
6. What does your testing look like in practice, not in principle?
7. Tell me about a time you had to work in code you did not understand.
8. What is something about your current stack that frustrates you?

Ownership: what did they actually build

Engineers interview well in the plural. Your job is to find the singular. Ask about the architecture of something they built, then narrow: which part did you design, which part did someone else design, what did you argue about. Strong candidates move to specifics naturally and are comfortable saying “that part was someone else's.” Candidates who stay abstract through three follow-ups usually contributed less than the story implies.

Debugging: the most underrated question in engineering interviews

“Tell me about the worst bug you have debugged” is unusually hard to fake, because real debugging stories have texture: the wrong hypothesis held for two days, the log line that did not make sense, the moment the cause became obvious in hindsight. Listen for method rather than heroics — did they bisect, reproduce, add instrumentation, or did they guess until it worked? A candidate who describes narrowing a problem systematically is describing most of the job.

Judgement: when did they not build the clever thing

• “When did you last choose the boring solution?” Senior engineers have many of these stories and tell them without embarrassment. The absence of any such story is a flag at senior level, where restraint matters more than capability.
• “Where would your system break first under 10x load?” You are checking whether they have thought about their own design's limits. “It would be fine” is a worse answer than a specific wrong one.
• “What frustrates you about your current stack?” Specific, technical frustrations are a good sign. Generic complaints about legacy code are not — everything becomes legacy code.

Collaboration: code review is the honest question

“How do you handle a review comment you disagree with?” is more revealing than any teamwork question, because every engineer has lived it recently. Good answers involve moving the disagreement somewhere with more bandwidth than a comment thread, and distinguishing between preferences and problems. Candidates who describe either always deferring or never deferring are both telling you something you want to know.

What to adjust by level

• Junior: weight the debugging and learning questions. Ask about something they did not understand and how they got unstuck. Do not expect architecture answers; see interview questions for junior developers.
• Mid: weight ownership. The gap between mid and senior usually shows up in whether they can describe trade-offs they chose rather than tasks they completed.
• Senior and above: weight restraint, influence and the 10x-load question. See interview questions for senior engineer candidates.

How to follow up when an answer is too smooth

Engineers who interview often have a polished version of every story. The way past it is to ask for the thing that would only be known by someone who was there: the error message, the name of the service that failed, how long the incident lasted, who else was in the room. These details are not themselves important — you are not checking facts — but the ability to produce them instantly distinguishes lived experience from a well-constructed summary. A candidate who says “I do not remember the exact error, but it was a connection pool exhaustion under retry storms” is far more convincing than one whose story has no texture at all.

Common mistakes interviewers make with engineers

• Testing for your stack rather than for engineering. Someone who has never used your framework can learn it in a fortnight. Someone who cannot reason about state, failure or data flow cannot learn that in a fortnight.
• Letting the candidate drive the whole hour. Strong communicators can fill sixty minutes with context. Interrupt politely and ask for the specific decision.
• Confusing confidence with competence. The correlation is weaker than most interviewers assume, and it runs against quieter candidates who are often better engineers.
• Scoring the technology rather than the judgement. “They used Kafka” is not a finding. “They chose Kafka over a database queue and could explain what they gave up” is.
• Asking a question you cannot score. If you would not be able to tell a 3 from a 4 on the answer, the question is decoration.

Pair these with a work sample, not a quiz

None of this replaces watching someone work. It complements it. A short, realistic exercise — reading unfamiliar code, extending something small, debugging a seeded failure — carries more signal than an algorithm puzzle for most roles. See how to test coding skills without LeetCode and what to look for in a coding interview.

Where Interviewer Mode fits

Disclosure: we make CoPilot Interview, which includes Interviewer Mode for the hiring side and a real-time assistant used by candidates. We have an interest in you using the first, and our view of the second is that interviews should be designed to measure something an assistant cannot fake. Weigh the advice below accordingly.

Frequently asked questions

What should I ask a software engineer in an interview?

Ask about a system they owned and where it would break under load, the worst bug they have debugged and how they found it, a time they chose the boring solution, and how they handle a code review comment they disagree with. These reveal judgement and ownership, which the coding exercise does not.

What is the best question to ask a software engineer candidate?

“What part of your current codebase would you change if you had a free week, and why that part?” It shows how they think about systems they did not design, what they consider important, and whether they can criticise constructively — all in one answer.

How do I interview an engineer more senior than me?

Ask them to explain a decision rather than a technology, and keep asking why until you reach the trade-off. You do not need to know the domain to evaluate whether someone can explain a choice clearly, name what they gave up, and describe what would have changed their mind.

Should I ask algorithm questions in an engineering interview?

Only if the role involves that work. For most product engineering roles a realistic exercise — reading unfamiliar code, extending it, debugging a seeded failure — predicts performance better and loses fewer good candidates who do not practise puzzles.