Practice, with someone who has been on the other side

A real interview, run at real pace, by someone who has sat on the other side of the table for two decades. Coding, or system design, or behavioural — your call.

• A recorded, timed round with a genuine problem — no toy questions.
• I interrupt, I push back, and I ask the follow-up you were hoping to avoid.
• Then we stop, and I tell you exactly what I would have written on the feedback form.
• We re-run the moment it went wrong until the answer is yours, not mine.

Most people can draw the boxes. Fewer can defend them when I ask what happens at ten times the traffic, or when the third box is down.

• Start from the requirements, not the architecture diagram — most designs fail here.
• Capacity, consistency, failure modes, and the trade-off you are actually making.
• What breaks first, how you would know, and what you would do at 3am.
• How to say "I do not know, here is how I would find out" and have it land well.

For new managers and new tech leads. I play a senior engineer on your team — the skeptical one, the checked-out one, the brilliant one who will not write tests — and you have to actually handle it.

• You run the one-on-one, the design review, or the difficult conversation. I stay in character.
• Scenarios drawn from what actually happens: a missed deadline, a rejected design, a quiet resignation risk.
• We break character to debrief, then run it again with what you learned.
• No slide deck about "radical candour." You practise the sentence until you can say it.