The hiring manager is the one interviewer who will still be in your life a year after the loop. Other rounds ask whether you can do the work. The manager asks something narrower: is there a funded seat, at what level would I be comfortable putting you in it, and which problem on my team does this person make smaller? Those three questions decide whether a good loop becomes an offer, and at which level.
Not advice. General information, and every example is invented.
General information, not career, legal or financial advice. No company publishes how its managers decide; the model here is the author's reading of the few company pages that exist. Every person, company and number in an example box is INVENTED and says so.
What the manager is deciding
A weak answer to any one of three questions stops an offer, even if the other two are strong.
One: is there a seat?
A seat is an approved, funded role. Three states matter: approved and open, approved but timed for next quarter, and "we are hoping to fund it". The third is not a no but a timing risk: weigh it before you plan your notice around it.
Two: at what level, and how sure are we?
The level on the seat is a scope statement. The author's reading: a wrong senior hire costs more than a wrong junior one, so doubt tends to resolve downward, and only evidence the notes can hold resolves it upward. A borderline loop can also end in no hire, or the same title with a smaller package (author's estimate, not measured). Titles are not portable between companies, so a level is not a verdict on you.
Three: which gap does this hire close?
A team can have a gap in capacity, in a skill nobody has for the next project, in seniority (nobody to set design), in timing (a launch date) or in composition. Find the gap early: ask what hurts most, and say which part of your work is nearest to it.
Next stop: Where the manager sits in your loop, 1 min
Where the manager sits in your loop
Loops come in two shapes (the author's reading). In one you interview for a single team's opening and its manager is in the loop, often early. In the other you pass a general loop and then talk to managers who have a seat at the level you earned; if none has one, there is no offer yet. Ask the recruiter: "Is this loop for one team's opening, or a general loop followed by team matching? If general, when would I speak to a manager?" If the team call is billed as a chat, prepare it as a round anyway. Lesson 4 covers a manager screen before the loop.
In the second shape the seat questions, your scorecard and the close carry it. Some loops also include an interviewer from outside the team. Amazon describes one as an objective third party who decides with the hiring manager; Atlassian's handbook describes a values interviewer who "likely won't be a member of the team you're applying to join". Ask whether your loop has one: expect one story taken apart with "why?" two or three times, so prepare fewer stories to greater depth.
Next stop: Evidence: what counts and what does not, 1 min
Evidence: what counts and what does not
Evidence comes in grades: a task (what you did), a decision (that you chose), a decision with its cost (what you gave up, which a manager can test) and scope (reach, which most level definitions turn on; lesson 1). A candidate who speaks only in the first two grades is easy to like and hard to level up.
Only the fourth row lets a manager write "scope across teams". Claim it only if it is true: a lower level that sticks beats a higher level that fails in review.
The "we" problem. In the author's reading, notes record a vague "we" as inflated, and a claim to the whole system as untrue. Say what was yours: "I wrote the design and made the two decisions I described; another engineer built the gateway, which I reviewed." For a part you did not own, reason in the open: "I do not know the exact setting; I would expect X, because of Y." Going vague on your own design is what sounds evasive.
Next stop: The project walk: ten minutes, one spine, 2 min
The project walk: ten minutes, one spine
Atlassian's handbook tells engineers to be "prepared to talk about a past project or two" in the manager interview. The trap is ten minutes of context before the first decision: notes record decisions and their costs, not context. Give the project a spine you can return to after each interruption.
The 30-minute call (Figure 11.4) gives the walk 9 minutes, probes included, so rehearse a 6-minute spine too: context 30 s, diagram 1 min, role and result 30 s, two decisions 4 min (where "why not the lock?" lands); the hardest problem waits until asked. "How much was you?" (30 s) and "what breaks at ten times?" (2 min) add 2.5 minutes: 8.5 in all, 30 s spare.
Choose a project where the design calls were yours, with a real trade-off, a failure and numbers you can defend. Prepare a second that shows a different strength. Prepare each of your two decisions as the same six lines, on paper, before the call.
INVENTED example: a filled decision card 1 min
Meera Iyer (invented), nine years in, built a settlement-matching job at an invented company, Finlane. All numbers are invented.
DECISION How to make a rerun of a match run safe
OPTIONS (a) a lock so only one run proceeds
(b) idempotent upserts keyed on partner file + line
(c) delete-and-reload the day's rows
CHOICE (b)
WHY Reruns happen after late partner files, up to 3 times
a month. A lock would block the second run; delete-
and-reload left a 4-minute window of no data
COST One key per record: 1.2M lines x 365 = about 438M keys
a year, 13-26 GB depending on index overhead. Needed a
clean-up job at 13 months
HINDSIGHT Same choice today. If reruns became rare I would take
the lock: simpler, and the storage cost is real
Said aloud this takes about two minutes. The last line, the condition under which she would choose differently, is what a manager reads as judgement. Storage is a range because 30 bytes is only the key; say the floor, the ceiling and which you would plan for.
End the project with one bridge to their work ("your move to real time looks like the cutover we did; the part I would watch is the part that hurt us"). One bridge is enough; three sounds rehearsed. Then give two minutes to your hardest problem: how you found it, what you did, a number before and after, one thing you would do differently.
Next stop: The depth probe: what breaks at 10x, and why not X, 2 min
The depth probe: what breaks at 10x, and why not X
At SDE-3 and above the manager goes one level into the system you just described: "what breaks at ten times the load?", "walk me through the failure modes", "why not X?". These test whether you know your design's limits as numbers (author's reading). Use five lines as the shape.
Code, 6 lines
LOAD today's number, with a unit (lines a second, not "a lot")
BOTTLENECK the first thing that fails at 10x, and why that one
MEASURE the test that would show it, before building anything
NOT YET what you would deliberately not build, and the signal
that would change your mind
FAILURES two failure modes and what the design does for eachINVENTED example: a probe and a push-back 2 min
Manager: Your matching job is fine today. What breaks at ten times the volume?
Meera: Partner files land in a six-hour overnight window, about 1.2 million lines matched as each file arrives, roughly 55 a second; ten times is 550, which the database writes without trouble. The first thing I expect to fail is the key index: 13 months of keys, 14 to 28 GB, becomes 140 to 280 GB, and the database has 64 GB of memory. I would test it by replaying a month-end file at ten times into a copy, then a rerun, and plot p95 upsert time and cache hit rate against table size. I would not shard by partner now: two quarters of routing work for a limit we are not near. I would revisit when the key table passes 40 GB or p95 upsert time doubles. Two failures I plan for: a partial file after a failover, which is why reruns must be safe, and a poison file, which goes to a dead-letter folder with an alert and does not block the night's other files (about 400 a night).
Manager: Your keys are mostly new each night. Is the whole index really hot?
Meera: Probably not, and I should not have implied it. A night's new keys land at the end of each partner's range, so those pages stay in memory. Old pages are read on a rerun or a resent file. So I would measure the working set, with a normal night and a rerun night kept apart. If a normal night at ten times stays above 99% cache hits, the rerun is the first limit, not the index. Then I plan for the rerun and do not buy 256 GB of memory.
Annotation: the push-back is the real test. The answer concedes the point, names the measurement that settles it, and says what changes if it goes the other way. The weak version is "we would add more instances and Kafka".
For "why not X?" use the decision card's shape: the constraint that ruled X out, what X would have given you, and the condition under which you would pick it. If you did not consider X, say so and reason about it now; that beats inventing a past deliberation.
Next stop: When the manager's slot holds a problem or a design, 3 min
When the manager's slot holds a problem or a design
For: SDE-1, SDE-2, SDE-3, Staff.
Some loops put a technical problem inside the manager's round. In India a single team's manager round is often called "techno-managerial" (author's reading): the project walk, the depth probe, the people half and 20 minutes of a problem. Ask the recruiter in writing: "Will the hiring-manager round include a coding problem or a design question, and how long is it?" If the answer is "it depends on the manager", prepare 20 minutes of each. A coding problem is lesson 6's round in less time: ask 2, plan 3, code 10, trace 3, one follow-up 2 (author's split). Cut the follow-up first and the trace last, because an answer nobody tested is the easiest to mark down.
A design here is a 20-minute lesson 8 round. Use the depth-probe lines as the spine, and let one choice, one rejected option and its cost carry it.
INVENTED example: 20 minutes of design in the manager's round 2 min
An invented manager, Arvind, near the end of a 60-minute call: "One show, 10,000 seats, 1,000 booking requests at the same moment. Hold seats safely, and do not keep anyone waiting long." The candidate is invented too, Neha Kulkarni.
CLARIFY "Specific seats, or any four together? How long may a
customer hold seats before paying?" Specific, up to 4
side by side, one minute.
LOAD "About 4,000 seat checks on 10,000 seats, in a burst."
BOTTLENECK "Not the load. The risk is two requests winning one
seat, a request holding 3 of its 4, or a hold lost
between the click and the payment."
REJECTED "One in-memory lock for the whole show. Fast: four
checks take microseconds, so 1,000 requests clear in
about 10 ms. Rejected for what it loses and where it
runs: a restart drops every hold mid-payment, and the
lock lives in one process, so no second server can
take over."
SHAPE "Holds are database rows. One transaction locks the 4
seat rows in seat order (no deadlock) and holds them
only if each is free or expired; fewer than requested,
roll back and answer 'taken'. A commit is about 2 ms:
behind one show lock, 2 s for the 1,000th person;
with row locks, different seats commit side by side."
HOT SEATS "If the burst wants the same front row, waiting row
locks queue like the show lock, and every waiter
holds a database connection. So lock with NOWAIT,
or a 50 ms lock timeout. NOWAIT answers 'taken' at
once, even if the holder rolls back; the
timeout, within 50 ms. The connection
pool is the ceiling."
MEASURE "Fire 1,000 requests at once, half at the same four
seats; check no seat went to two people, repeat; then
kill the server mid-burst and check every hold
survived. A pass is not proof, so I would break the
code on purpose and watch the test fail."
NOT YET "A cache or a queue in front of the database. One
database takes this burst; I add one if commit p95
passes 50 ms under the test."
FAILURES "A restart: holds survive, they are rows. An unpaid
hold expires after a minute. A payment that lands
after expiry: the sale is written only if the hold
id still matches; if not, refund and say so."
ROLLOUT "Behind a flag on one small show; watch holds that
become sales. The rollback is the flag."
Gave up / revisit when: the in-memory lock's speed, for holds that survive a restart; revisit if commit p95 under the burst passes 50 ms, then add the cache or queue (NOT YET above). The microsecond and 2 ms figures are the author's estimate (not measured); time your own database's commit.
Next stop: Down-levelling: how it happens and how to answer, 1 min
Down-levelling: how it happens and how to answer
The goal: keep the level you earned, or learn why you did not, without damaging the relationship. First ask whether you are offered a lower level or the same title for less. Then the author's sequence:
- Ask for the definitions of the offered level and the next one, to see which skills the loop did not see.
- Argue the evidence, not the number: which round you think was mis-scored, and what scope evidence you can add in a day or two. "Which part of the next level's scope did you not see in my design round?" is answerable. "Can you do better?" is not.
- Talk to the hiring manager if you disagree, and decline if you still do.
- Settle the level first, then pay (lesson 13): level compounds into every later raise. If you accept the lower level, ask for a written re-level date.
INVENTED example 1 min
The call. Recruiter: "The team would like to offer you the level below the one you interviewed for." Candidate: "Can I see the definition of that level and the next one? And can I speak to the manager about which part of the next level you did not see?" She neither refuses nor accepts on the call.
A day later. "I read the definitions. You did not see scope across two teams in my project round. I ran the migration across the reporting and billing services, with a named owner for each. Could that be considered in the levelling review?" Manager: "That is fair. I will raise it with the panel." The candidate named the gap, offered evidence and asked for a process, not a number.
Next stop: Why you are leaving, why this team, GCC or product, 1 min
Why you are leaving, why this team, GCC or product
A leaving reason is scored on what it says about you: a pull towards something is safe; a push away is safe if it is about scope or learning and stated without blame. The sentences below are invented; lesson 4 holds the recruiter version.
Table: Question, Weak, Stronger (invented) (4 rows)
| Question | Weak | Stronger (invented) |
|---|---|---|
| Why leaving? | "My manager is bad and the pay is low." | "I have owned one system for three years. I want a team where the problems are not already solved, and yours is moving settlement to real time." |
| Why us? | "Great brand." | "You said one outage a quarter comes from partner files. I fixed a version of that and would like to do it at your volume." |
| GCC or product? | "GCCs are stable." | One true reason that is about the work, not the safety: who the users are, or what you want to own. |
| Short stint, or a layoff? | Silence, blame, or hiding it. | The fact, the dates, and a reference: "The project was cut in month four; I stayed six months to hand it over. My manager there will confirm." |
Say only what a reference would back, and never criticise an employer by name: the manager hears how you would talk about them.
Next stop: The SDE-2 track: what changes, what to skip, 2 min
The SDE-2 track: what changes, what to skip
For: SDE-1, SDE-2.
The same three questions, at the SDE-2 column of lesson 10's level table, with less time on people and strategy (author's reading). Ask the recruiter how long the call is.
Table: Part of the call, At SDE-2, do this (5 rows)
| Part of the call | At SDE-2, do this |
|---|---|
| Project walk | One feature or service over weeks, your own part named, one decision card (Rohan's below); the why-not probe still comes. |
| People | Reviews and helping a new joiner; a weak performer only as a peer: what you did, and when you told your lead. |
| Failure | Your own mistake, a small cost, the fix, and the test that stops it coming back. |
| Approach question | The same shape on a smaller system; say what you would ask your lead, not decide for the organisation. |
| Your manager: a disagreement, and "IC or manager?" | The disagreement in their terms, your data, what you did when you lost; one true track and your steps toward it. Trap: being simply right, or "whatever the company needs". |
Skip the people-scope table and the director section. Answer "how would this scale?" in three lines (today's load, one bottleneck, one failure mode), not five. Keep the evidence ladder, the decision card and the questions you ask back. A 30-minute SDE-2 plan (author's): their team 3, your pitch 2, project walk 12, people and a failure 5, an approach question 4, your questions and close 4.
INVENTED example: an SDE-2 decision card and a three-line scale answer 1 min
Rohan Das (invented, three years in) built order export for merchants on an invented seller platform; numbers invented.
DECISION How a merchant downloads a year of orders as a CSV
OPTIONS (a) build the file inside the request
(b) a background job that emails a link
CHOICE (b); the job and file format were mine, the email
template a teammate's
WHY The largest merchant has 200,000 orders; (a) took
41 s in a test, and the gateway times out at 30 s
COST A job table, a "preparing" screen, files deleted
after 7 days; three extra days of work
HINDSIGHT Same choice. Revisit when: if most exports stay
under 5,000 rows, build those inline
Manager: How would this scale?
Rohan: About 300 exports a day, 60 in the month's first hour. At ten times, the first thing to hurt is the job's read on the orders table in that hour, slowing checkout, so I would move exports to the read replica. The failure I plan for: a job that dies halfway restarts, and writes under a temporary name, so a half file is never linked.
Annotation: one feature, his part named, one rejected option priced, then load, bottleneck, failure. That is the SDE-2 bar.
Next stop: People scope: what the manager probes at SDE-3 and Staff, 1 min
People scope: what the manager probes at SDE-3 and Staff
For: SDE-3, Staff.
From SDE-3 the people half carries as much of the level note as the project (author's reading). At Staff each row moves one step out: the person you grew is a senior, the incident crossed teams.
Table: Question, What they read, Evidence that lands, Trap (5 rows)
| Question | What they read | Evidence that lands | Trap |
|---|---|---|---|
| Mentoring: "Who have you grown, and how do you know?" | Whether people improve near you | One person, a measured outcome in them, a method that is not presence, your own miss (Meera's answer below); at Staff, a senior who now leads designs | "I was always available." |
| A weak performer, as a lead without reports | Whether you act early and fairly | Talk to them first, agree one dated expectation, offer help, then tell their manager what you saw, not a verdict | Their manager first, or doing their work quietly |
| Hiring: "What do you write down when you interview?" | Whether you can hold a bar | Loops run, the signal you look for, a time a debrief changed your vote | "I can tell in five minutes." |
| Cross-team or product: "A team you depend on says no"; "product wants the feature, you want the debt fixed" | Influence without authority; pricing quality | Their constraint in their words, each option's cost in hours or incidents a month, both views on one page if it goes up | Escalation as the first step; "quality always comes first" |
| On-call: "An incident you led?" | Ownership after launch | Minutes to detect and to mitigate, your first call, the postmortem action you owned and whether it shipped | Blame, or actions with no owner |
The disagreement with your manager, asked at every level, is in the SDE-2 track's table.
Next stop: A full hiring-manager round, annotated, 4 min
A full hiring-manager round, annotated
One senior call between an invented manager, Salma Rao, and Meera Iyer (invented, nine years in), compressed. The bracketed lines are what the manager writes.
INVENTED example: a senior hiring-manager round (transcript) 4 min
Salma: The team first. We own payments callbacks and partner settlement, eleven engineers, two seats open.
Meera: What hurts most today?
Salma: Lost callbacks, about three a month, and the retry rules live in one engineer's head.
[Notes: asked before pitching. Two facts she can reuse.]
Meera (pitch): I build settlement and callback systems. I moved partner-settlement matching from a nightly job to incremental runs, and ran a service that handled 400 partner files a night. The retry and recovery part is closest to your lost callbacks. I also grew one engineer from SDE-1. I want this seat because the callback path is where I would own the whole failure story.
[Notes: system, proof nearest the team's problem, why this seat. Under a minute.]
Salma: The thing you are proudest of in the last two years?
Meera: The move to incremental runs. A typical file went from 14 hours to confirmation in about 9 minutes, and breaks stayed flat at about 30 a month. The cost was a fourth on-call rotation, and I would not call that free.
Salma: You chose upserts over a lock. Why not the lock?
Meera: [the decision card: reruns up to three a month; a lock blocks the second run; 13 to 26 GB a year in keys; the lock if reruns become rare.]
[Notes: rejected option, constraint, cost, a condition for the opposite choice. Level-note material.]
Salma: How much of this was you?
Meera: The design, the key scheme, the rollout and four weeks on call were mine. The file parser was a teammate's, the finance sign-off my manager's. I led two engineers; I did not manage them.
Salma: What breaks at ten times the volume?
Meera: [the five lines: 55 to 550 a second; the key index passing memory; a replay test; no sharding until the key table passes 40 GB; a partial file after failover.]
[Notes: load number, first bottleneck, measurement, a thing not built yet, a failure mode. Senior depth.]
Salma: Tell me about someone you grew.
Meera: Karan, an SDE-1 who could ship tickets but not choose between two designs. I gave him the retry queue and one rule: he writes the one-pager, I ask questions and do not write the fix. Review comments on his changes went from about eleven to four in six months, and in month five he ran the queue migration alone. I over-explained for two months and he stopped asking; I started every one-to-one with his questions.
Salma: How do you know it was you and not just Karan?
Meera: I do not, fully. Review count is a proxy. The method changed when I stopped answering for him, and his promotion write-up quoted the migration, not my help.
[Notes: concedes the limit of her evidence. Strong.]
Salma: Product wants the retries changed before a launch in four weeks. You think it needs six. What do you do?
Meera: I take the date as real and bring a range, six weeks, maybe eight, because retries touch the ledger. Then two options in writing: the launch partner only in four weeks with the rest after, or everything in six. The PM picks; I say what each costs.
Salma: How would you approach moving our callbacks to a queue, one quarter, four engineers?
Meera: Is latency also a complaint, and what are the limits? (Lost callbacks first; no new vendor; a freeze at quarter end.) Then done means no callback lost in a day, p95 under 30 seconds. Two shapes: a queue with a dead-letter store, or retries in the sender. I take the queue if we have an owner for the dead-letter store. Run both paths side by side for two weeks, move the smallest partner first, keep the old path until week ten. If it slips I cut the dashboard, not the comparison.
Salma: And if it slips by a month anyway?
Meera: I tell you in week six, not week eleven, with the partners that have moved and those that have not, and ask whether the freeze is firm. I would not drop the shadow run.
Meera (her turn): If it goes well, what does year one look like? And what would make you doubt me after this call?
Salma: The doubt: you have not run a team with reports. Year one is the callback path with two engineers.
Meera: Fair. I have mentored one engineer and handled a missed-sprint case as a lead, and Karan's manager can be a reference. Is that the gap you want closed?
[Notes: asked for the doubt, got one, answered with evidence, not defence.]
What the manager files: seat yes (the callback path). Level SDE-3, supported by two decisions with costs, a lead role with exact credit and a people example with a conceded limit. Gap closed: callbacks. Doubt: formal reports.
Pay ("current and expected?"), notice and buyout questions: lesson 2 has the rules and scripts. A counter-offer, and everything after the round: lesson 13.
Next stop: Staff and Principal: a director or VP in the manager's seat, 3 min
Staff and Principal: a director or VP in the manager's seat
For: Staff, Principal.
At Staff the manager is often a director (lesson 12's skip-level table has the questions). This exchange adds one India centres often ask (author's reading): getting a say in decisions made at head office.
INVENTED example: a Staff candidate and a director 1 min
Director: What would you do in your first 90 days?
Vikram (invented, 13 years in): First, which decision is waiting for this seat? (Three teams run their own retry libraries: keep or merge.) Month one is a count: retry paths, owners, incidents a quarter each. By day 45 a shared dashboard ships, so the three teams argue from one set of numbers. By day 60, a one-pager with "do less" as option A, which the three leads review before you see it. No re-architecture this quarter.
Director: Two of those teams decide at head office, hours behind us. How do you get a say?
Vikram: In writing, early: the page goes out two days before their design review, and I ask for fifteen minutes in it, their morning, my evening. If they decide without me, I ask for the reason in writing and keep counting.
Director: And if the leads say no?
Vikram: Option A ships: the dashboard, with the incident count each quarter. If it does not fall in two quarters, the data makes the case, not me.
[Notes: asked for the decision before planning; measured before proposing; a written route into a decision made elsewhere; a plan for losing.]
The Staff call and a decision at scope
For: Staff.
The Staff bar needs one decision card from Figure 11.2's fourth row. Vikram's, once he has counted:
INVENTED example: a decision card across teams 1 min
DECISION Three teams' retry libraries: keep three or merge
OPTIONS (a) keep three, add one shared dashboard (do less)
(b) merge into the cards team's library; the
platform team owns it
(c) move retries into the queue service
CHOICE (b), once (a)'s dashboard has a quarter of counts
WHY 9 retry incidents a quarter, 6 from one library's
missing backoff; (c) puts three teams on a queue
nobody runs yet
COST Payments 160 h and lending 120 h to move; half a
platform engineer to own it
OWNER Platform owns the library; each team its retry
rules and alerts
REVISIT Incidents not halved two quarters after the merge,
or a team needs ordering the library lacks: (c)
Director: How do you grow a senior? Vikram: Divya wrote clean code and avoided design reviews. I handed her the merge's design, not its code, and came to her first two reviews only. By month four she ran the cross-team review; she leads the queue work now.
Director: What did you decide not to do? Vikram: Option (c) this year: it fixes ordering nobody has asked for, at a quarter of three teams' time.
Drill, Staff version. A partner plays a director for 30 minutes: team and pitch 3, first 90 days 3, the head-office route 2, the card as your project walk with two decisions and "why not (c)?" 8, ten times from today's load 2, a senior you grew 4, what you decided not to do 3, the doubt and close 5. At Staff the doubt is usually reach ("your work stayed in one team"); answer with the hours on teams you did not run.
Principal: lesson 12 has the worked "A bet that failed" with the VP's probes, a VP conversation on the business, a worked CTO call with its minute plan and drill, and a Staff engineer grown.
Next stop: Questions to ask the manager, 1 min
Questions to ask the manager
Table: Ask, What it tells you (4 rows)
| Ask | What it tells you |
|---|---|
| "Is this seat approved and open now, or timed?" | Question one: a timing risk against your notice period. |
| "What hurts most on the team today?" | Question three: the gap you can name in your close. |
| "What does year one look like at this level?" | The level in the manager's head. |
| "What would make you doubt me after this call?" | The reservation, while you can still answer it. |
Close with interest, one reason and the doubt, as Meera does above. Never leave without asking for the doubt.
Next stop: Practice and a rubric, 2 min
Practice and a rubric
Drill: a recorded 30-minute call. A partner plays Salma and asks her probes, in order, about your project: proudest work, why not the rejected option, how much was you, ten times, someone you grew, "how do you know?", a slipped date, an approach question, "and if it slips?". Keep Figure 11.4's minutes (SDE-1 and SDE-2: the SDE-2 plan) and stop at 30:00. Score the recording within the hour, not your memory. Next day, redo only the block with the longest pause. The rubric is the author's construct, not any company's; tick only what the recording shows.
Table: Box, Marked up, Marked down, Seen (7 rows)
| Box | Marked up | Marked down | Seen |
|---|---|---|---|
| 1 Seat, level, gap | Asked if the seat is open and what hurts most, before pitching | Pitched before asking anything | |
| 2 Two decisions | Each with a rejected option, constraint, cost and revisit condition | "We used Kafka because it is scalable" | |
| 3 Credit | Your part, a teammate's and your manager's named | A vague "we", or the whole system claimed | |
| 4 A number | A before and an after, with a unit | "Much faster" | |
| 5 Ten times | The five lines (SDE-1, SDE-2: three) from today's load as a number | "Add instances and Kafka" | |
| 6 Push-back | Conceded, with the test that settles it and what changes | Defended, or dropped without a test | |
| 7 The doubt | Asked for, and answered with evidence | Not asked, or argued with |
The bar by level (author's estimate, not measured). SDE-1 and SDE-2: 6 of 7, decisions at feature size, like Rohan's. SDE-3: 6 of 7, plus a people answer from the table's evidence column. Staff: all 7, one decision at scope across teams (Figure 11.2's fourth row). Principal: all 7, one decision adopted by several organisations and still followed by every new system (lesson 12's Reach row), plus the bet that failed. Two clean calls at your bar, different partners and days, is lesson 5's gate line.
Practice with an AI: the prompt kit in the appendix has 2 cards for this lesson.
Sources
3 sources
- Atlassian, "Atlassian engineering interview handbook", https://www.atlassian.com/company/careers/resources/interviewing/engineering, no publication date shown, read 2 Nov 2026 (the company's own page). Used for the manager interview, preparing a past project or two, the values interviewer outside the team, and saying so when you do not know.
- Amazon, "What is an Amazon bar raiser?", https://aboutamazon.com/news/workplace/amazon-bar-raiser, no publication date shown, read 2 Nov 2026 (the company's own page). Used for the objective third-party interviewer who decides with the hiring manager.
- Not sourced, so the author's reading: how managers decide, the three questions, the evidence grades, the call plans, the rubric, the people table and every figure in an example box.