The Same Story, Wrong Frame

A candidate I once worked with had a strong banked story about leading a payments database migration. They had told it well in three onsites and gotten three offers. Then they used the exact same telling for a staff-level role at a much larger company, and they were rejected with the feedback 'good engineer, not yet at the staff bar'.

Nothing was wrong with the underlying work. The work would have cleared the staff bar at most companies. What was wrong was the framing. The story they told emphasised the things that score for an L4 to L5 IC: I picked the right option, I executed the canary, I was on-call when it broke, I shipped on time. Those are real signals. They are not the signals a staff interviewer is grading on. A staff interviewer wants to hear: what was the second-order risk you saw that nobody else saw, what was the principle you established that other teams reused, how did you change the way the org thinks about migrations going forward. The same project contained those signals; the candidate just did not surface them.

This is the gap that this lesson closes. You already have your stories. You already have your numbers. What is missing is a framework for reframing the same story so it lands on the role and level you are actually interviewing for.

The Two Axes: Level and Surface Area

Reframing happens along two axes:

[ Level ]         L3 / L4 / L5 / L6 / L7+         (IC ladder seniority)
[ Surface area ] Frontend / Backend / Infra / ML / Full-stack / Platform / etc.

Level determines what kind of impact the interviewer is looking for. Surface area determines what kind of detail and craft they want to hear about. The same story can move along both axes with light reframing of the opening sentence, the conflict beat, and the resolution.

There is also a third, weaker axis worth naming: company stage (startup, scale-up, big-tech). It usually correlates with one of the first two but it sometimes diverges, and it is worth knowing when it does.

Axis 1: Level Signals

Most engineering ladders, despite different rubric labels, grade on roughly the same dimensions, with the weights shifted as level increases. A useful approximation:

L3 (junior IC)         Execution, learning, takes feedback
L4 (IC)                Owns features end-to-end, moderate scope, technical judgement
L5 (senior IC)         Owns systems, leads projects, mentors, surfaces trade-offs
L6 (staff IC)          Cross-team scope, multi-quarter strategy, taste, principles
L7+ (principal/staff+) Org-shaping, second-order thinking, raises the bar for others

The shift is not 'more impact' as you go up. The shift is in what kind of impact gets credit. An L5 gets full credit for 'I led the migration and the system was much better afterwards'. An L7 gets diminishing credit for the same sentence because the implicit comparison group is different. They want to hear: did you see the failure mode coming, did you ship a principle other teams use, did you raise the bar of how the org operates going forward.

Four level-specific signals to surface (or not) in the same story:

L3 to L4 (early IC) framing. Lead with execution and learning. 'I owned the implementation', 'I worked closely with my tech lead', 'I learned how to run a canary rollout I had not done before'. Show ownership of a defined scope and willingness to absorb feedback. Do not over-claim org-level impact. Stories about taking direction well, asking the right questions, and shipping reliably are exactly right.

L5 (senior IC) framing. Lead with technical judgement and project leadership. 'I considered three options and chose the read replica because it was reversible', 'I drove the cross-functional sign-off', 'I mentored the L3 on canary best practices during the rollout'. Show that you operate above feature-level scope, surface trade-offs, and lift the people around you. The classic 'I led a complex technical project' story belongs here in its full form.

L6 (staff IC) framing. Lead with second-order thinking and cross-team effect. 'The principle we established (canary at 1% with automated rollback on lag SLO) was adopted by two other teams the next two quarters', 'I anticipated that the per-merchant queue would be needed because we had seen similar fairness problems on the search team's migration the prior year', 'I changed how our team scopes migration work going forward'. Show that you see further than the immediate project and that your work changes other people's work. Process and principle outscore execution at this level.

L7+ (principal/staff+) framing. Lead with org-shaping and bar-raising. 'I made the case to leadership that we needed a migration playbook the company did not have, and I wrote it', 'I changed the way the platform org thinks about reversibility in migrations', 'In retrospect, the most important thing I did was establish the precedent that read replicas were the default for any reconciliation-class system'. Show that you are not just a strong engineer with bigger projects, you are reshaping how the larger system around you operates.

A useful self-test: read your draft answer and ask 'is the most senior version of me telling this story, or is the version of me from two levels ago?'. If you are interviewing for L6 and the answer reads like an L4 execution story, the rubric will discount you. The conflict and reflection beats are usually where you can shift the level without inflating the underlying work.

Axis 2: Surface Area Signals

Different specialties grade behavioral answers on different texture. The same Action paragraph that scores well for an infra interviewer can score poorly for a frontend one because the details that matter are different. Five common surface areas and what each weights:

