Behavioral questions for engineers — the round that decides close calls.

Why these rounds carry more weight than engineers expect

Most engineers over-prepare for algorithms and treat the behavioral round as small talk. Hiring committees do the opposite: coding rounds are pass/fail gates, while behavioral evidence decides level and tie-breaks. The evaluators are listening for specific signals — ownership beyond your ticket, judgment under uncertainty, how you metabolize failure, and whether working with you is energizing or exhausting. Every question below maps to one of those.

Structure answers with STAR (the weighting that works is in our hub guide): ten seconds of setup, first-person actions, results with numbers.

Technical disagreement questions

"Tell me about a time you disagreed with a teammate's technical approach." "Your tech lead chose a design you thought was wrong — what did you do?"

The trap is telling a story where you were simply right. The signal interviewers want is how you disagreed: Did you understand the other position well enough to state it fairly? Did you convert opinion into evidence — a benchmark, a prototype, a failure scenario written down? Did you commit cleanly once the decision went the other way?

Incident and failure questions

"Tell me about a time you broke production." "Describe your worst outage." "A bug you shipped hurt users — walk me through it."

Every senior engineer has broken production; pretending otherwise reads as either inexperience or dishonesty. The evaluation is entirely about your relationship with the failure:

• Own the decision chain — "I skipped the canary because the diff looked trivial" beats "the deploy system allowed it."
• Show incident discipline — detection, mitigation first, root cause after, comms to affected teams.
• Land on the systemic fix — the test class that now exists, the alert that now fires, the checklist item that now blocks. Blameless post-mortem culture is the password; the systemic fix is the proof you actually live it.

Ownership and initiative questions

"Tell me about something you improved that nobody asked you to." "A time you went beyond your role."

The distinguishing signal between mid-level and senior is scope of felt responsibility: your ticket vs. your team's outcomes vs. the org's trajectory. Good raw material: the flaky test suite you fixed that unblocked everyone, the migration you proposed and drove, the on-call runbook you wrote after a painful rotation, the cross-team dependency you untangled. Include the unglamorous cost ("I spent two Fridays on it") — unpaid-cost details are what make initiative stories credible.

Technical judgment questions

"Walk me through a hard technical decision." "A time you chose 'good enough' over 'right'." "Describe a trade-off you got wrong."

These test whether you reason in trade-offs or absolutes. A senior answer names the axes explicitly — latency vs. cost, delivery date vs. tech debt, build vs. buy — states the constraint that dominated, and describes the decision process: what you prototyped, who you consulted, what would have changed your mind. If the question is about a wrong call, the lesson must be operational ("I now write down my reversal criteria before committing"), not sentimental ("I learned to be careful").

Collaboration and code review questions

"How do you handle a review where the author pushes back?" "A time you received harsh feedback." "How do you onboard a junior engineer?"

• Code review conflict: separate blocking concerns (correctness, security) from preferences (style); concede preferences explicitly. Naming that distinction out loud is itself the senior signal.
• Receiving feedback: pick a story where the feedback stung and was right. The arc is initial defensiveness → verification → changed behavior with evidence.
• Mentoring: concrete mechanisms beat vibes — pairing cadence, "first PR in week one", graduated scope, letting them own an incident with you as backstop.

A 15-question practice bank

Practice out loud and timed — recording yourself, or in a mock with an AI interview assistant that transcribes and debriefs you. Aim for six reusable stories that cover this whole list:

1. A time you disagreed with your tech lead and were wrong.
2. A time you disagreed and were right — how did you win the room?
3. Your worst production incident, end to end.
4. A project that slipped badly — what did you do when you saw it slipping?
5. Something you built that nobody asked for. Was it worth it?
6. The hardest technical decision of your career.
7. A time you chose speed over quality. Would you again?
8. A time you inherited terrible code. What did you actually do?
9. Harsh feedback you received and what changed.
10. A review comment thread that got heated.
11. How you brought a struggling teammate along.
12. A time you had to say no to a product manager.
13. Work you're proudest of — and its biggest compromise.
14. A time you missed something in review that mattered.
15. Why are you leaving, and why here? (Prepare this cold — the general playbook is in the hub.)