Six slots · day one work
Six stories cover this interviewer's entire question surface. They are the gap in your preparation, not the knowledge — a polished boundary line with nothing concrete behind it collapses on the first “can you give me an example”.
Everything on this page is stored in this browser only and is never sent anywhere.
Four rules. They are the difference between a story that works and one that fills time.
One number each, and go and find the real one. Open the old deck, the old dashboard, the old email thread. “Roughly a third” said with confidence is fine; a made-up precise figure is not, because the follow-up question is always about the number.
The other people have to be reasonable. Every story where a colleague was an obstacle who eventually saw sense reads as someone hard to work with across a seam — which is the exact risk this interviewer is assessing.
End on the cost or the change, then stop. Not on the lesson. If the lesson is not obvious from the outcome, the story is the wrong one.
Ninety seconds spoken. Write them short. Anything you cannot say in ninety seconds will be cut badly under pressure, and it will be the ending that gets cut.
Not a story — the constraint everything else has to match. Write it before you write anything else, from memory, in your own words. If it drifted from the prepared version, keep your version and adapt the rest of this site to it.
Why it matters — a two-person panel compares notes, and the thing they compare is how you described the boundary. A slightly weaker line said twice beats a stronger line that contradicts the first one.
The single most valuable story for this round. A strategy, design or process that already existed and that you did not produce — and what you had to add before anyone could build it. It demonstrates the position instead of asserting it.
Covers — what do you add that our team doesn't · how would you avoid becoming another hand-off · what does a good requirements doc contain · a time you worked across teams · what does solution definition mean
Rework avoided, estimate variance, questions raised before build rather than in UAT.
She owns design, so this one is tested rather than accepted. Five beats: what it was, how you knew it was broken, the structural change, the number, what you got wrong first. The evidence beat is the one nearly everyone skips and the one she is listening for.
Covers — walk me through a redesign · how do you know a design is good · why would we want you doing UI/UX · how do you gather requirements · a time you changed your mind
Not an opinion. This beat is what separates someone who designs from someone with taste.
A request from someone with more authority than you that you declined, deferred, or traded down — and the relationship survived. She is assessing whether you protect her team's credibility with stakeholders or spend it.
Covers — how do you say no · influence without authority · a stakeholder wanted their spreadsheet replicated · managing up · a time you disagreed with a decision
A disagreement that looked like a requirements conflict and turned out to be a definitions problem — headcount, spend, active, complete, revenue. This is the most finance-native story on the page, and it maps directly onto the three named projects.
Covers — contradictory requirements · how would you approach the headcount dashboard · what does a good requirements doc contain · a time you found the real problem · why is this harder than it looks
Built correctly, shipped on time, poor usage. The most useful story you own, because it is the only one that proves you measure adoption at all — and a transformation team has seen plenty of these.
Covers — tell me about a failure · how do you drive adoption · a time you were wrong · what would make you unsuccessful here · what are you not good at
Usage, not effort. If you never measured it, say so — that is part of the lesson.
A prototype that changed a decision and was then thrown away — or one that nearly became a commitment and how you handled it. This story reassures both interviewers at once, which makes it the safest one to volunteer unprompted.
Covers — how do you stop a prototype becoming production · how do you know a design is good before it's built · what do you add · a time you de-risked something · working with engineers you don't manage
Done when
Slot 0 is filled from memory, five of the six stories have content, and at least four contain a specific number. Then go and say them out loud once each — writing a story and being able to tell it are different skills, and only the second one is tested.