● Interview questions by role

Software engineer interview questions

By The Don't Wing the Interview Team · Published 5 July 2026

Software engineering interviews are two different exams wearing one name. The first tests whether you can build: coding exercises, system design, technical deep-dives. The second — the one this guide covers — tests whether anyone can build with you: how you handle disagreement, missed deadlines, ambiguous requirements and code review friction. Candidates routinely over-prepare the first and walk into the second cold.

That is a costly imbalance, because the behavioral loop is where hiring committees break ties. Two candidates who both passed the coding bar are separated by who showed clearer ownership, better communication and more credible judgment — all of which come from prepared, specific stories, not improvisation.

What employers test software engineer candidates on

Ownership under failure: what you do when your code, estimate or design turns out to be wrong — engineering interviews probe this harder than almost any other competency.
Collaboration signals: code review behavior, disagreement with senior engineers, working with product managers and designers who change requirements.
Judgment and trade-offs: whether you can explain why you chose an approach, what you gave up, and when you would revisit the decision.
Communication across the technical boundary: explaining a technical problem to a non-technical stakeholder without either condescending or hiding behind jargon.
Delivery realism: how you estimate, what you do when a deadline slips, and whether you raise problems early or ride them into the ground.

Ownership and failure questions

“Tell me about a time you failed.”
Engineering versions of this usually probe a technical bet that went wrong or an estimate that blew up. Own the decision, quantify the impact, and show the mechanism you adopted afterwards.
“Tell me about a time you shipped a bug to production.”
The interviewer wants your incident behavior: how fast you detected it, whether you communicated before being asked, how you fixed it, and what prevention you added. Speed of disclosure matters more than the bug itself.
“Describe a technical decision you got wrong.”
Pick a real architecture or tooling choice. Explain what you knew at the time, what you missed, and how you unwound it — the competency is intellectual honesty plus recovery, not infallibility.
“Tell me about a time you missed a deadline.”
Show early escalation with options, not a heroic all-nighter. Interviewers score “I told my lead in week two and we cut scope” far above “I worked weekends and nearly made it”.

Collaboration and conflict questions

“Tell me about a disagreement with another engineer.”
The strongest answers move the disagreement from opinion to evidence: a prototype, a benchmark, a design doc with trade-offs. Show that you committed fully once the decision was made — even when it went against you.
“How do you handle harsh code review feedback?”
Give a real example with the feedback named. Zero defensiveness, a distinction between style preferences and substantive issues, and ideally a changed habit that came out of it.
“Tell me about working with a difficult product manager or stakeholder.”
Avoid making the other person the villain. The signal is how you converted friction into structure: clearer requirements, a shared priority list, an agreed definition of done.
“Describe a time you mentored or unblocked another engineer.”
Expected from mid-level upwards. Show diagnosis (what they were actually stuck on), your approach (pairing, questions, docs — not just doing it for them), and what they could do afterwards that they could not before.

Judgment and delivery questions

“Walk me through the project you're most proud of.”
This is a depth probe disguised as an icebreaker. Pick the project you can defend three follow-ups deep: why this design, what broke, what you would do differently. Pride without detail reads as inflation.
“Tell me about a time you had to make a technical decision with incomplete information.”
Show your actual method: what you did to reduce uncertainty cheaply (spike, prototype, asking someone who had done it), the reversible-versus-irreversible framing, and the checkpoint you set to revisit.
“Describe a time you improved something nobody asked you to improve.”
Initiative with judgment — the improvement should have served the team or the user, and you should be able to say what it cost and why that trade was right. Unrequested refactoring that delayed a release is a negative signal dressed as a positive.
“How do you decide when code is good enough to ship?”
Anchor it in a real shipping decision. Name the bar you applied — tests, review, monitoring, rollback plan — and show that the bar moves with the stakes of the change.

How expectations change with seniority

Early-career / junior
Interviewers expect learning velocity and coachability more than scope. Strong answers show you asking good questions, absorbing review feedback fast, and turning one mistake into a changed habit. Do not inflate scope — a defended small story beats a borrowed big one.
Mid-level
The bar shifts to independent ownership: features carried end to end, incidents handled, estimates owned. Your stories should show you operating without someone checking your work, and starting to influence how the team works — reviews, testing, on-call habits.
Senior and above
Stories must extend beyond your own output: technical direction you set, conflicts between teams you resolved, engineers you grew, decisions you made with incomplete information and real consequences. Interviewers at this level probe for judgment under ambiguity and how you disagree with other senior people.

A preparation plan that actually works

01
Read the actual job posting and list the competencies it names or implies — ownership, cross-team work, mentoring, ambiguity. That list is your question forecast.
02
Pick six to eight real projects or incidents and map each to the competencies it can evidence. One strong story usually covers two or three questions with different emphasis.
03
Write each story as bullet points in STAR shape — situation, your task, your actions, the measured result — and attach one number to every result you can.
04
Say every story out loud against a timer at least twice. Written answers hide the rambling that spoken answers expose; the interview is spoken.
05
Run a full voice mock interview against the specific job posting, score the answers, and spend your remaining prep time only on the weakest two or three — targeted repair beats another general rehearsal.

Frequently asked questions

Do behavioral questions really matter for engineering roles?

Yes, and increasingly so with seniority. Most engineering hiring loops include at least one dedicated behavioral interview, and hiring committees use it to break ties between technically comparable candidates. A failed behavioral round sinks otherwise strong loops — particularly on ownership and collaboration signals.

How technical should my behavioral answers be?

Technical enough to be credible, plain enough that a non-specialist interviewer can follow the stakes. Name the technology and the constraint, but spend your words on decisions, trade-offs and outcomes. If the interviewer wants depth they will ask — leaving room for the follow-up is part of a good answer.

What if most of my work was on a team and I can't isolate my contribution?

Every team project contains individual decisions: something you noticed, proposed, pushed back on, debugged or documented. Interviewers do not expect solo heroics — they expect you to know which parts were yours. Answers built entirely on “we” are one of the most common reasons engineering behavioral rounds score poorly.

How is a senior engineer's behavioral interview different from a junior's?

The same questions arrive with higher expectations. A junior can pass with ownership and learning; a senior is expected to show influence beyond their own tasks — mentoring, steering technical direction, handling conflict between teams, and making judgment calls with incomplete information. Prepare stories at the scope of the level you are applying for.