Situational interview questions ask what you would do in a hypothetical scenario (“What would you do if a release you shipped started throwing errors?”) instead of what you did in the past. For software engineers they usually involve production problems, disagreements, unclear requirements and competing priorities. Answer them by saying what you'd clarify, what you'd protect first, the concrete steps you'd take and who you'd keep informed. Then anchor the answer in something you've actually done, which turns a guess into evidence.
Below: how situational questions differ from behavioral ones, what interviewers listen for, a five-step answer pattern, 15 engineering scenarios with answer outlines, and how to practice. For past-tense “tell me about a time” questions, see our behavioral STAR examples.
Situational vs behavioral interview questions
Both are standard parts of structured interviews. The U.S. Office of Personnel Management's guide to structured interviews describes situational questions as asking what you would do in a situation like one you might face on the job, and behavioral questions as asking you to describe what you actually did in a relevant past situation. Google's re:Work guide to structured interviewing draws the same line: hypothetical questions present a job-related hypothetical situation, while behavioral questions ask about prior achievements.
| Situational (hypothetical) | Behavioral | |
|---|---|---|
| Typical wording | “What would you do if…?” “Imagine you…” “How would you handle…?” | “Tell me about a time…” “Give me an example of…” |
| Time frame | A future or imagined situation | Something that already happened |
| What it shows | How you'd respond to a new situation (re:Work's framing) | Your patterns of behavior (re:Work's framing) |
| Answer shape | Clarify, protect, act, communicate, prevent | STAR: situation, task, action, result |
| Main risk | Sounding idealistic or generic | Sounding rehearsed, or having no story |
OPM also notes that behavioral questions have shown higher validity where the work is highly complex, such as professional and managerial jobs. That's a good reason to back every hypothetical answer with a real example when you have one. In practice the two blend: a hypothetical often arrives as a follow-up to a story (“What would you do if it happened again tomorrow?”), and the Tech Interview Handbook's list of common behavioral questions includes a hypothetical about what you'd want to work on during your first day at the company.
What interviewers listen for
- Priorities. Do you protect users, data and production before your own code or the deadline?
- Judgment under uncertainty. Do you ask what you'd need to know, or charge ahead on assumptions?
- Communication. Who would you tell, when and where? Silent heroics are a red flag.
- Ownership with limits. Do you act on what's yours and escalate what isn't, at the right moment?
- Realism. Answers that need unlimited time, perfect teammates or zero trade-offs sound untested.
A five-step pattern for answering
- Clarify. State your assumptions or the one or two questions you'd ask first (“Is this hitting all users or one region?”). Don't stall with ten.
- Protect. Say what you'd stabilize first: users, data, security or the commitment at risk.
- Act. Walk through concrete steps in order, naming the people or tools involved.
- Communicate. Who you'd inform, when, and in which channel.
- Prevent and anchor. How you'd stop it from happening again, then one sentence of real experience: “I handled something similar when…”
Not every question needs all five; people scenarios lean on steps 1, 3 and 4. Aim for one to two minutes. If you're interviewing at Google, our Googleyness and leadership guide covers how hypotheticals show up in that round.
15 situational interview questions for software engineers (with answer outlines)
The outlines below are examples we wrote to show the shape of a strong answer, not the only right answer. Adapt them to your stack, your team and your level.
Production and technical judgment
1. “What would you do if error rates spiked right after you deployed a change?”
Roll back or turn off the feature flag first; investigate once users are safe. Post in the incident or team channel what you saw and what you did. Then check logs and the diff, reproduce the bug, fix it with a test and redeploy carefully. Close with a short blameless write-up and the alert that would have caught it sooner.
2. “What would you do if you found a security vulnerability in code that's already in production?”
Keep it out of public channels and public issue trackers. Report it right away through your company's security process or to the owning team, with what you found and how to reproduce it. Help assess exposure, then fix or mitigate under the security team's direction.
3. “What would you do if you had to change a legacy system with no tests and no documentation?”
Find the people who know it and ask what tends to break. Write tests that capture current behavior before changing anything, make the smallest change that solves the problem, ship it behind a flag if you can, and leave notes for the next person.
4. “What would you do if you were paged at 2 a.m. for a service you don't own?”
Follow the runbook if there is one and use only safe, reversible steps, such as scaling up, failing over or disabling a feature. Escalate to the owning team's on-call quickly rather than improvising risky fixes. Log what you did, and follow up on missing runbooks the next day.
5. “What would you do if a teammate's pull request works but would be hard to maintain?”
Separate blocking issues from preferences. Comment on the specific risk (“this duplicates the retry logic in three places”), suggest an alternative and offer to pair if the thread drags on. Block only for correctness, security or real maintenance cost; otherwise approve with a follow-up ticket.
Deadlines and priorities
6. “What would you do if you realized you would miss a deadline?”
Flag it as soon as you know, not on the due date. Bring options with rough estimates (cut scope, add help or move the date), recommend one and explain why, then update everyone who depends on the work.
7. “What would you do if two managers gave you urgent requests at the same time?”
Clarify the real impact and deadline of each. If they still conflict, don't choose silently: put both in front of the two managers, or your own manager, and ask them to agree on the order. Confirm the decision in writing and tell the person whose request waits.
8. “What would you do if a product manager asked for a feature you think will hurt users?”
Ask what problem the feature solves before arguing. Explain the specific risk with data or an example, and offer an alternative that meets the same goal. If the decision still goes the other way, commit and add guardrails such as a flag and metrics. Our guide to the conflict question covers the follow-ups.
9. “What would you do if you were asked to ship before testing was finished?”
Name what could break. Propose ways to ship safely: a feature flag, a staged rollout, extra monitoring, or testing the riskiest path first. If it still has to go out, document the known gaps, get explicit sign-off and schedule the follow-up work.
10. “What would you do if requirements were vague and the stakeholder was unavailable?”
Write down your assumptions and send them for async confirmation. Build the smallest reversible slice that tests the riskiest assumption, and hold off on hard-to-undo choices such as schemas or public APIs until you hear back. Show progress early so corrections stay cheap.
People and team situations
11. “What would you do if a teammate kept missing commitments that block your work?”
Talk to them privately first and ask what's in the way; there's often a blocker you don't know about. Offer help or split the work differently, and adjust your own plan so you aren't stuck. Bring in your manager only if the pattern continues after a direct conversation.
12. “What would you do if you disagreed with an established practice on a new team?”
Learn why it exists before proposing a change; it may solve a problem you haven't seen yet. Build credibility with a few deliveries, then suggest a small, measurable experiment instead of a process overhaul.
13. “What would you do if a senior engineer dismissed your idea in a meeting?”
Don't argue it out in the room. Follow up one-on-one to understand the objection, then write a short proposal with evidence or a prototype. If it's still turned down for good reasons, let it go and say what you learned.
14. “What would you do if you were asked to collect user data the privacy policy doesn't cover?”
Raise the concern with the person asking and bring in your company's privacy, security or legal contact. Don't ship until it's cleared, and suggest a way to meet the goal with less data. This one tests integrity, so say plainly that you wouldn't quietly comply.
15. “What would you do in your first 30 days on this team?”
Listen first: meet teammates and key partners, set up your environment, read the main services and recent incident write-ups. Ship a small change early to learn the deploy path. By the end of the month, agree on goals with your manager and own a first real project.
Weak vs strong situational answers
| Weak pattern | Why it hurts | Stronger move |
|---|---|---|
| “I'd stay up all night and fix it myself.” | Silent heroics; nobody knows what's happening | Mitigate, tell the channel, then fix |
| “I'd escalate to my manager right away.” | Sounds like you can't act alone | Act on what's yours; escalate with options when stuck |
| “That wouldn't happen on my team.” | Dodges the question | Accept the premise and answer it |
| “It depends.” (and nothing else) | No decision | Name what it depends on, then choose |
| “I'd communicate with stakeholders.” | Too generic to evaluate | Say who, when and in which channel |
How to practice situational questions
- Pick five scenarios that match the job. On-call-heavy roles call for more production scenarios; senior and lead roles, more people scenarios.
- Outline each in bullets using the five steps, plus one real experience you can point to. If you don't have one, use the closest internship, school or open-source example; our free STAR story builder helps you shape it.
- Answer out loud in one to two minutes, and time yourself.
- Have someone add a twist. “The rollback fails too. Now what?” Practicing the second layer is what makes an answer sound real.
- Rehearse your anchor stories. CoPilot Interview's free AI mock interview builds behavioral questions from your résumé and the job description, reads them aloud and scores each spoken answer out of 10 with what to fix and a model answer.
For a broader plan, our story-bank method for behavioral interviews shows how a handful of real stories can cover most of these scenarios.
Rehearse your scenario answers out loud
Paste your résumé and the job description, choose a behavioral mix, and answer an AI interviewer out loud. Each answer gets a score out of 10 with what to fix and a model answer. Free for 15 minutes every day, no credit card.
Try a free AI mock interviewFAQ
What is a situational interview question?
A question that describes a hypothetical, job-related scenario and asks what you would do, usually phrased “What would you do if…” or “How would you handle…”. It tests your judgment and priorities rather than your history.
What is the difference between situational and behavioral interview questions?
Situational questions ask what you would do in a hypothetical situation; behavioral questions ask what you actually did in a past one. Behavioral answers follow STAR, while situational answers walk through how you would clarify, prioritize, act and communicate.
Can I use the STAR method for situational questions?
Not directly, because there is no past situation yet. Answer the hypothetical with clear steps first, then add a short STAR-style example of a time you handled something similar. That gives the interviewer both your reasoning and your evidence.
What if I have never been in the situation they describe?
Say so briefly, then reason through it: what you would clarify, what you would protect first, what you would do and who you would tell. Borrow the closest real experience from school, an internship or open-source work so the answer is not purely theoretical.
How long should a situational answer be?
Around one to two minutes. Give the steps in order and the reason behind the key trade-off, then stop and let the interviewer add a twist or ask a follow-up.
Do tech companies ask situational questions?
Yes, often mixed with behavioral ones. Google's re:Work guide to structured interviewing describes hypothetical questions alongside behavioral ones, and a “what would you do if it happened again?” follow-up can come after any story you tell.