Frontend. UX empathy, cross-functional fluency (design, PM, copy), accessibility, performance under real-world conditions, browser and device variance, working with non-engineering stakeholders. Stories should mention design partners, user research, accessibility audits, perceived-performance metrics, browser-specific issues. A frontend candidate telling the migration story should highlight the customer-facing surface (no visible incidents, latency reduction at the user level, the rollout coordination with product and CX) more than the database internals.

Backend / infra. Reliability, scale thinking, on-call discipline, blast radius, reversibility, observability, postmortem habits. Stories should mention SLOs, p99 latency, traffic patterns, dependency graphs, rollback strategies, on-call rotations. A backend candidate telling the migration story leans into the canary mechanics, the lag SLO, the per-merchant queue, the rollout discipline. Internals are the point.

ML / data. Experimentation, data quality, ambiguity tolerance, ethics, model lifecycle, end-to-end ownership of pipelines. Stories should mention training data sources, evaluation metrics, A/B test design, drift, label quality, downstream consumers of features. An ML candidate telling the migration story would frame it as a data infrastructure migration, focusing on the feature pipeline guarantees, drift monitoring, and how downstream model retraining schedules were affected.

Full-stack / product engineering. Breadth, product sense, end-to-end ownership, customer outcomes. Stories should mention product hypotheses, end-to-end shipping (database to UI), measurable customer metrics, willingness to work across the stack. A full-stack candidate telling the migration story emphasises the customer outcome chain (reconciliation latency to revenue reporting on time), and probably also mentions a piece of UI or admin tooling work that was part of the project.

Platform / developer experience. Internal customer empathy, leverage thinking, abstraction taste, adoption metrics. Stories should mention internal teams as customers, adoption curves, migration ergonomics, documentation, deprecation handling. A platform candidate telling the migration story leans heavily on the playbook reuse outcome (two later migrations adopted the canary pattern) because that is platform-level impact.

Notice that none of these reframings change the underlying work. The candidate did the same migration. They emphasise the parts that signal the right surface area and skim the parts that do not.

Reading the Job Description for Signals

The job description is the cheapest, highest-signal artifact you have for tailoring. Most candidates skim it for required years of experience and tech keywords. Use it instead as a competency map.

Four passes through a JD:

Pass 1: Find the level signals.

Look at the verbs in the responsibilities section:

• 'Implement' or 'contribute' = L3 to L4 weighting
• 'Own', 'lead', 'drive' = L5 weighting
• 'Define', 'establish', 'influence across teams' = L6 weighting
• 'Set strategy', 'shape the org', 'raise the technical bar' = L7+ weighting

Match the level you are interviewing for to the verbs the JD uses, and reframe your stories with the same vocabulary.

Pass 2: Find the surface area signals.

Look at the listed technologies, the products mentioned, the team description. A JD that mentions 'design partners', 'accessibility', and 'cross-functional collaboration' is asking for frontend competency-blocks even if the role is technically full-stack. A JD that mentions 'on-call', 'incident response', and 'distributed systems' is asking for backend / infra competency-blocks. Tailor the texture of your stories accordingly.

Pass 3: Find the values signals.

Most JDs include phrases that map directly to the company's behavioral rubric. 'Bias for action', 'high ownership', 'customer obsession', 'craftsmanship', 'rigor', 'move fast', 'long-term thinking'. These are not filler. They are the labels the interviewer's rubric will use. Pick the two or three that show up most prominently in the JD and make sure at least two of your top stories explicitly demonstrate them.

Pass 4: Find the gaps you can probe.

If the JD mentions a competency you are weak on, that is a place where the bar will be high in the interview. Either bank a story specifically for that competency or be ready to acknowledge the gap honestly with a credible plan to close it.

A single 30-minute pass through the JD before each loop, with notes on which of your stories map to which signals, is one of the highest-leverage prep moves available to you.

Worked Example: The Migration Story, Three Ways

Using the canonical anchor story (Q2 2024 FintechCo, single Postgres to read-replica reconciliation, p99 47m to 9m, eight weeks, 12M transactions per month, per-merchant queue retrofit), here are three reframings for three different role-and-level combinations.

Telling 1: Mid-level frontend role at a high-growth startup (L4-equivalent)

The candidate is interviewing for a frontend engineer role at a 200-person company. The JD emphasises 'shipping end-to-end with design and PM', 'craftsmanship in user-facing surfaces', and 'comfort with ambiguity'. The role is not pure backend, but the candidate's anchor story is a backend migration. Can it still work? Yes, with reframing.

