Four hours, six stories, done. You do not write an answer per question. You build a six by six grid of competencies against your own projects, pick six cells, and write one story per cell, so each story already answers three or four of the prompts you will actually hear. Every story runs 90 seconds spoken, with Action taking 60 percent of the words. The final hour is not polishing. It is rehearsing follow-up probes, which is where one-day preparation usually falls apart.
The four hour block, in order
Run these in sequence. The order matters more than the total time, and skipping the last two blocks is the most common way a full day of preparation still produces a bad interview.
0:00 to 0:25, build the grid
Six real projects across the top, six competencies down the side. Mark every cell usable or thin, then pick six cells using each row once and each column once. No writing yet, just the picks.
0:25 to 1:20, write six Action beats and nothing else
Nine minutes each, 120 words each, every one starting with the word "I". No context, no result. Writing Action first stops you spending your best energy on setup, the beat nobody scores.
1:20 to 1:50, bolt on Situation, Task and Result
Five minutes per story, to a hard budget: 24 words, 16, 40. If Situation needs a third sentence, the story is too complicated to use tomorrow. Pick a different cell.
1:50 to 2:05, stop
A real break, away from the screen. You cannot hear your own filler after two straight hours of editing.
2:05 to 2:50, timed read-aloud, six passes
Phone timer, out loud, at real speaking pace. Anything over 95 seconds gets cut, and the cut always comes out of Situation.
2:50 to 3:35, probe drill
Four probes per story, 20 seconds per answer, spoken not written. Twenty four short answers in 45 minutes. This is the block people skip and the block that decides the round.
3:35 to 4:00, cold recall
Shuffle the prompt list, no notes. Three seconds to name which of the six you are about to tell, then tell it. Hesitating over which one means the grid still has an overlap in it.
The 6 by 6 grid
Projects across, competencies down. Swap the column headings for your own six, keeping the shapes: something you launched, something you inherited, something that broke, something with another team, something you built alone, something from an earlier job. The grid is not there to cover everything. It forces a permutation, one cell per row and one per column, so no two of your six stories share a competency or a project.
| Competency | P1 Launch | P2 Inherited system | P3 Incident | P4 Cross-team | P5 Solo build | P6 Earlier role |
|---|---|---|---|---|---|---|
| Ownership when it went wrong | possible | possible | BLAST | thin | possible | possible |
| Conflict and disagreement | FRICTION | possible | thin | possible | thin | possible |
| Ambiguity and scoping | possible | possible | thin | FOG | possible | possible |
| Delivery under a hard date | possible | thin | possible | possible | CLOCK | possible |
| Influence without authority | possible | PERSUADE | thin | possible | thin | possible |
| Being wrong and correcting it | possible | possible | possible | possible | possible | WRONG |
A cell marked thin is not a judgement on the project, it is a warning that the story would need invented conflict to work. Solo builds rarely carry a real disagreement. Incidents rarely carry scoping ambiguity, because at 2am the scope was decided for you. Leave those cells empty.
What the six cover, and the probe each one attracts
Six stories, roughly two dozen prompts. Read the row, pick the tag, then change only your opening sentence so it names the signal the interviewer asked for. The rest stays intact.
| Tag | The prompts it answers | The probe it always attracts |
|---|---|---|
BLAST | Biggest failure; a mistake you made; ownership beyond your remit; walk me through an outage | "How long between the deploy and the moment you knew?" Detection time is scored harder than fix time. |
FRICTION | Conflict with a coworker; disagreeing with someone senior; difficult feedback received; a time you were right | "What if they had never agreed?" The only strong answer commits to a decision anyway. |
FOG | Ambiguous requirements; a decision without enough data; competing priorities; a project nobody owned | "What did you decide not to do?" They want the rejected scope named out loud. |
CLOCK | Tight deadline; going above and beyond; a time you said no; how you prioritise | "What did you cut, and who did you tell?" Cutting scope openly beats cutting quality quietly. |
PERSUADE | Influence without authority; a skeptical stakeholder; getting tech debt funded; disagree and commit | "Whose mind did you fail to change?" A clean sweep sounds fictional. |
WRONG | A time you were wrong; a bad estimate; feedback that changed you; learning something fast | "What would have shown you sooner?" Name the check you should have run in week one. |
The 90 second shape and the 60 percent rule
Two hundred words at interview pace is about 90 seconds. Split them 24 / 16 / 120 / 40. Action takes 60 percent because Situation and Task describe circumstances everyone on that team shared, and Result describes an outcome you can claim only partial credit for. Action is the only beat holding decisions that were yours alone. If your draft carries more Situation than Action, you have written a project summary, not an answer.
Then the four probes every story must survive, rehearsed as separate 20 second answers rather than folded into the story itself:
- "What would you do differently?" The answer has to be a decision, not a virtue. "I would have raised it on day three instead of day eleven" works. "I would communicate more" does not.
- "What option did you reject, and why?" Naming the road not taken turns an anecdote into evidence of judgement.
- "How did you know it worked?" Whatever number sits in your Result, be ready to say how it was measured and over what window.
- "What did the other person actually say?" A near-quote is worth more than any metric here, and it is the probe invented stories die on.
Two rewrites, before and after
Prompt: tell me about a conflict with a coworker.
Before: "So this was at my last company, we were building a new checkout service, and there was a lot going on because the team had just reorganised. One of the other engineers and I did not really see eye to eye about how to structure the API. We went back and forth in code review for a while, eventually came to a compromise and got it shipped, and I think we both learned a lot."
Ninety seconds of talking with no decision in it. Every verb is plural, the disagreement is never stated, and "came to a compromise" gives the interviewer nothing to write down. Here it is at 200 words, Action carrying 120.
After: "I owned the checkout API on a four person team. A senior engineer blocked my pull request three days before a launch marketing had already announced. I had to win the argument, change the design, or ship something I did not believe in. His objection was that my endpoint returned a partial order object, which he had watched cause silent data loss on an earlier service. That was a fair point and I said so first. Rather than argue in comments, I booked twenty minutes and asked him to describe the exact failure he was picturing. Then I built both versions behind a flag and replayed two weeks of production traffic through them. Mine dropped nothing, but his caught a retry case I had missed that could double charge a customer. So I kept my response shape and added the idempotency key he wanted. I posted the replay numbers on the pull request so nobody had to take my word for it. He approved it that afternoon, we launched on the announced date, and the key caught eleven duplicate submissions in the first month that we would otherwise have refunded by hand."
Prompt: tell me about a time you failed.
Before: "My biggest failure was a migration that ran late. There were a lot of dependencies outside our control and some requirements changed halfway through, so the timeline slipped by about two months. I learned a lot about communication, and now I always make sure to over-communicate with stakeholders."
Passive throughout. The delay happens to the speaker rather than because of them, and the lesson is a slogan. The repair is to move the failure off the estimate and onto the silence.
After: "I estimated six weeks to move our reporting jobs off a legacy scheduler. It took fourteen. The estimate was mine alone, and two other teams had planned their quarter around it. In week three I found that a third of the jobs read from a table nobody owned any more, and I said nothing for eleven days because I still believed I could absorb it. That silence was the real failure, not the estimate. When I did raise it, I brought three options instead of an apology: drop the reports nobody had opened in six months, split the migration in half, or hold the date and freeze new jobs. We took the split. Afterwards I worked out what I had missed, which was that I had estimated from job count when the real cost was upstream tables, so every estimate I have given since counts tables. The second half landed four weeks past the original date rather than eight, and the dependent teams replanned once instead of twice."
For prompts pitched at the company you are actually seeing rather than generic ones, the company Q&A generator builds a bank for the company and role. Feed it into the grid. The useful output is the list of prompts none of your six stories can currently answer.
Where one day is not enough, and where a copilot is the wrong tool
Four hours cannot manufacture experience. With eighteen months in one job on one project the permutation breaks, you get three or four honest stories rather than six, and stretching four experiences into six produces the thin, over-rehearsed answers interviewers catch on the first probe. Take the three real ones and rehearse until they survive four questions deep. Depth beats a full grid.
One day is also thin for principle-driven loops that want two examples per principle. The grid still earns its place, because it shows which principles you have no evidence for, but book a second session for the rest.
On tooling, plainly: OfferPilot AI is a poor fit for the live behavioral round specifically. Reading a drafted answer about a life you did not live, while a person watches your face, sounds exactly like what it is. It earns its keep in technical rounds, where a definition or a tradeoff on screen saves you from going blank. Use it here to pressure-test the six beforehand, then close it. Two limits without spin: the overlay is excluded from screen capture at the operating system level, so it does not appear in Zoom, Teams or Meet, but that does nothing about a webcam, a lockdown browser, an interviewer sitting across a table, or a second-device camera. It also runs on Windows 10 and 11 only, with no macOS, Linux, mobile or browser version. For an onsite behavioral round, what is in your head is the entire product.
Six cells, six Action beats, one timer, one probe drill. That is the day. Tomorrow you should be able to name the story in three seconds and start talking.