R11 · Part 3 · The people rounds
Behavioural & hiring manager
Prepare six real stories and you can answer any question in this round, because the twenty questions map onto the same handful of events. Situation, task, action, result — and spend most of the time on the action, because that is the only part that is about you.
Everything open, top to bottom.
07On this page
- Tell me about a time you disagreed with a technical decision.
- Your app is down in production and you are the only engineer available. What do you do?
- Why do you want to work here?
- Where do you see yourself in three years?
- You have worked remotely for three years. How will you work in an office team?
- The rest of the round
- What you ask them — and the one question almost nobody asks
1 · A production failure you owned
What broke, how you found out, the first ten minutes, and the structural change that made recurrence impossible.
2 · A disagreement you lost
You argued a technical position, did not win, committed fully anyway, and it worked out. More valuable than one you won.
3 · A difficult client or stakeholder
Scope change, an impossible deadline, or a demand you pushed back on. Client work gives you plenty of material.
4 · Shipping under real time pressure
What you deliberately cut, and how you made sure the debt was recorded rather than quietly forgotten.
5 · Someone you made better
A specific junior, a specific weakness, what you did, and what they can do now that they could not before.
6 · A decision you reversed
You committed, evidence came in against it, and you changed course. Shows you update on data rather than on ego.
Tell me about a time you disagreed with a technical decision.
What they are really testingWhether hiring you means hiring an argument.
The strongest version of this story ends in one of two places: "and I was wrong", or "and I lost, and I committed fully anyway, and here is how I made it work."
Managers are screening for disagree-and-commit. A candidate who wins every story they tell is either lucky, or is telling you they do not let things go.
The story where you were right, they did not listen, and it later broke — told with satisfaction. Even when true, the tone is what gets scored, and it reads as "I will say I told you so."
“On the notifications feature I thought the templates should live in the database so the content team could edit them without a deploy. My lead wanted them in code. I said why I preferred it — fewer deploys for copy changes — and he pointed out we had no review flow, so a typo would go straight to users with nothing in between. I had not thought about that. We kept them in code and I wrote a script that made copy changes a two-minute job instead of an hour. If we had got a review flow later I would have raised it again.”
Why it passes here: Nobody expects you to have won an architecture argument at two years. They are checking that you can disagree without it becoming personal, and that you can say “I had not thought about that” — which most candidates carefully avoid, and which reads as honest rather than weak.
“We were deciding whether to move to a monorepo. The case for was shared code and atomic cross-repo changes. My case against was CI: we were at eleven minutes and I thought it would go to around forty without the task caching we did not have. I built that argument with a number rather than a feeling — I prototyped it and timed the pipeline and put the figure in the doc. The team went ahead anyway, because the duplication cost was hurting more than I had weighted it. So I committed: I took the caching work that made it viable and we landed at fourteen minutes. Looking back the decision was right and my objection was really about sequencing, not direction.”
Why it lands: Three things score here. The trade-off is described as a trade-off instead of as you being right. The evidence is a measurement. And you committed after losing, with work attached — which is the specific behaviour this question exists to find, and the reason it is asked in almost every loop.
“We had a chance to consolidate two payment integrations and I argued against doing it that quarter. I was overruled, it shipped, and it cost us two incidents and about six weeks of unplanned work. So I was right, and I still count it as my failure — being right in a document is worth nothing. I had raised it as a technical risk, in a technical forum, to people who were optimising for a date, and I never translated it into their terms: no number on the probability, no cost for the rollback, and no smaller version of the plan that would have given them most of what they wanted. Now when I disagree with something that is going to happen anyway, I bring the cheaper alternative rather than only the objection.”
Why this is the level above: Choosing a story where being right did not help is a level marker on its own — most candidates cannot resist the one where they won. The lesson is about making an argument land inside an organisation, which is what senior means past the point where your technical judgement is already assumed.
- What would you do if the same thing happened here?
- How did the other person feel about it afterwards?
Your app is down in production and you are the only engineer available. What do you do?
What they are really testingWhether your instinct is to restore or to investigate. There is a right answer.
In this order, and the order is the answer:
- Confirm the blast radius. Everything, or one endpoint? All users, or one tenant?
- Communicate immediately, before you have a diagnosis, with an expectation for the next update. Silence is what turns an outage into a relationship problem.
- Restore service. Roll back to the last known good release. Do not debug production while it is down.
- Verify recovery against a real user path, not just a health check returning 200.
- Then investigate, on the artifact and the logs, not on the live system.
- Blameless write-up with one concrete prevention action that has an owner and a date.
- What if rolling back is not possible because of a migration?
- Who do you tell first?
- What goes in the write-up?
Why do you want to work here?
What they are really testingWhether you researched. On a walk-in day this is where most candidates are visibly caught out.
Ten minutes on their website and LinkedIn before you walk in — for every company, in the queue if necessary. Then name their product, name something specific about the problem it solves, and connect it to something you have actually built.
"You are solving X, and the closest thing I have built is Y, which is why the problem is interesting to me" beats any amount of enthusiasm. Enthusiasm without specificity reads as the same answer you gave the company down the road.
"I've heard great things about the culture" and "I want to work with cutting-edge technology." Both are content-free, both are said by everyone, and both signal you did not look them up.
- What do you think our biggest technical challenge is?
- Who do you think our competitors are?
Where do you see yourself in three years?
What they are really testingWhether you will still be there. They are pricing the cost of replacing you.
For your profile the answer that lands is depth, not title: owning a system end to end, being the person the team asks about the architecture, growing into technical leadership through influence rather than headcount.
If you genuinely want people management, say so — but frame it as an interest to grow into, not a condition. And do not say "running my own company", however true, in a round designed to test retention.
- What would make you leave after a year?
- Do you want to manage people?
You have worked remotely for three years. How will you work in an office team?
What they are really testingA real question for you specifically, and the interviewer may not ask it directly — they will just wonder.
Get ahead of it. Frame remote as having made you better at the things offices are bad at — written communication, asynchronous decision records, making your work visible without being seen — and then say plainly that you moved cities to be in a room with people, which is a stronger signal than any answer.
- How do you handle a disagreement over text?
- What did you find hardest about remote work?
The rest of the round
What they are really testingSame six stories, twenty different doors into them.
- Tell me about a project that failed.
- How do you handle competing priorities from two stakeholders?
- Describe a time you had to learn something quickly.
- How do you give critical feedback on a colleague's code?
- How do you receive it? Tell me about feedback that stung.
- What do you do when you are blocked?
- Describe your ideal team and your ideal manager.
- How do you keep quality up when the deadline will not move?
- Tell me about a time you said no.
- What motivates you, and what makes you disengage?
- Tell me about a time you had to work with someone difficult.
- How do you decide when something is good enough to ship?
- What is the hardest bug you have ever debugged? (Have a real one, with the diagnostic path — this doubles as a technical question.)
- What do you do outside work? (If you have a public project of your own, lead with it — it is genuinely differentiating and it evidences everything else you have claimed about standards and mentoring.)
- What questions do you have for me? (Never "none." See below.)
What you ask them — and the one question almost nobody asks
What they are really testingThis is scored. Two or three good questions, tailored to who is in front of you.
To the engineer who interviewed you
- What does the path from merged pull request to production look like, and how long is it?
- What is the test and code review culture actually like — not aspirationally?
- What is the part of the codebase everyone is slightly afraid of?
- How much of your week is feature work versus maintenance and incidents?
To the hiring manager
- What would someone need to have done in the first six months for you to consider this hire a clear success?
- Why is this role open — growth, or a replacement?
- How does the team decide what gets built, and how much say does engineering have?
- What is the biggest technical risk facing the team in the next year?
To HR
- What is the fixed-to-variable split, and what percentage of variable was actually paid out last year?
- How does the appraisal cycle work, and what was the average increment last cycle?
- Is there a formal engineering level structure, and where would this role sit?
The one worth asking every single time: "Is there anything about my background that gives you hesitation, that I could address now?" It is uncomfortable and it works. Either you get to answer the objection while you are still in the room, or they say no and you have closed the loop cleanly. Almost nobody asks it, and interviewers remember the people who do.
- Which of the teams you have met would you most want to join?
- What would make you say no to an offer from us?
Finished this round?
0 of 27 rounds read in this book