'In Q2 of 2024 I was on the payments team at a 300-person fintech. We processed about 12 million transactions a month. Our reconciliation pipeline ran on a single Postgres box, and finance was forecasting traffic to double the next quarter. I was a senior engineer on a small team, and the migration touched our internal admin tooling that finance and customer-support used to investigate transactions. I owned the user-facing slice of the migration: the admin search experience, the per-merchant filter, and the feature flag UX for the rollout.

The interesting part was the rollout coordination. We were canarying the new replica at 5%, but the admin tooling needed a consistent view, otherwise CX agents would see one transaction state in one ticket and a different state in the next, depending on which canary bucket the request landed in. I worked with our designer on a small banner UI that showed the data freshness state to CX, and I added a sticky-bucket cookie on the admin app so a single agent always saw a consistent slice. I also ran two 20-minute walkthroughs with the CX team before each canary step so they knew what to expect.

We finished in eight weeks with zero customer-visible incidents and zero CX-reported confusion, against my prior assumption that the rollout would generate at least a handful of confused tickets. The freshness banner pattern got reused on two later admin tooling launches by the same team. The thing I would do differently is talk to CX in week one, not week three; I assumed the migration was a backend-only project for too long, and the user-facing slice was not as small as I had estimated.'

What is happening: the candidate has the same underlying migration story but frames it from the user-facing surface. The conflict beat is the rollout coordination, not the database choice. The numbers are the same (eight weeks, zero incidents) but the new metric (zero CX confusion) is the one a frontend interviewer cares about. The reflection lands on a frontend-relevant lesson (talk to user-facing stakeholders earlier).

Telling 2: Senior backend role at a big-tech company (L5 to L6 boundary)

The candidate is interviewing for an L6 backend role. The JD emphasises 'driving cross-team initiatives', 'establishing technical patterns others reuse', and 'long-term thinking'. The interviewer is a staff engineer.

'In Q2 of 2024 I was the technical owner for migrating our reconciliation pipeline off a single Postgres instance, with a forecasted 2x traffic ramp in Q3 and a non-negotiable revenue reporting deadline. The interesting part for me, looking back, is not the choice of read replica. The interesting part is that we did not have a migration playbook at the company, and the team before us had had a bad migration experience the prior year that everyone still talked about, but nobody had abstracted the lessons into anything reusable.

So I did two projects in parallel. One was the migration itself: read replica, partitioned reconciliation queries by date range, canary at 5% behind a feature flag with a 5-minute lag SLO and automated rollback. On day three of canary, lag exceeded the SLO. I had a 20-minute decision: roll back and lose two weeks, or push through. I pushed through, but added a per-merchant queue to smooth the load, because I had seen a fairness problem like this on the search team's migration the prior year and assumed it would re-emerge here. It did. The queue absorbed it.

The second project, which is the part I am more proud of in hindsight, was that I wrote up the canary playbook (5% then 25% then 100%, lag SLO with rollback automation, per-merchant fairness review for any partitioned workload) as a one-page doc and walked it through infra leadership. Two other teams adopted it for their own migrations in the next two quarters. We finished the migration in eight weeks with zero customer-visible incidents, p99 dropped from 47 minutes to 9 against an internal SLO of 15, and the canary pattern is now the default for that class of work at the company.

The thing I would do differently is invest in the per-merchant queue from day one rather than retrofitting it during canary. The deeper lesson, which is the one I have applied since, is that any partitioned migration needs a fairness check before the canary starts, not after. I have made that a default in the playbook.'

What is happening: the candidate is foregrounding the principle and the cross-team adoption (L6 signals), not just the project execution (L5 signal). The fairness lesson generalises beyond this project, which signals taste and second-order thinking. The reflection is written as a principle that has been adopted, not a one-off learning.

Telling 3: Staff platform engineer role at a developer infrastructure company (L7-equivalent)

The candidate is interviewing for a staff role on a platform team. The JD emphasises 'set technical direction across the org', 'raise the bar of how the platform org operates', and 'multi-quarter strategy'. The bar is high.

'In Q2 of 2024 we had a class of system at the company (reconciliation-style nightly batch pipelines) running on single Postgres instances, and the engineering org was about to hit the wall on it because we were onboarding two large marketplace customers and traffic was forecasted to double across the year. I was the technical owner for the most acute one, the payments reconciliation pipeline, but the actual problem was a class problem, not an instance problem.

