Situational Interview Questions for Software Engineers: 10 Scenarios With Answers
Situational interviews are the part of the loop where an interviewer stops asking what you have done and starts asking what you would do. The prompts always begin the same way. "Imagine you just got paged at 2 a.m." "Suppose the spec you were given turns out to be wrong." "What would you do if a senior engineer keeps blocking your pull request?"
Behavioral questions mine your past. Situational questions stress-test your judgment in a future that has not happened yet. The interviewer wants to see whether you panic, default to blame, or reach for a process. Most candidates flunk these questions not because they lack experience, but because they freestyle. They talk through a scenario the way they would talk through it with a friend: loose, meandering, sometimes contradicting themselves.
This post gives you a framework and ten scripted scenarios with strong and weak answers. The goal is not to memorize. The goal is to rehearse a default shape that lets your real experience land in under two minutes.
Table of Contents
- Why Situational Questions Are Different
- The SCAN Framework for Situational Answers
- Scenario 1: The Ambiguous Spec
- Scenario 2: The Blocked Pull Request
- Scenario 3: The Production Incident at 2 a.m.
- Scenario 4: Conflict With a Senior Engineer
- Scenario 5: The Impossible Deadline
- Scenario 6: The Legacy Code With No Tests
- Scenario 7: A Teammate Is Underperforming
- Scenario 8: You Disagree With a Design Decision
- Scenario 9: Scope Creep Mid-Sprint
- Scenario 10: You Shipped a Bug That Cost Money
- Common Pitfalls and How to Avoid Them
- FAQ
- Conclusion
Why Situational Questions Are Different
Behavioral questions have a STAR-shaped anchor because they reference a real event. You pick a project, narrate what happened, and describe the outcome. Situational questions float. They ask you to reason about a scenario you have not lived through, or to generalize a past experience into a repeatable playbook.
That shift in tense creates three traps.
The first trap is hedging. Candidates pile conditionals on top of conditionals. "Well, it depends on the severity, and also on who is involved, and also on what time it is." The interviewer wants to see you make decisions, not to see you avoid them.
The second trap is performing. Candidates reach for what sounds mature rather than what they would actually do. "I would schedule a one-on-one with the senior engineer to align on our values." No one does that. The answer feels hollow because it is hollow.
The third trap is forgetting that the interviewer is also evaluating your technical reasoning. A situational question about a production incident is not just a test of your communication. It is also a test of whether you know how to stabilize before you diagnose.
The fix is a framework tight enough to keep you from hedging, flexible enough to let your real experience through, and short enough to stay under two minutes.
The SCAN Framework for Situational Answers
SCAN stands for Situation, Constraints, Action, Next step. It is deliberately compact so you can recite it under stress.
Situation: restate the prompt in your own words. One sentence. This buys you a breath and confirms you heard the question.
Constraints: name two or three things that shape your response. Severity. Blast radius. Time of day. Who else is on call. This is where you demonstrate judgment, because you are showing what you weigh.
Action: describe what you would do in order. Three to five steps, no more. Use verbs. "I stabilize. I communicate. I investigate."
Next step: close the loop. A postmortem, a follow-up document, a retrospective. Strong engineers do not just solve; they prevent.
Rehearse this shape out loud. If you find yourself adding a fifth step or stacking more constraints, you are drifting. Pull back.
Scenario 1: The Ambiguous Spec
Prompt: "You are given a ticket that says 'add export functionality to the dashboard.' The product manager is on vacation for a week. What do you do?"
Weak answer: "I would probably just start coding. CSV export is pretty standard. I have done it before, so I would add a button and ship it."
Why it is weak: the candidate jumps to implementation without acknowledging that the spec is underdefined. They are about to build the wrong thing and call it velocity.
Strong answer using SCAN:
Situation: "A ticket landed with a one-line description and no owner available, so I have to resolve the ambiguity myself."
Constraints: "Two things shape my response. First, export is almost always a user-visible feature, so the wrong choice is expensive to reverse. Second, the PM is out for a week, so I cannot just wait, but I also cannot pretend I have the answer."
Action: "I would do four things. First, I would search the ticket tracker and Slack for prior context, because 'export' has almost certainly come up before. Second, I would write down three candidate interpretations: a CSV of the current view, a PDF report of the dashboard, and a scheduled email export. Third, I would post those three options in the product channel with my recommendation and a deadline, asking for a thumbs-up from whoever is covering. Fourth, if no one replies in twenty-four hours, I would build the smallest version that ships value, which is CSV of the current view, behind a feature flag."
Next step: "When the PM returns, I would walk them through the three options I considered and what I shipped, so we can iterate without rework."
Scenario 2: The Blocked Pull Request
Prompt: "Your pull request has been sitting for four days. The reviewer keeps leaving nits but not approving. How do you handle it?"
Weak answer: "I would just ping them again and maybe escalate to their manager if they do not respond."
Why it is weak: it skips the self-check and jumps straight to escalation. Escalation is the last resort, not the second step.
Strong answer:
"First, I want to verify that the blocker is the reviewer and not the pull request. I would reread the diff as if I were the reviewer. If it is longer than four hundred lines, that is on me, and I would split it. If the tests are flaky, that is on me, and I would fix them.
Assuming the PR is clean, I would address every nit in a single push and leave a comment that consolidates the resolutions so the reviewer does not have to re-read. Then I would ask directly: 'Is there a blocker beyond these comments, or is this ready to approve once the nits are resolved?' That question forces a yes or no.
If another day passes with no reply, I would check their calendar. They might be on leave. If they are online and still silent, I would ask in the team channel for a second reviewer, framing it as wanting unblocked shipping rather than calling anyone out. Escalation to their manager is only if the PR is time-critical and the silence is consistent across days."
Scenario 3: The Production Incident at 2 a.m.
Prompt: "You are on call. At 2 a.m., your pager goes off: checkout conversion has dropped 40 percent. What do you do?"
This is the scenario where structure matters most, because you are being evaluated on whether you have an incident response muscle.
Strong answer:
"My first loyalty is to stopping the bleeding, not to diagnosing. I would open the runbook first, even if I think I know the system, because the runbook has checks in an order that someone sober wrote.
Step one: confirm the alert is real. I would pull up the dashboard and compare this minute to the same minute last week. If conversion is genuinely down, I acknowledge the page so no one else gets woken up duplicately.
Step two: open an incident channel and post a status every fifteen minutes even if I have nothing new. Silence is worse than bad news during an incident.
Step three: check the last deploys in the last two hours. Most outages are self-inflicted. If a deploy went out, roll it back before investigating further. You can always redeploy once you understand what broke.
Step four: if no recent deploy, check external dependencies. Payment provider, CDN, auth provider. A surprisingly large share of 'our site is broken' turns out to be Stripe or Cloudflare.
Step five: once conversion recovers, I stop. I do not keep debugging at 2 a.m. I hand off to the day team with a written summary and go back to sleep. The postmortem happens within forty-eight hours and includes a timeline, a root cause, and two or three concrete action items with owners."
Scenario 4: Conflict With a Senior Engineer
Prompt: "A staff engineer on your team insists on a design you think is wrong. You have presented your case and they are not budging. What do you do?"
Weak answer: "I would just go with their decision because they have more experience."
Why it is weak: it abdicates judgment. Staff engineers are not always right, and interviewers know it.
Strong answer:
"Disagreement with a senior engineer is normal. The question is whether I have made my case well.
First I check my homework. Is my objection about correctness, performance, or maintainability? Do I have a concrete scenario where their design fails? If I cannot articulate a failure mode they have not already answered, my objection may be taste rather than substance.
Second, I reframe the conversation in writing. Verbal disagreements with a senior engineer are asymmetric; they have home-field advantage. I write a short document with their design, my alternative, the tradeoffs, and a recommendation. I send it to them privately before anyone else. That lets them react without public pressure.
Third, if they still disagree after reading the document and we have to ship, I disagree and commit. I write a comment on the design doc saying I do not agree but will implement their decision, and I note the specific failure mode I expect. If I turn out to be right, I have a paper trail to learn from. If I turn out to be wrong, I learn more from being wrong than from being stubborn."
Scenario 5: The Impossible Deadline
Prompt: "Your manager commits the team to shipping a feature in two weeks. You estimate it will take six. What do you do?"
Strong answer:
"The worst thing I can do is silently aim for two weeks and miss by four. That surprises everyone and burns trust.
I would have a direct conversation with my manager within a day of the commitment, not within a week. I would bring three things to that conversation: my estimate with the top three risks, what a scoped-down version that could ship in two weeks would actually contain, and what a six-week version looks like for comparison.
I want the manager making the tradeoff, not me. My job is to surface the options, not to pick for them. They might say 'ship the scoped version now, fast-follow in four weeks.' They might say 'the deadline was political, we can slip.' They might say 'ship what you can in two weeks, we will assess.' All of those are better outcomes than me grinding for six weeks while they tell the business two.
The common mistake is being either silently heroic or loudly defeatist. Both fail. The right posture is honest and constructive."
Scenario 6: The Legacy Code With No Tests
Prompt: "You need to refactor a critical payment module. There are no tests, the original author left the company, and documentation is outdated. Where do you start?"
Strong answer:
"I start with characterization, not refactoring. Refactoring code you do not understand is gambling with production.
Step one: read the code end to end before touching it. I would trace one complete request path and draw the flow on paper. If I cannot explain it to a rubber duck, I cannot safely change it.
Step two: write characterization tests. Not unit tests for the code I wish existed, but tests that capture the current behavior, including the behavior I think is wrong. These tests are scaffolding. They tell me if my refactor changed observable behavior.
Step three: identify seams. Places where I can introduce an interface and swap implementations. Seams let me refactor incrementally rather than in a big-bang rewrite.
Step four: refactor in small commits, each one passing the characterization tests. Deploy behind a feature flag that lets me route a small percentage of traffic through the new path, compare outputs, and fall back instantly if anything drifts.
Step five: once the new path has run shadow for a week with matching outputs, flip the flag. Delete the old code in a follow-up PR so the change is reviewable."
Scenario 7: A Teammate Is Underperforming
Prompt: "A peer on your team is consistently missing deadlines. It is starting to affect your own work. What do you do?"
Strong answer:
"This is not my decision to manage their performance. It is my decision to manage my own work and to be honest with my manager about dependencies.
First, I would talk to the peer directly. Missed deadlines often have causes that look different up close. Maybe they are stuck on a blocker. Maybe the estimate was wrong. Maybe they have a life event they are not broadcasting. A five-minute pairing session can surface a lot.
If I can help unblock them with an hour of my time, I would do it. That is cheaper than escalation.
If the pattern continues after I have tried to help, I would tell my manager, framed around my work, not theirs. 'I have a dependency on X that has slipped twice. I tried to help and the pattern continued. Can we talk about options?' That is not snitching; that is keeping the manager informed about a risk they are paid to manage."
Scenario 8: You Disagree With a Design Decision
Prompt: "The team has picked a database technology you think is wrong for the use case. You have already raised your concern and been overruled. Do you keep pushing?"
Strong answer:
"I push twice, carefully, and then I commit.
The first push was when the decision was being made. The second push is one follow-up, usually in writing, once I have concrete evidence that the concern is real. That evidence might be a prototype showing the problem, a benchmark, or a query I cannot express efficiently in the chosen tech. Without new evidence, a second push is just repetition, and that burns credibility.
If the second push does not change the decision, I commit. I write code that works well in the chosen technology, not code that secretly undermines it to prove a point. If my concern turns out to be real, it will surface on its own, and then we pivot. If my concern turns out to be wrong, I was saved from a bad instinct.
The worst thing is to build in the chosen tech resentfully and produce code that reinforces the original objection. That is not disagreement; that is sabotage."
Scenario 9: Scope Creep Mid-Sprint
Prompt: "Two days into a two-week sprint, your PM asks you to add three new requirements. What do you do?"
Strong answer:
"I say 'yes, and.' I do not say 'no,' and I do not say 'sure.'
'Yes, and' looks like this: 'Yes, I can add those. Which of the existing items should I drop to make room?' That question reframes the request as a tradeoff rather than a free addition. PMs often do not realize the cost of their request until you quantify it.
If the answer is 'nothing, just add it,' I push back with a specific risk. 'If I add all three without dropping anything, I will likely slip the original scope by four days. That puts us at 60 percent chance of missing the sprint review. Is that the tradeoff you want?'
Usually this produces one of three outcomes. The PM picks the most important of the three to add and defers the rest. The PM agrees to extend the sprint. Or the PM realizes on reflection that the new requirements are not urgent. All three are better than silently absorbing the work."
Scenario 10: You Shipped a Bug That Cost Money
Prompt: "A change you deployed caused a payment bug that overcharged customers. How do you handle it?"
Strong answer:
"First, stop the bleeding. Roll back the change immediately if that reverts the bug. If it does not, hotfix the specific overcharge path and deploy.
Second, quantify the blast radius. How many customers, how much money, over what window. This is the number everyone else in the company needs to know.
Third, communicate up and out. Tell my manager, the on-call lead, and whoever owns customer communications within the hour. Do not wait for the full picture. Partial information delivered quickly is more valuable than complete information delivered late.
Fourth, make customers whole. Refunds, credits, whatever the policy is. This is not the engineer's call, but the engineer's responsibility is to give the customer-comms team the exact list of affected accounts.
Fifth, postmortem without blame. The postmortem asks why the bug got past review, why the tests did not catch it, why the canary did not catch it. The action items are systemic, not personal. If my individual behavior was the cause, I own that in a separate conversation with my manager, not in the public postmortem."
Common Pitfalls and How to Avoid Them
Situational answers fail in predictable ways. Watch for these.
The first pitfall is stacking hedges. "I guess it depends, but probably I might, although it could go the other way." Interviewers hear this as the absence of judgment. Cut hedges down to one constraint, then decide.
The second pitfall is describing process without action. "I would gather stakeholders and align on priorities." Gather how? Align on what? The strong version names the stakeholders and the deliverable. "I would message the PM and tech lead with three options and ask for a decision by end of day."
The third pitfall is forgetting the interviewer does not know your company. You will casually say "our on-call rotation" or "our deploy pipeline" as if those terms carry meaning. They do not. Spend ten seconds sketching the context so the interviewer can follow your reasoning.
The fourth pitfall is going over two minutes. Situational answers should be shorter than behavioral ones. You are demonstrating a playbook, not telling a story. Under ninety seconds is ideal.
The fifth pitfall is answering the question you wish they asked. If they ask what you would do about a blocked PR, do not pivot into a story about a PR you unblocked last quarter. Answer the hypothetical, then offer the anecdote as supporting evidence.
FAQ
Are situational questions the same as behavioral questions?
No. Behavioral questions ask about events that happened. Situational questions ask about events that could happen. The former uses STAR; the latter uses SCAN or a similar framework. Many interviewers blur the two, so you should be comfortable switching between tenses.
What if I have never been in the scenario they describe?
Say so, briefly, and then reason by analogy. "I have not been on call for a system at that scale, but I have handled a similar severity incident at my current job, and here is how I would apply that experience." Interviewers prefer honest reasoning over fabricated stories.
How long should a situational answer be?
Between sixty and ninety seconds. If you need more, the interviewer will ask follow-ups. Silence after your answer is a signal to stop, not to elaborate.
Should I ask clarifying questions first?
One, maybe two, and only if the prompt is genuinely ambiguous. If the question is "what would you do if a senior engineer blocked your PR," do not ask "which senior engineer" or "what kind of PR." Those questions stall. Instead, state the assumption you are making and move.
What if the interviewer pushes back on my answer?
Pushback is data, not attack. Engage with the substance. "That is fair, I was assuming the rollback was safe. If the rollback itself is risky, I would do this instead." Strong candidates update their answer visibly. Weak candidates dig in.
Conclusion
Situational questions are not trick questions. They are invitations to demonstrate that you have a playbook, that you can weigh tradeoffs, and that you stay calm when a prompt describes something hard. Most candidates arrive with strong technical skills and a weak structure for these answers. The fix is rehearsal, not cleverness.
Pick three scenarios from this list that feel least familiar. Write out SCAN answers for each. Record yourself saying them. Trim until each one lands in ninety seconds. Do the same for three more a week later. By the time an interviewer asks "what would you do if..." you will have the first sentence already loaded, and the rest will follow.
The engineers who get hired are not the ones who have lived through every scenario. They are the ones who can think on their feet in public, which is exactly what situational questions measure.