A behavioural round is an evidence hunt. The interviewer asks for one past event, writes down close to word for word what you say you did, files each piece under a competency and rates it against a written rubric. People who never met you read those notes and decide. So what scores is not a better story but a story that can be written down: a headline first, "I" for your own decisions, the option you turned down and what it would have cost, a number that says how it was measured, and a reflection you have already acted on.
Not advice. General information, and every example is invented.
General information. Company pages were read between 31 Oct and 2 Nov 2026 and change. Every person, number and story below is INVENTED. A claim about how interviewers behave that names no source is the author's reading, not measured.
What the round is for
Several interviewers decide together, so their notes must be comparable. Google's guide to structured interviewing (re:Work, "Updated March 2026") lists role-relevant questions, "Recording comprehensive feedback of candidate answers so evaluators can easily review responses", standard rubrics and calibration.
The guide separates two question types; read which you were asked.
Table: Type, Sounds like, How to answer (2 rows)
| Type | Sounds like | How to answer |
|---|---|---|
| Behavioural | "Tell me about a time you disagreed with a teammate." | One real event: your decisions, a result, a reflection. Not "what I usually do". |
| Hypothetical | "What would you do if two teams wanted opposite things from your service?" | Ask what you need to know, state assumptions, give two options with costs, choose, say what would change your mind. One real sentence afterwards helps. |
INVENTED: the hypothetical above, in five steps 1 min
"First I would ask each team what it needs and by when. Say search wants prices cached for an hour and payments wants every price live, and both are fair. Option one: one rule for all, cheap, and one team loses. Option two: a freshness setting per caller, about two weeks of work. I choose the setting, default live: a stale price costs money, a stale search result a click. If live reads tripled database load, I would revisit. Last year one timeout flag settled a fight like this."
Page: questions first, assumptions aloud, two priced options, a choice with its reason, the trigger to change, one real sentence.
How many questions? Amazon's SDE II prep page says the loop has four 55-minute interviews and each interviewer "will typically ask two or three behavioral-based questions"; its SDE III page says the same of five 55-minute interviews, plus a 60-minute screen where half the time is Leadership Principles. That is eight to twelve questions at SDE II and ten to fifteen at SDE III. Plan for eight stories plus three spares, eleven for a senior loop. For fifteen questions, reuse a story only under a different competency. The 4-week plan rehearses four lead stories first: the four Mock 1 asks (S5, S3, S8 and S6).
Next stop: The shape: STAR with a time budget, 1 min
The shape: STAR with a time budget
STAR is Situation, Task, Action, Result: the situation with a number for the stakes, the task you owned, two to four decisions each with its reason and the option you turned down, a result against a baseline, and one reflection. The fifth beat is the author's addition, because "what would you change?" follows most good stories. No source here says interviewers score the letters: they order your telling, and the rubric judges it. Figure 10.1 draws the ceiling: two minutes, half of it action.
Table: Failure, What it looks like, What the page records (5 rows)
| Failure | What it looks like | What the page records |
|---|---|---|
| Letters without decisions | Four tidy sentences, "we" everywhere, no option rejected | Ownership poor; judgement not reached |
| Story too long | Background first, action at minute four | Missing evidence on the next question |
| Invented precision | A number nobody measured, quoted to the unit | The first follow-up breaks it |
| Wrong question answered | A good failure story told to "a time you disagreed" | Competency not evidenced |
| Recited reflection | "I'd communicate more", nothing behind it | The "what would you change" probe finds nothing |
Next stop: What gets scored, 1 min
What gets scored
Google (re:Work guide) defines three attributes: role-related knowledge, problem solving and leadership. It pairs "Tell me about a time" questions with role knowledge and "Imagine if" questions with problem solving, and rates on four levels: outstanding, solid, borderline, poor. For individual contributors it describes "emergent leadership": taking initiative, working across teams, and a drive for self-development.
Atlassian (engineering interview handbook, 2 Nov 2026) runs a separate values interview "to assess your alignment with Atlassian's five values", often with someone outside engineering, and a manager interview where you "talk about a past project or two". The handbook does not list the five values; read them on Atlassian's own pages. Microsoft has stated, in a regional 2022 post, that it looks for a growth mindset: curiosity and "recognizing that failure happens along the way to mastery". Confirm the current form with your recruiter.
When nothing is published, prepare against these seven, the author's synthesis and not any company's list.
Table: Competency, The interviewer listens for, Evidence that scores (7 rows)
| Competency | The interviewer listens for | Evidence that scores |
|---|---|---|
| Scope | How far your decisions reached | Teams or users affected, money at stake, how long it lasted |
| Ownership | Acting unasked; owning failures | "I noticed, I decided, I followed up three weeks later" |
| Conflict | Raised directly, with data, relationship kept | The other side's view stated fairly |
| Ambiguity | Progress with missing information | The assumption written down, the cheap test, the revisit |
| Growth | Behaviour changed by feedback | What you do differently now, with a later example |
| Collaboration and leadership | Direction without a title | Who you persuaded and how; who did the work |
| Judgement | Options weighed | Two options with costs, one chosen, what would change your mind |
Answer the question asked; if your closest story shows another competency, say so in the first sentence.
Next stop: Amazon-style rounds: leadership principles and the bar raiser, 3 min
Amazon-style rounds: leadership principles and the bar raiser
Amazon publishes sixteen Leadership Principles, all in the table below. Its prep pages say interviewers ask about "the 'what' and 'how' of your experiences, as well as the 'why' of your decisions" and tell you to use STAR. The page lists no example questions and does not say which principles are probed most; the choices below are the author's.
The bar raiser. Amazon's own page describes an interviewer from outside the hiring team who acts as an objective third party, helps decide which principles the loop should test, and shares the final hiring decision with the hiring manager; it states an aim of hiring people better than 50 per cent of their would-be peers. Companies that copy Amazon's loop may use other names; ask whether any interviewer is from outside the team. In the author's reading, one interviewer has no stake in filling the seat and will probe a story until it breaks, so prepare each lead story to survive the whole ladder below.
Moves for an Amazon-style loop.
- Map one story to each principle you expect and tell each story to one interviewer, because the debrief reads notes together; reuse it only under a different principle. Keep three spares; the table maps all sixteen.
- Put the principle in the result, not the first sentence. "I showed Ownership" is a label the interviewer writes.
- Expect metrics. Amazon's page says answers "should include metrics or data where applicable". Bring the number and its source.
- For Dive Deep and Insist on the Highest Standards, rehearse one story three questions deep: the count and how it was counted, why the metric missed it, and the limit of your fix.
- For Have Backbone, Disagree and Commit, name the other side's best argument, say you disagreed once with evidence, and show the commitment after the decision.
Table: Principle (Amazon's words), Story slot, The line the page needs (16 rows)
| Principle (Amazon's words) | Story slot | The line the page needs |
|---|---|---|
| Customer Obsession: "Leaders start with the customer and work backwards." | Won with data (S4) | Start from the user's wait: the feature shipped and p95 stayed under budget |
| Ownership: "don't sacrifice long-term value for short-term results" | Your fault (S8) | You told operations first and made the job refuse a second file |
| Dive Deep: "skeptical when metrics and anecdote differ" | Won with data (S4) | The 35 ms measured on production-shaped data, not an opinion |
| Deliver Results: "with the right quality and in a timely fashion" | Led others (S5) | Meera's answer below: 410 pages a month to 160, the third team's drift said plainly |
| Have Backbone; Disagree and Commit: "Once a decision is determined, they commit wholly." | Lost and committed (S3) | Concern written down, plan followed, week-three check |
| Earn Trust: "vocally self-critical, even when doing so is awkward" | Your fault (S8) | "I now ask what if this runs twice", with a later catch |
| Hire and Develop the Best: "raise the performance bar with every hire and promotion" | Grew someone (S7) | The bar written before any name; where she is a year on |
| Insist on the Highest Standards: "problems are fixed so they stay fixed" | Incident (S2) or senior S8 | The timeout check, and the two changes it has blocked |
| Bias for Action: "Many decisions and actions are reversible and do not need extensive study." | Incident (S2) | Rolled back at minute nine, before the cause: it could be undone |
| Invent and Simplify: "always find ways to simplify" | Design decision (S1) | Three accounts on events, not a rewrite |
| Are Right, A Lot: "work to disconfirm their beliefs" | Won with data (S4) | The test that could prove you wrong, run first |
| Learn and Be Curious: "never done learning" | A spare: learnt fast | What you learnt, by when, and what it shipped |
| Think Big: "Thinking small is a self-fulfilling prophecy." | Led others (S5), senior | One rule for three teams, not one team's alerts |
| Frugality: "Accomplish more with less." | Chose not to build (S6) | What you did not build, and what that saved |
| Strive to be Earth's Best Employer: "a safer, more productive" workplace | Grew someone (S7) | What changed for the people around you |
| Success and Scale Bring Broad Responsibility: "leave things better than how they found them" | Your fault (S8) | The rule that outlived the fix |
Next stop: Building a story bank of eight, 2 min
Building a story bank of eight
Take stories from your own job; side projects rarely show conflict, because you worked alone. Interns and freshers: internships, college team projects and hackathons count, under the three tests below. Cover every competency at least twice with these eight slots.
Table: Slot, Question it answers, The twelve-month check (8 rows)
| Slot | Question it answers | The twelve-month check |
|---|---|---|
| 1 Design decision | "A decision, and what you rejected" | Still in place; the number now |
| 2 Incident you led | "Something broke on your watch" | Did the prevention hold? |
| 3 Lost, committed | "Disagreed with a decision above you" | What became of the decision |
| 4 Won with data | "Changed someone's mind" | The number still in budget |
| 5 Led others | "Led without authority" | Adoption a year on, as a count |
| 6 Chose not to build | "Something you refused" | Which assumption held |
| 7 Grew someone | "Mentored or hired" | Where they are now |
| 8 Your fault | "Your biggest mistake" | The rule still in force, times it ran |
Figure 10.2 is the method that fills it from your own history; allow ninety minutes the first time.
- Timeline. Open your calendar, pull-request history, incident tracker and performance reviews, in that order. For each job write the team, the dates and the three largest things that shipped.
- Thirty events. One line each, under prompts: an outage you were paged for; a design you chose between two ways; a meeting you lost; a launch that slipped; a person who left or grew; a thing you refused to build; a mistake you made.
- Three tests. Mine: can I say in one sentence what I personally decided? Fails if "the team did it and I was in the room". Measured: is there a number against a baseline, and can I say where it came from? Fails if I would have to guess. Scope: who besides me was affected, and what was different six months later? "Only me, and nothing" is fine at SDE-2 and thin above.
- Fill the worksheet, one row per survivor. A column you cannot fill with a fact means "needs evidence": spend ten minutes finding the number in a tracker or pager export before you drop it.
Table: Slot, Event (one line), My part (one sentence), Number, baseline, source, Who else, six months later, Done (8 rows)
| Slot | Event (one line) | My part (one sentence) | Number, baseline, source | Who else, six months later | Done |
|---|---|---|---|---|---|
| Design | |||||
| Incident led | |||||
| Lost | |||||
| Won | |||||
| Led others | |||||
| Not built | |||||
| Grew someone | |||||
| Failure |
Services-firm engineers: many events happened on a client project whose architect approved the design. Your decisions are still yours; separate them aloud: "The client's architect owned the target design. I proposed splitting the migration into three cutovers and wrote the rollback plan; she approved it after a one-hour review." Describe the client generically ("a large insurer") and check whether your contract forbids naming it. Say "I" for your decisions and credit the team in the same sentence: modesty is recorded as absence. For gaps and short stints, give one true sentence about what happened and one about what you did, then go forward.
Next stop: Five worked stories, 4 min
Five worked stories
Kavya is an INVENTED backend engineer with six years at a payments company; every number is invented. Each label is her bank slot. After each, what the page would hold.
INVENTED: S1, the option she rejected 1 min
"A reconciliation step held a lock on a shared table for about twenty minutes a day and blocked finance reports. I was asked to propose a fix. I rejected running the batch hourly, because it would double the load on the shared database and move the problem. I rejected a full rewrite: six weeks, and I had two. I chose an event-driven update for the three accounts that account for most of the lock time. Lock time on those fell to under two minutes, over one week of logs. I did not measure the other accounts, and I say so."
Page: two options rejected with costs, a number labelled with how it was measured. Reflection is thin: honest, not a change she has made.
INVENTED: S2, the rollback before the cause 1 min
"At 7:40 one evening, twenty minutes after a release I had approved, payment success fell from 98% to 91%. I was on call. At minute nine I rolled back without knowing the cause: a rollback took four minutes and could be undone, and the dashboard showed about 300 failed payments a minute. I rejected a forward fix, because I could not say what it would fix. Success was back at 98% by minute fourteen. Next morning I found the cause: a client-library upgrade had cut a bank timeout from 10 seconds to 2. I added a build check that fails any timeout change without a named reviewer; in six months it has blocked two. I now read a library's change notes before I approve its upgrade."
Page: the rollback and its reason, the forward fix rejected, a check that keeps the cause fixed and how often it has run. Probes: "Who agreed to the rollback?" and "What if it could not be undone?"
INVENTED: S3, lost and committed 1 min
"In a design review the question was whether to move a service to a new message queue. I wrote the alternative: keep the existing queue and add monitoring. The architect chose the new queue, and her reason was fair: after a reorganisation nobody owned the old one. I thought the migration risk was real, so I wrote my concern down, committed to the new plan and asked for a check in week three. The check found an ordering bug we fixed before it reached customers. I argued once; the second time I should have brought a number."
Page: the other side stated fairly, an explicit commitment, a later event showing the concern mattered. Weak spot: how many messages, if any, were affected?
INVENTED: S4, won with data 1 min
"A product manager wanted a feature in one release that added a second database call to every request. I owned the latency budget: 120 milliseconds at the 95th percentile, and we ran at 95. I measured the call on staging with production-shaped data: it added 35, so 130. I proposed two weeks to cache the call, then a launch behind a flag with a rate limit. He agreed to the delay, because I had shown him a number rather than an opinion. We shipped at 104. I would bring that measurement on day 1; the argument took four days the test would have saved."
Page: the cleanest headline in the bank and a number with its baseline and method. Probes: "How production-shaped was the data?" and "What if he had said no?"
INVENTED: S8, the retry that doubled a bank file 1 min
"This is about a change I made to a nightly payout job that sends about 40,000 payouts to the bank, and the two nights it sent the file twice. I owned the retry setting I changed, to make the job survive a slow bank connection. On two nights the connection dropped after the file was accepted, the job retried, and a second file went out. I told the operations lead and the bank's contact first, before fixing anything quietly, because they needed to know which payouts could be late. Then I made the job record the bank's acceptance, and refuse a second file for a date only once the first was accepted; a rejected file can still be resent. In the eight months since there has been no duplicate. I now ask 'what if this runs twice?' in every review. That caught the same pattern in a refund job last quarter."
Page: stakes in the first sentence; "I" on three decisions; the option rejected is the quiet fix; a stated window. Probes: "How do you know no duplicate happened since?" (the log being empty proves nothing alone. I replayed the dropped connection in staging: the second file was refused, a rejected one still resent. In production I compare the bank's daily file count with ours).
Next stop: Stories at one to two years, 1 min
Stories at one to two years
For: Intern, SDE-1.
Fill the job slots you have true events for (a task or a bug, over days) and the rest from lesson 14's five fresher slots. Learnt fast covers Learn and Be Curious; took initiative, Ownership.
INVENTED: SDE-1, the bug from month three 1 min
Tanvi (INVENTED, ten months in): "In my third month I changed the date filter on our order-history page, and orders placed between midnight and 5:30 am began to show under the previous day: my query used UTC dates, not IST. I told my lead first, because the monthly statement used the same filter and went out in four days. I wrote a failing test for an order placed at 1 am IST and fixed the query that evening. I rejected patching only the page, because the statement would still be wrong. Nineteen customers had complained. Every date change I make now has a test at the midnight edge, and last month it caught the same mistake in a refund report."
Page: "I" on each step, the narrower fix rejected, a count, a habit with a later catch. Probes: "How did you know no statement had gone out wrong?" and "Why did review miss it?"
Next stop: Scoring a story, and the level it reads at, 2 min
Scoring a story, and the level it reads at
Use Google's four levels (outstanding, solid, borderline, poor). Mark the lowest level each story clearly reaches on each row; the criteria are the author's.
Table: Criterion, What it asks, Your score (7 rows)
| Criterion | What it asks | Your score |
|---|---|---|
| Headline and stakes | The first two sentences say what it is about and what was at stake | |
| "I" for decisions | Decisions in first person; the team credited in the same sentence | |
| Option rejected and its cost | At least one alternative, with what it would have cost | |
| Number, labelled | A number against a baseline, with how it was measured, or "estimate" | |
| Reflection acted on | One change you made, with a later example | |
| Survives two probes | "What exactly did you do?" and "How did you know?" answered without restarting | |
| Scope matches your target | The story sits in your target level's row of the table below; a lead story one row smaller scores borderline, however well told |
The rubric finds your weakest row, usually the reflection; it does not predict a result. Scope is read as a level signal; the table is the author's reading of published ladders (lesson 1), not a published rule, and titles are not portable.
Table: Dimension, Intern / SDE-1, SDE-2, SDE-3 / senior, Staff, Principal (6 rows)
| Dimension | Intern / SDE-1 | SDE-2 | SDE-3 / senior | Staff | Principal |
|---|---|---|---|---|---|
| Story scope | A task, a bug or a college project; days | A feature or a service; weeks | A system or several teams; quarters | An organisation or platform; a year or more | Several organisations; years |
| Ambiguity | Asks good questions early | Clear task; asks when stuck | Turns a vague goal into a plan with a measure | Finds the problem worth solving | Frames a problem leaders had not, with a number |
| Whom you move | Yourself | Your team | Teams you do not manage | Directors; sets a standard others adopt | VPs and the CTO |
| People work | Takes feedback, asks for help | Reviews, helps joiners | Hires, grows others, raises a concern with evidence | Grows seniors; shapes a bar or ladder | Grows Staff engineers |
| Failure story needs | A mistake owned and learnt from | Own mistake, small cost, a fix | Real cost, postmortem, system change | Org-wide cost, lasting change | A bet that was wrong, found, stopped |
| Twelve-month check | What you do differently now | "Still running" | A measured number a year on | Adopted by others, without you | Still deciding new work |
For a senior loop's eleven: the eight slots, three told at senior scope (cross-team, people, a costly failure), and spares. Meera's answer below models the cross-team one; the next section models the other two.
Next stop: Two senior models: a hire, a costly failure, 2 min
Two senior models: a hire, a costly failure
For: SDE-3, Staff.
Kavya again, two years later, telling slots 7 and 8 at senior scope.
INVENTED: senior S7, a hire and what became of her 1 min
"I led a team of five with one open seat. Before we saw anyone I wrote the design question and a four-line rubric. Of eleven candidates I argued against the fastest coder, who waved away the pairing exercise, because the seat meant working in other people's code. We hired an engineer from a smaller services firm: weaker algorithms, the best debugging I saw. I gave her a 90-day plan with two milestones. A year later she owns the on-call tooling and has led a postmortem. What I got wrong: for three weeks I gave her too little, and she had to ask for harder work."
Page: a bar set before any name, a rejection with its reason, where she is a year on. Never hired? Use a loop you sat on or a junior you brought up, say your role, and give no names or personal details. Probes: "What did the rejected candidate do well?"
INVENTED: senior S8, the migration without a rehearsal 1 min
"A migration I approved made about 2,300 settlements post with a zero fee for four hours. Finance reversed them by hand, about six person-days by my estimate, and one partner's invoice went a week late. I had approved the schema change without rehearsing it on a copy; I did not know it dropped a column default. A finance analyst caught it at her midday check, and I told finance the cause that afternoon. I rejected fixing only my own review habit, because a habit fails when someone else approves. Money-table migrations now need a rehearsal on a copy, checked by a second person, and a CI check blocks any change to a default. Nine ran in the next twelve months, all rehearsed, none with an incident."
Page: impact first, her part and what she did not know, the quiet fix rejected, a system change, proof over a window. Probes: "How was the 2,300 counted?" and "Who objected to the new rule?"
Next stop: The follow-up ladder, 1 min
The follow-up ladder
Your telling is the first minute or two; the rest is the interviewer testing whether it is true and yours. The probes come in a fairly predictable order (the author's reading); an interviewer may stop at any rung.
Keep a half page per story so the telling stays short: five facts with numbers; who did what with your part marked; two options rejected and their cost; who disagreed, in their words; what happened after; one thing you got wrong. For S4: p95 budget 120 ms, running at 95; the call added 35 (staging, production-shaped data), so 130; two weeks to cache it, then a flag with a rate limit; shipped at 104; four days of argument. I measured and wrote the proposal; the PM approved; a teammate ran the load. Rejected: ship as asked (130 against 120), drop the feature (his quarter goal). He said the delay cost a launch slot. p95 stayed under budget for three releases. Got wrong: brought the number on day 5, not day 1.
Next stop: A senior answer, with the follow-ups, 2 min
A senior answer, with the follow-ups
Meera Iyer (INVENTED, nine years in) answers a common senior probe. Bracketed lines are what the interviewer would note.
INVENTED: senior model answer 2 min
Interviewer: Tell me about a time you got several teams to change how they worked when you had no authority over them.
Meera: Three teams on our platform were paged about 410 times a month between them, and about seven in ten pages needed no action. I led one of the three and had no say over the other two. I proposed one rule, that every page must link a runbook and name an owner, and two teams kept it. Two quarters later the three page about 160 times a month: mine from 150 to 40, the second from 140 to 30, and the third, which drifted back, is at about 90, down from 120. [Headline and result in the first breath, including the cost. Scope: three teams.]
Interviewer: How did you get the 410?
Meera: A pager-tool export, averaged per month and split 150, 140, 120. "Seven in ten" is an estimate: I sampled 100 pages and 71 needed no action. A sample, not a measured rate. [Measured and estimate separated unprompted.]
Interviewer: Why would the other teams listen?
Meera: At first they did not. Their best argument was fair: fewer alerts means a bigger chance of missing a real incident. So I changed my own alerts first, over four weeks, and published a table each Friday: pages, pages needing action, incidents missed. Zero missed. Then I asked their leads for a four-week trial on two noisy alerts each, revertible any time. [Influence by evidence and a small reversible ask.]
Interviewer: What did you reject?
Meera: A director's mandate, because a rule handed down is followed on paper. And a shared deduplication tool, my first idea: two engineer-months for a problem a rule and a table solved in a quarter. [Two options, one her own favourite.]
Interviewer: And the third team?
Meera: They tried it, got to about 50 a month, and drifted back. I did not escalate; their incident record showed no harm. I should have asked their lead in month two what would make the rule worth keeping. For that team a table was the wrong instrument; they needed to see a near miss. I have not gone back to fix it. [The honest partial. Do not rescue it with a tidy ending.]
Interviewer: What would you change?
Meera: On my second meeting I now ask each side "what would make you stop doing this?". I did it last quarter on an on-call handover and learned in week one that one lead feared being blamed, which changed the proposal. [Reflection acted on, with a later example.]
Gave up: a mandate's speed, the deduplication tool, the third team's full drop. Revisit when: the third team passes 120 pages a month, or a missed incident traces to a removed alert.
Next stop: Stories at Staff and Principal scope, 1 min
Stories at Staff and Principal scope
For: Staff, Principal.
Lesson 12 works the Principal failure story ("A bet that failed") and a Staff engineer grown, each with probes, and a Principal story bank. At Staff, tell the same shape inside one organisation.
Next stop: The project deep-dive: twenty minutes on one system, 4 min
The project deep-dive: twenty minutes on one system
For: SDE-2, SDE-3, Staff, Principal.
Senior loops often spend most of a round on one system you built; a Principal loop may ask for it as a talk (lesson 12). Atlassian's handbook tells manager-interview candidates to prepare "a past project or two", "from who you worked with to the technical challenges you had to overcome"; Amazon's SDE III page says to "Expect at least one question on software systems design." Neither gives a length; the twenty minutes and the probe order are the author's. A story is scored on your decisions; a deep-dive is scored on whether you understand the system well enough to have made them. The interviewer asks you to draw it, then presses on the joints, in about the order of the probes below.
Prepare one system on one page you never read aloud. Put five numbers on top, each with its source or "estimate", because the first ninety seconds should contain them: throughput, latency, data size, team size and cost. Then: purpose in one sentence; a drawing of 5 to 7 boxes you can draw in 60 seconds; your part against others'; then one line per probe below, each marked tested or reasoned, ending with one redo and its revisit trigger.
Meera's half page for an order-events outbox (INVENTED; the Figure 10.4 drawing): about 1.2 million events a day, 600 a second at a sale peak (broker metrics); order-write p99 38 ms before, 41 after (APM); relay lag p99 1.5 s, 6 s at peak; 3 engineers, 6 weeks, about Rs 60,000 a month for relay hosts (my estimate from the bill). Before: about 35 events a day missing (nightly reconciliation). After: none missing in 18 months by the same check. Rejected: change data capture (nobody ran it; about three months against six weeks) and Kafka first (the order write turns async, and checkout needs the order number at once). A relay dying mid-batch resends rows, so delivery is at-least-once and consumers drop repeats by event id.
The probes, in order, with Meera's answers shortened:
- Why a table, not change data capture or Kafka first? "Three options, each with its cost in our terms: months, or a change the user would see. The outbox cost a second write, 3 ms, and a table to clean up. I took it because it stopped the loss with tools we already ran."
- What was your part? "I wrote the proposal and the failure analysis and built the relay with Tarun. Deepa moved the three producers."
- The relay dies halfway? "Rows are marked sent only after Kafka acknowledges, so nothing is lost, and a consumer can see an event twice."
- Ten times the load? "Peak 6,000 a second. One relay did about 2,000 in a load test, so the relay is second. The database breaks first: one node takes about 1,000 write transactions a second (cheat sheet C3), so 6,000 needs partitioning first. More relays that each grab any free row would break each order's event order. On paper: hash the order id into eight buckets, one lease per bucket. Only the relay limit was tested; the buckets are a design."
- What failed in production? "Week three: two relays ran together for 40 seconds during a deploy and loyalty double-credited 212 orders. My design said 'exactly once', which I had never checked against what a consumer sees. We added a lease and an event id in every message."
- How do you know none were lost? "The same nightly check that found 35 a day. It cannot see wrong contents, only missing events, and I say so when I quote the zero."
- Cost, and who disagreed? "18 engineer-weeks, about Rs 60,000 a month, 3 ms. Farhan wanted change data capture and his argument was right: a second write on the busiest table. We settled on the outbox now and a written trigger to revisit when a second database must publish; that came at month 14."
- What would you change? "Write 'at-least-once' on day one and ship a dedupe library with it; partition the table by day from the start."
The deep-dive is lost when the fifth answer contradicts the first, so the same numbers must appear throughout. The senior signal is the line between what you measured and what you reasoned, held for twenty minutes. If the system was designed before you joined, say so first and scope your part: "I owned the relay, not the design." At SDE-2 the round usually stays on your component; at senior level expect the ten-times and who-disagreed probes.
Next stop: Drill: record yourself, 1 min
Drill: record yourself
Spoken aloud, a story that reads well runs long, loses its "I" or trails off. Record each story once, with the phone.
- Record without notes. Ask yourself the question cold, start the recorder and answer until you stop. Stop yourself at 2:00.
- Transcribe it. Use the phone's dictation or any speech-to-text. Read the text, not your memory of it.
- Mark four things on the transcript. Where the action begins, each "we" that hides a decision, each number with no source, and each filler or restart. Action should begin before 0:30.
- Score on the seven-row rubric above. Fix only the lowest row.
- Record again the next day, from the half page, not the transcript. Compare the second with the first: is the headline now in the first two sentences, and did the time fall?
Mock 1 asks: led without authority (S5), lost a disagreement (S3), a failure that cost (S8), a project you chose not to build (S6) and why this company (lesson 4's pitch); Staff and Principal add a bet that failed (lesson 12). Target: your four lead stories pass the rubric at solid on every row, in two takes, with the first action decision before 0:30. Lesson 5's readiness gate (part D) runs three mocks on this rubric, scored on the telling and again after the probes: its before-and-after rubric.
Practice with an AI: the prompt kit in the appendix has 2 cards for this lesson.
Sources
8 sources
- Amazon Jobs, "Leadership Principles", https://www.amazon.jobs/en/principles, read 31 Oct, 2 Nov and 4 Nov 2026 (sixteen principles and the quoted lines; Customer Obsession checked 4 Nov).
- Amazon Jobs, "SDE II interview prep", https://www.amazon.jobs/content/en/how-we-hire/sde-ii-interview-prep, read 31 Oct and 2 Nov 2026 (four 55-minute interviews; two or three behavioural questions each; metrics; STAR).
- Amazon Jobs, "SDE III/Sr. SDE Interview Prep", https://www.amazon.jobs/content/en/how-we-hire/sde-iii-interview-prep, read 2 and 4 Nov 2026 (five 55-minute interviews, each interviewer "will typically ask two or three behavioral-based questions"; 60-minute screen with half on Leadership Principles; "Expect at least one question on software systems design"). Names neither a hiring manager nor a bar raiser.
- Amazon, "What is an Amazon bar raiser?", https://aboutamazon.com/news/workplace/amazon-bar-raiser, no date shown, read 31 Oct and 2 Nov 2026 (objective third party, shared hiring decision, the 50% aim, helps identify which principles to test).
- Google re:Work, "A guide to structured interviewing for better hiring practices", https://rework.withgoogle.com/intl/en/guides/a-guide-to-structured-interviewing-for-better-hiring-practices, page dated "Updated March 2026", read 31 Oct and 2 Nov 2026.
- Atlassian, engineering interview handbook, https://www.atlassian.com/company/careers/resources/interviewing/engineering, read 2 Nov 2026; its values-interview link returned "not found" that day.
- Microsoft CEE Multi-Country News Center, "Preparing for the job interview with Microsoft", https://news.microsoft.com/en-cee/?p=2228, 9 Sep 2022, read 2 Nov 2026.
- The story bank, rubric, ladder, level table, minute marks, the Amazon story map, the record-yourself drill and every person, number and system in the examples (Kavya, Tanvi, Meera, the outbox) are the author's constructs and are INVENTED.