Behavioral and engineering judgment questions
The non-coding round: incident stories, disagreement, estimates and scope creep, mentoring, technical debt, designs you'd redo, decisions under uncertainty, working with product and design, owning mistakes, and using AI tools responsibly. Model answers describe what a strong answer shows, not a single correct story.
Answer out loud or on paper before revealing. If your answer misses a key point, revisit the linked guide or explainer.
Nothing is due right now. Every question in this set is scheduled for a later review.
Tell me about a production incident you were involved in.
Reveal model answer
A strong answer uses STAR (situation, task, action, result) and spends most of its time on the actions you personally took. Give the context and impact in a sentence or two: what broke, for whom, and how badly. Then cover how you detected it, how you mitigated first (roll back, flip a flag, shed load) before hunting for the root cause, how you communicated with stakeholders while it was happening, and how you found the cause. Close with a measurable result and what changed afterwards: the blameless postmortem, the follow-up actions, and the alert or guardrail that would catch it sooner next time. The interviewer is checking for calm prioritization, ownership without blaming people, and learning that changed the system, not only the people involved.
WHAT A STRONG ANSWER COVERS
- STAR structure, weighted toward your own actions.
- Impact in concrete terms (users, duration, money).
- Mitigate first, diagnose second.
- Communication during the incident.
- Blameless postmortem and systemic follow-ups.
RED FLAGS
- "We" for everything, so your own role is invisible.
- Blaming a teammate or another team.
- No result, or a lesson like "be more careful".
- A story where nothing went wrong.
LIKELY FOLLOW-UPS
- What would you have done if the rollback hadn't worked?
- Which follow-up action from the postmortem actually got done?
How did your answer compare?
SOURCES
Tell me about a time you disagreed with a technical decision.
Reveal model answer
A strong answer shows that you disagreed with evidence and through the right channel, then committed to the outcome. Describe the decision and why it mattered, and how you made your case: a written proposal or design-doc comment that framed the trade-offs in terms of shared goals (cost, risk, user impact), data or a quick prototype instead of opinion, and an honest account of the other side's strongest argument. Then the resolution: either you changed minds, or you were overruled and backed the decision fully while proposing a checkpoint to revisit it. Interviewers look for respect, persuasion with evidence, and the ability to disagree and commit without undermining the decision later.
WHAT A STRONG ANSWER COVERS
- Evidence and trade-offs, not taste.
- Fair to the opposing view.
- Escalation through the right channel at the right level.
- Commitment after the decision; no quiet sabotage.
- What you learned, including if you were wrong.
RED FLAGS
- A story where you were right and everyone else was foolish.
- Going around the decision-maker, or ignoring the decision.
- Never disagreeing with anyone.
LIKELY FOLLOW-UPS
- How did you decide it was worth the fight?
How did your answer compare?
SOURCES
How do you estimate work, and what do you do when scope keeps growing mid-project?
Reveal model answer
A strong answer treats estimates as ranges with stated assumptions rather than promises: break the work down, call out the unknowns and spike the riskiest one first, and give a range that narrows as you learn. Many teams flip the question by setting an appetite, the time the work is worth, and shaping the scope to fit it, which makes trade-offs explicit up front. When scope grows, make the cost visible right away instead of absorbing it quietly: "adding X moves the date by about a week, or we drop Y", and let the product owner choose between time, scope, and quality. A good example story shows you re-planning early, cutting to a smaller valuable release, and keeping stakeholders informed, without missing the date silently.
WHAT A STRONG ANSWER COVERS
- Ranges and assumptions, with risk reduced early.
- Fixed time and variable scope (appetite) as a tool.
- Surface each scope change with its cost when it arrives.
- The trade-off decision belongs to the product owner.
- Early communication; no silent slips.
RED FLAGS
- Padding every estimate by three and calling that a method.
- Absorbing scope with overtime until the team burns out.
- Refusing to estimate at all.
LIKELY FOLLOW-UPS
- Your estimate was off by 2x. How did you handle it?
How did your answer compare?
SOURCES
Tell me about someone you mentored or helped grow.
Reveal model answer
A strong answer shows you adjusted to the person rather than handing out generic advice. Start with where they were and what they wanted, then what you did: asked questions before giving answers (the GROW model of goal, reality, options, will, which Google's re:Work coaching guide uses, is a useful frame), handed them work slightly beyond their current level with a safety net, gave specific and timely feedback in code review and one-on-ones, and gave them visibility (letting them present the work). Finish with a concrete outcome, such as them leading a project or being promoted, and what you learned about mentoring. The signal is leverage: you multiply the team rather than being the bottleneck.
WHAT A STRONG ANSWER COVERS
- Adapted to the person's goals and level.
- Coaching through questions, not only telling them what to do.
- Stretch work with support.
- Specific feedback and visibility for their work.
- A concrete outcome for them.
RED FLAGS
- Mentoring meaning "I answered their questions".
- Taking credit for the mentee's results.
LIKELY FOLLOW-UPS
- How did you handle a mentee who wasn't improving?
How did your answer compare?
SOURCES
How do you decide when to pay down technical debt versus ship features?
Reveal model answer
A strong answer treats debt as a business trade-off. Taking on debt deliberately to hit a date can be prudent, while reckless debt and debt nobody noticed are the kinds to watch. The interest only matters where the code changes often, so prioritize debt that sits on a frequently changed path or causes incidents, and leave stable code alone even if it's ugly. Measure it (lead time, incident counts, onboarding friction), fix the hot spots directly before adding process, and pitch the work in product terms: "this cuts checkout changes from two weeks to two days". In practice, refactor alongside the features that touch the code, set aside a steady share of capacity, and plan larger paydowns with milestones; a big-bang rewrite is the last resort.
WHAT A STRONG ANSWER COVERS
- Prudent versus reckless, deliberate versus inadvertent debt.
- Focus on debt in code that changes often.
- Evidence and business framing.
- Incremental paydown alongside feature work.
- Wariness of rewrites.
RED FLAGS
- "Stop all features for a quarter to refactor" with no measures.
- Treating all old code as debt.
- Never paying any of it down.
LIKELY FOLLOW-UPS
- Tell me about a time you argued for a debt paydown and lost.
How did your answer compare?
SOURCES
Tell me about a system you designed that you would do differently now.
Reveal model answer
A strong answer picks a real decision that had consequences, explains why it was reasonable with what you knew at the time, and then says specifically what changed: scale, team size, or a requirement you didn't foresee. Give the cost in concrete terms (migrations, incidents, coupling) and what you would choose now, including what you'd give up by choosing it. Good answers also cover what you changed in your process: writing design docs or ADRs that record the alternatives and the conditions for revisiting them, putting extra care into hard-to-change things like data models and interfaces, and validating with real clients early. This question tests self-awareness and whether you can reason about trade-offs, not whether you've never made a mistake.
WHAT A STRONG ANSWER COVERS
- A real decision with real consequences.
- Fair to the earlier context.
- A specific alternative and its costs.
- A process change: ADRs and care with interfaces and data models.
- Self-awareness without beating yourself up.
RED FLAGS
- "I'd use a different framework" with no reasoning.
- Blaming requirements or other people.
- Claiming you'd change nothing.
LIKELY FOLLOW-UPS
- How would you migrate the existing system without stopping feature work?
How did your answer compare?
SOURCES
Tell me about a time you had to make a decision or prioritize without enough information.
Reveal model answer
A strong answer separates reversible decisions from irreversible ones: decide reversible ones quickly with a stated assumption and a checkpoint, and spend the extra effort only on the ones that are expensive to undo. Describe how you found the cheapest information that would change the decision (a log query, a spike, a five-minute call with a user) and set a deadline for gathering it, made the call and wrote down the assumptions, and told stakeholders what would make you revisit it. For prioritization, show a framework you actually used, such as impact against effort, existential risks first, or what unblocks the most people, and what you deliberately didn't do. Then the result, and whether the assumptions held.
WHAT A STRONG ANSWER COVERS
- Reversible versus irreversible decisions.
- The cheapest information that would change the decision, with a time limit.
- Written assumptions and a review point.
- An explicit prioritization rationale, including what you chose not to do.
- Honest about the outcome.
RED FLAGS
- Waiting for perfect information.
- Acting on gut feel with no review afterwards.
- Prioritizing whoever shouts loudest.
LIKELY FOLLOW-UPS
- What would have made you reverse the decision?
How did your answer compare?
SOURCES
How do you work with product managers and designers, especially when you disagree on scope or feasibility?
Reveal model answer
A strong answer shows early, two-way collaboration instead of a hand-off. Get involved while the problem is still being shaped, so feasibility and cost inform the design. Offer options with trade-offs ("we can ship this in two weeks if the filter is server-side only") instead of a yes or no. Raise edge cases and states the design missed, such as empty, loading, error, offline, and accessibility. When you disagree, anchor on the user problem and the evidence, prototype to settle the question, and respect that product owns the priorities while you own the technical judgment. A good example has you changing a plan for the better together, with clear roles and expectations.
WHAT A STRONG ANSWER COVERS
- Early involvement, while the problem is being shaped.
- Options with costs, not just yes or no.
- Missed states and accessibility raised early.
- Shared focus on the user problem.
- Clear decision rights.
RED FLAGS
- "I just build what's in the ticket."
- Treating product or design as the opposing side.
- Vetoing on feasibility without offering alternatives.
LIKELY FOLLOW-UPS
- Tell me about a time a designer's idea changed your technical approach.
How did your answer compare?
SOURCES
Tell me about a mistake you made at work and how you handled it.
Reveal model answer
A strong answer picks a real mistake with real impact (not a disguised strength), states plainly that it was yours, and moves quickly to what you did: raised it immediately rather than hiding it, limited the damage, and told the people affected. Then show the systemic fix, not just personal resolve: a test, a check, a review step, or a guardrail that makes the same mistake hard for anyone to repeat, ideally written up in a blameless postmortem. The signals are honesty, a quick escalation, and a focus on improving the system, which is what makes teams psychologically safe enough to report problems early.
WHAT A STRONG ANSWER COVERS
- A real mistake, owned plainly.
- Raised quickly and transparently.
- Damage limited, and the people affected informed.
- A systemic fix, not just "I'll be more careful".
- What it taught you.
RED FLAGS
- "I work too hard" or a similar humblebrag.
- Shifting blame to tools or other people.
- A mistake with no consequences, chosen to be safe.
LIKELY FOLLOW-UPS
- How did your team or manager react, and what did that teach you about how you lead?
How did your answer compare?
SOURCES
How do you use AI coding tools in your work, and how do you use them responsibly?
Reveal model answer
A strong answer is concrete and balanced: say where AI helps you (scaffolding, tests, unfamiliar APIs, explaining code, first drafts) and where you don't trust it (security-sensitive logic, subtle concurrency, version-specific facts). The core is accountability: you own every line you merge, so you read and understand generated code, check it with tests and type checks, and verify APIs and versions against the official documentation, because models can invent APIs and packages. Cover data handling: follow company policy on what code or data may go to which tools, and never paste secrets or customer data. Watch for supply-chain risk (packages that don't exist or are typo-squatted) and for prompt injection when tools act on untrusted content. Mention evidence that AI amplifies a team's existing practices, good or bad, so strong review, tests, and small batches matter more with AI, not less.
WHAT A STRONG ANSWER COVERS
- Specific uses and specific limits.
- Ownership: understand, test, and review generated code.
- Verify facts and dependencies against primary sources.
- Data and secret handling within policy.
- Security risks: invented packages, prompt injection, insecure output.
- AI amplifies existing engineering practices.
RED FLAGS
- "I don't use it" as a point of pride, with no reasoning.
- Merging generated code you can't explain.
- Pasting production data or credentials into a chat tool.
LIKELY FOLLOW-UPS
- How would you review a large AI-generated pull request from a teammate?
- What guardrails would you add before giving an agent write access to the repository?
How did your answer compare?
SOURCES