Prepare migration leadership story

A typed scaffold plus a concrete example. Replace every field with your real project; keep the structure so the answer stays bounded under interview pressure.

type MigrationStory = {
  context: string;        // What was the system before? Who used it? What hurt?
  scope: string;          // Boundary of the migration. What was IN, what was deliberately OUT.
  technicalDecision: string; // The senior call you owned, and why.
  myRole: string;         // The verbs an interviewer can audit: led, decided, partnered, escalated.
  collaboration: string;  // How you got buy-in. Who pushed back; how you addressed it.
  rolloutStrategy: string; // Flagged, dual-write, shadow read, percentage rollout, kill switch.
  measurableResult: string; // The numeric or operational outcome the team owns now.
  whatYouWouldDoDifferently: string;
};

const example: MigrationStory = {
  context:
    'A 4-year-old Redux + REST stack served the trader-facing order ticket. State was fragmented across 11 slices, optimistic updates required hand-rolled rollback, and the team was rewriting the same fetch+normalize+dedupe code per feature. New hires took three weeks before a first PR landed.',
  scope:
    'IN: every order ticket screen, the realtime PnL panel, and the alerts shelf. OUT: the legacy admin tools and the back-office reconciliation views (different team, different SLAs, deliberately deferred).',
  technicalDecision:
    'Move the trader app to TanStack Query plus a thin store for purely client-only UI state. The contract was explicit: server data lives in the query cache, ephemeral UI state lives in component state, durable session state goes through the store. Optimistic updates use TanStack mutation cache, not hand-rolled rollback.',
  myRole:
    'Tech lead. I wrote the architecture RFC, ran two engineering reviews to address pushback, and owned the rollback decision tree. I migrated three of the eight modules myself and reviewed the rest.',
  collaboration:
    'The pushback was that TanStack Query "hides" stale data. I demoed staleTime + the query devtools at engineering review and committed to a rule: any read that affects a money decision must call refetch() explicitly. That made the staleness boundary auditable in code review.',
  rolloutStrategy:
    'Module-by-module behind a per-trader feature flag. Each migrated module ran a 24-hour shadow comparison against the old store, asserting payload equality. We rolled to 5% of traders for a week, watched client error rate and order-rejection metrics, then ramped weekly.',
  measurableResult:
    'New-hire time-to-first-PR dropped from 21 days to 6 days. Client error rate on the order ticket fell 38%. The "stale optimistic update" support category disappeared. We removed roughly 7,200 lines of net code.',
  whatYouWouldDoDifferently:
    'I would have written the staleness rule into a lint pass earlier; we caught two real money-decision reads relying on cached data only because of code review attention. A rule encoded in tooling is more durable than a rule encoded in reviewer memory.',
};

Convert the answer into observable behavior. In a mid-senior interview, say which behaviors are covered by unit tests, interaction tests, accessibility checks, and one browser smoke path.

// "Test" for a behavioral story = a self-grade rehearsal.
// 1. Read the story aloud in 90-120 seconds.
// 2. Have a peer ask three follow-up questions:
//    - "What did you personally decide that another engineer would have decided differently?"
//    - "What metric would have shown this migration was failing, and who watched it?"
//    - "If the migration had to rollback at 50% rollout, what was the playbook?"
// 3. Each follow-up should land in 60 seconds with a concrete answer.
// 4. Pair the verbal pass with a written one-pager so you don't drift.

Shows whether your communication matches the level of ownership expected from senior frontend engineers.

• Use a real project or credible constructed scenario.
• Name your ownership directly.
• Include a tradeoff, outcome, and what you would do next.

• Open with context and user or business risk.
• Describe the technical decision and your ownership.
• Close with measurable outcome, learning, and relevance to the target role.

• A polished story is useful, but over-rehearsed answers can sound detached from real engineering judgment.
• Depth matters more than listing many technologies.

• Interviewer asks for your personal contribution.
• Metric is unavailable or ambiguous.
• The story exposes a skill gap you need to frame honestly.

• Say the answer aloud in two minutes.
• Write one follow-up technical detail.
• Prepare one honest limitation and ramp-up plan.

• What would a staff engineer have done differently?
• What evidence would a hiring manager trust?