Software engineer interview questions for the round before the code
Start with what this page isn't. For engineers, the code is the assessment (a take-home, a pairing session or a structured technical interview) and no recorded answer substitutes for it. What a recorded round is good for is the thing a take-home never shows and a CV can't: how someone explains a technical decision to a person who wasn't there, what they do when they disagree with a reviewer, and whether they can say they don't know. On a pipeline of three hundred junior applicants, that's also the cheapest way to protect reviewer time.
What the job actually involves
An engineer turns ambiguous requirements into working software and then keeps it working. Writing new code is a smaller share of the week than people outside the role expect. Most of it is reading existing code, reviewing other people's, debugging, and negotiating scope with whoever asked.
The variable that separates engineers of similar technical ability is communication under disagreement. Code review is a daily negotiation, incidents are a communication problem before they're a technical one, and an engineer who can't say 'I don't know' will guess in production. None of those show up in a take-home.
The questions, and what a good answer sounds like
Ask these as written. Each one is paired with what a strong answer sounds like, so two people rating the same candidate reach the same conclusion for the same reason.
1. Explain something technical you built to someone who doesn't share your background.
A good answer: Picks the right level of abstraction and checks in rather than lecturing. Strong answers lead with what the thing is for. This is the single most useful question in the list because it is a work sample for the half of the job a take-home can't test.
2. A reviewer rejects your pull request and you think they're wrong.
A good answer: Asks what they're seeing, argues the substance in writing, and escalates or concedes instead of relitigating in comments for a day. What you're listening for is whether disagreement is about the code or about being right.
3. Tell me about something you shipped that broke.
A good answer: A real incident, owned, with the systemic fix rather than just the hotfix. The tell is whether the diagnosis stops at 'I made a mistake' or reaches 'nothing would have caught it, so we added something'.
4. You're given a task and the requirements are ambiguous.
A good answer: Asks before building, with the interpretations named and a recommendation. Engineers who build the wrong thing confidently are more expensive than engineers who are slow.
5. How do you decide when something is done?
A good answer: Names criteria beyond it works — tests, observability, someone else can change it. Strong answers mention the next person to touch the code.
6. You're two days into a five-day estimate and you now know it'll take ten.
A good answer: Says so on day two, with what changed. Same behaviour the sales and account guides test under different names: honest bad news early is worth more than accurate estimates.
7. What is something you believed about engineering two years ago that you no longer believe?
A good answer: A specific reversal with a reason. This is the best proxy available for whether someone is still learning, and it is very hard to prepare convincingly.
8. How do you approach reading a codebase you have never seen?
A good answer: A method — entry points, tests, following one request through — instead of reading top to bottom. Most of the job is reading code, and candidates rarely get asked about it.
A scorecard you can rate against
Rate every candidate 1 to 4 on each row, and write the rating down before you watch the next one. Ratings drift badly when they're relative to whoever you just saw.
| Criterion | What a 4 looks like |
|---|---|
| Explaining to a non-specialist | Chooses the right abstraction and checks understanding. A 2 lectures at one level regardless of the listener. |
| Disagreement in review | Argues substance and then concedes or escalates; a 2 relitigates or capitulates immediately. |
| Incident ownership | Names a systemic fix, not just the hotfix. A 2 stops at the mistake. |
| Handling ambiguity | Asks first with a recommendation. A 2 builds confidently on an assumption. |
| Estimate honesty | Raises an overrun on day two. A 2 works late and reports at the deadline. |
How to run the screen
- Be clear with yourself about what this round is for. It filters and it protects reviewer time. It doesn't assess engineering ability, and treating it as though it does is how you reject good engineers who interview badly.
- Put it before the take-home, not after. The whole economic argument is that reviewing three hundred take-homes is impossible and watching three hundred two-minute answers isn't.
- Ask two or three questions only, and make the explanation question one of them. Engineers are, reasonably, suspicious of process that wastes their time.
- Score communication explicitly and separately from technical content. Mixing them produces a round that quietly becomes a bad technical interview.
- Never reject on accent, hesitation or interview nerves. None of them predict engineering ability, and this failure mode is well documented in technical hiring.
Running this on a large applicant pool is where it gets expensive. VoxScreen sends these questions as a single link, transcribes and scores every answer against criteria you set, and hands back a ranked list. Free for 50 candidates a month, no card.
Common hiring mistakes for this role
- Using a recorded round as a technical screen. It isn't one. Trivia questions asked to camera measure recall and preparation, not engineering.
- Asking algorithm puzzles in a recorded format. The candidate can't ask clarifying questions, which removes the only part of the exercise with signal in it.
- Weighting fluency over content. This is the specific way recorded rounds go wrong in engineering hiring, and non-native speakers pay for it disproportionately.
- Skipping the take-home because the recording was impressive. Articulate and unable to build is a real combination and it is expensive.
- Making it long. Every additional question loses you strong candidates who have three other processes running, and they aren't lost at random.
Common questions
Should software engineers be screened with a video interview?
Not as the technical assessment. That has to be code, whether a take-home, a pairing session or a structured technical interview. A short recorded round is useful in front of it, for the communication signal a take-home never shows and to triage a pipeline too large to review. If you're using it instead of a code assessment, you're using it wrong.
What should I ask engineers in a first-round screen?
Ask them to explain something they built to someone without their background, what they do when a reviewer rejects their pull request, and about something they shipped that broke. Those three cover the communication, disagreement and ownership signals that a code assessment can't show, and they take about six minutes total.
How do I screen hundreds of junior engineering applicants?
Reviewer time is the scarce resource, not candidate time, so put a short recorded round in front of the take-home instead of reviewing everything. Ask the same two or three questions of everyone, score communication separately from content, and be strict with yourself about not turning it into an ad-hoc technical interview.
Is it fair to judge engineers on how they speak?
On communication, yes. Explaining decisions and disagreeing productively are part of the job. On fluency, accent or nerves, no, and the distinction matters because this is exactly where recorded rounds go wrong in engineering hiring. Score whether the explanation landed, not how polished the delivery was, and write that difference into your criteria before you start watching.