I made two calls early. The first was to do the immediate migration with the most reversible option I could justify (a dedicated read replica with date-partitioned queries, canary at 5% with a 5-minute lag SLO and automated rollback) rather than the architecturally cleanest option (sharding by merchant ID, which would have been a 12-week schema migration). I made that call because the company did not have the operational maturity to do a 12-week schema migration safely yet, and I judged that the right move was to ship the reversible migration now and earn the right to do the bigger one later.

The second call was to treat the project as the prototype of a class of migrations, not as a one-off. I wrote a one-page canary playbook (5/25/100 lag SLO with auto-rollback, per-merchant fairness check before any partitioned canary) and presented it to the platform leadership team as a proposal for the default migration pattern across the company. Two other teams adopted it in the next two quarters; the third migration in the queue used the playbook with no platform-team involvement, which to me is the actual outcome we wanted.

On the immediate project: eight weeks, zero customer-visible incidents, p99 reconciliation latency 47 minutes to 9 against the 15-minute internal SLO. Canary lag spiked on day three, I added the per-merchant queue I had been planning to add in week six (because I had seen the same fairness shape on a peer migration the prior year), and we held.

The reflection that has stayed with me is that the company-level cost of the prior team's bad migration was not the migration itself, it was the absence of an artifact that would have prevented it. So now, when I take on any migration-class project, I write the playbook as the deliverable and treat the migration as the validation. The most expensive thing about the prior outage was that nobody had bothered to abstract.'

What is happening: the candidate is reframing the work as org-shaping, not project execution. They explicitly identify a class problem rather than an instance problem. They make the playbook the deliverable and the migration the validation. The reflection is a working principle they apply to all subsequent work, not a learning from one project. This is the L7 frame.

What Did Not Change Across the Three Tellings

The migration was the same migration. Same quarter, same team, same options considered, same canary mechanics, same per-merchant queue retrofit, same eight-week timeline, same 47-to-9 latency drop, same two reuses of the canary pattern. Every fact in all three tellings is true.

What changed:

• The opening sentence (different hook for different framing).
• The specific surface area details surfaced (CX coordination for frontend, replication mechanics for backend, class-of-system thinking for platform).
• The conflict beat (rollout coordination vs SLO breach decision vs class-vs-instance problem framing).
• The resolution and reflection (what lesson generalises at what scope).

This is the entirety of the tailoring craft. You are not changing the work. You are changing which true sentences about the work you choose to put in the foreground.

A Tailoring Worksheet for Every Story

For each story in your bank, fill out this worksheet:

[ Headline (L4) ]   The execution-focused version of the hook
[ Headline (L5) ]   The judgement-focused version of the hook
[ Headline (L6) ]   The cross-team-effect version of the hook
[ Headline (L7) ]   The org-shaping version of the hook

[ Frontend frame ]  Which user-facing details to surface
[ Backend frame ]   Which reliability/scale details to surface
[ Platform frame ]  Which adoption/leverage details to surface
[ ML/data frame ]   Which experiment/data details to surface (if applicable)

[ Reflection (low) ] What I learned (one-off learning)
[ Reflection (mid) ] What principle I adopted (generalisation)
[ Reflection (high)] What pattern I have applied since (org-shaping)

You do not need every cell filled for every story. You need enough that, after reading the JD, you can pick the right combination in 30 seconds. The candidate who does this work in advance walks into the loop with optionality. The candidate who does not is locked into one telling and has to hope it lands.

Honest Calibration: Do Not Reach Above Your Level

A tempting failure mode, once you understand the level axis, is to over-reach. The L5 candidate decides to tell every story in the L7 frame. The interviewer hears 'changed how the org thinks' and 'class problem not instance problem' from someone whose actual scope was a single team feature, and they discount the entire answer.

The rule: tailor up at most one level beyond the most senior version that is honest. If your work was genuinely L5, tell it as a strong L5 story or, where the principle holds, as a tentative L6 story ('I think there is a generalisable lesson here, which I have applied since'). Telling it as an L7 story will not get you the L7 offer; it will get you no offer.

The reverse failure mode is also real and more common: the L6 candidate who tells L4 stories. If the work was genuinely L6, owning the level in the framing is not arrogance, it is calibration. Many strong engineers under-frame because they have been culturally trained to defer. The interview is not the place. State the level honestly.

Bridge to the Next Lesson

This lesson taught you to take the same banked story and reframe it for different roles, levels, and surface areas. The next lesson, Advanced Storytelling: Layered Answers for Senior Roles, goes one layer further: how to deliver a 90-second 'system 1' headline that lands the framing immediately, while seeding hooks the interviewer can pull on for follow-up, so the conversation goes where you want it to go without you having to dump every detail upfront. That is the staff and principal craft.