Behavioural playbook

Behavioural questions are evidence requests wearing a story costume. "Tell me about a time a project went wrong" is not asking for the incident - it is asking whether you own outcomes and change your practice afterwards. In an AI interview the same prompt often hides a second layer: they want to know whether you can separate a modelling problem from a process problem. Name the capability to yourself before you start talking, then answer that.

STAR keeps an answer complete; the failure mode is spending three minutes on the situation and thirty seconds on what you did. Aim for roughly ninety seconds, most of it on your own decisions, landing on a result someone else could verify. Senior AI interviews reward altitude control: give the outcome first to a hiring manager, the mechanics first to the engineer who will be your peer.

Interviews do not reward recall under pressure; they reward a small set of well-shaped stories you already own. Eight to twelve is enough, each tagged with the capabilities it can evidence, because one story answers several questions with the foreground shifted. For an AI role, make sure the bank covers at least one shipped system, one experiment that failed, and one disagreement about approach.

"Why this company" is answered badly by praise and well by specifics: something they do that connects to something you have done. The senior-IC variant adds a second question underneath - why depth rather than management - and a vague answer there reads as indecision about the ladder. Keep the thread of your career visible: this role should look like the next step in a line, not a jump.

The AI-specific versions are unusually concrete: you think the team is over-engineering an LLM solution where retrieval would do, or a product manager wants a feature you believe will cost more latency than it earns. Both are graded on whether the other side stays credible in your telling - state their case first, well enough that they would sign it. Then translate your concern into their currency, and say what you did after the decision went the other way.

A senior IC role asks you to be a technical reference, and the evidence for that is not your own output - it is growth you caused in someone else. Diagnose before you prescribe in the telling: say why the person was stuck, what structure you gave them, and what they could do afterwards that they could not do before. Cross-functional stories count here too, where the work was making your constraints legible to people who do not share your vocabulary.

"Scaling AI capabilities across Europe" is deliberately vague, and three stakeholders wanting three things from one quarter is deliberately overloaded. Neither question wants the answer you happened to pick - they want the structure you used to pick it: what you knew, what you could not know yet, which decisions were reversible, and the criterion you ranked the asks against. A scope cut told as a deliberate trade reads as stewardship; the same cut told as an accident reads as drift.

The messy production failure is the highest-signal question in most AI interviews, and sanitized answers score worst: if nothing was really your fault, nothing was really learned. Name your own mechanism - the decision or omission that contributed - then the practice you changed because of it. The quarter where the model never beat the baseline is a sibling question, and the answer they want treats it as a finding with a kill decision, not as a confession.

Healthcare AI makes these questions live rather than hypothetical: pushing back on shipping something that was not right, or checking that a patient-facing model works fairly across languages and demographics. Concrete beats principled - name the harm as an event, the people who would carry it, and the alternative you would support. The communication craft and the measurement craft are different skills, and strong answers show both: how you would raise it, and what you would actually measure.