Senior Engineering Interview Handbook / Chapter 163
The 14-Day Emergency Plan
A two-week senior-interview salvage plan that turns a fast diagnostic into narrow repairs, daily mock exposure, honest cuts, and a rested final approach.
Page tools
At the end of day two, the first plan is already wrong
Consider a modeled senior backend engineer with a loop fourteen days away. The known rounds are coding, system design, behavioral, and project deep dive, followed by a hiring-manager conversation. There are two hours available on most weekdays and five on each weekend day. The first attempt at a plan divides those hours neatly among algorithms, architecture reading, story writing, and company research.
Then the diagnostic begins.
The engineer finds a workable coding approach quickly but declares completion without testing an empty input or the upper boundary. In design, the service decomposition is plausible, but the answer starts with components and never establishes data ownership or a migration path. Seven stories can be retrieved; mentoring and conflict both lead back to the same example. The primary project survives fifteen minutes of questioning. The secondary project becomes vague as soon as the reviewer asks who made the central decision.
The balanced calendar is now indefensible. The engineer does not have four equally weak subjects. There are three risks that could recur across the loop: finishing code without proving it, designing a destination without explaining how the system gets there, and presenting evidence that thins under follow-up. The next twelve days have to attack those behaviors while keeping every likely round warm.
That is the purpose of an emergency plan. It is not a compressed curriculum. It is a salvage campaign in which every substantial block must expose a hiring risk, repair one, or test whether the repair survives interview conditions.
Put the immovable facts on one page
Before choosing a topic, write down the interview dates and likely rounds, the hours that remain after work and personal obligations, the language and tools you will use, the people available for mocks, and whether rescheduling is a real option. Include sleep and recovery in the capacity calculation. Hours borrowed from the last nights of sleep are rarely full-strength preparation hours.
Next, inventory what already exists: timed coding attempts, a mistake log, design canvases, a story bank, primary- and secondary-project notes, prior mock feedback, and the resume version the interviewers will see. Two weeks is too short to keep rediscovering prepared material.
For each likely round, define a minimum bar in observable terms. A coding attempt must reach executable code, deliberate tests, and a complexity explanation within the available time. A design answer must clarify the problem before drawing, establish a source of truth, and follow at least one production failure or rollout decision. Behavioral answers need retrievable evidence and clear individual contribution. The project deep dive needs one primary project that can sustain 30 to 45 minutes and a distinct secondary project that can sustain at least 15. Communication is not a separate study track; it is visible in all of these attempts.
Do not lower a minimum bar merely to make the calendar fit. If a likely round is far below a credible bar, the plan should reveal that fact early enough to delay or narrow the opportunity when possible.
Spend two days finding behavior, not topics
The first two days should produce attempts that can fail. Run one representative coding problem in the chosen language, including tests and complexity. Give a system-design prompt 45 minutes and use the opening you would use live. Retrieve answers to ten behavioral prompts from story labels without searching through notes. Explain the primary project for fifteen minutes, then accept skeptical questions about ownership, trade-offs, impact, and failure. Record one answer so that recommendation, structure, and pace can be inspected rather than remembered.
A diagnosis such as “rusty at coding” cannot govern a practice block. Describe the first visible failure:
The approach is usually viable, but I stop after the happy-path example and
leave boundary tests until the interviewer asks.
or:
I name services before users, scale, data ownership, and failure tolerance,
so later trade-offs rest on assumptions I never made explicit.
Choose no more than three primary risks. Prefer risks that travel. Late clarification, weak testing, vague ownership, unsupported impact, and slow retrieval can damage several rounds. A narrow technical gap deserves primary status only when it is likely to be sampled or blocks a prepared design, story, or project.
Everything else receives a maintenance rule. “One timed coding touch every day” is a rule. “Review graphs when there is time” is a wish.
Repair the next attempt
Days three through six are deliberately narrow. The unit of progress is a changed attempt, not another page of notes.
For the modeled engineer, the coding repair is a completion ritual. Before saying the solution is finished, name the invariant, run the ordinary case, then test empty or minimal input, a boundary value, duplicates when relevant, and the largest expected shape. Two well-chosen timed problems can test that ritual better than five unrelated problems completed with the old habit.
The design repair uses one method throughout the campaign:
- Name users, core flows, scale, and non-goals.
- Establish the data model and source of truth.
- Draw the smallest architecture that serves the core flow.
- Follow one failure through detection, mitigation, and recovery.
- Explain rollout, migration, and the trade-off that deserves the remaining time.
This is enough structure to prevent wandering without turning every prompt into the same memorized answer. Apply it to one or two likely prompt families. Learning several named design frameworks now would add retrieval choices when the useful repair is to make one opening dependable.
The evidence repair begins before the final week. Expand the story bank until the likely leadership families have distinct, retrievable labels. Prepare a two-minute version of the strongest stories, then test follow-ups about conflict, individual action, evidence, and reflection. For projects, write the system or workflow trace, the consequential decisions and alternatives, the boundary of personal ownership, the support for outcomes, and the details that must remain confidential. Give the secondary project enough mechanism to prove range; do not try to make it a shorter copy of the primary.
Every day includes mock exposure, but not every day needs a full mock. A ten-minute coding completion, a five-minute design opening, an interrupted story, or a skeptical project follow-up can reproduce the pressure needed to test one repair. End the fragment with one correction rule and schedule a nearby retest. Feedback that does not alter a later attempt is merely a record of the miss.
Day seven is where the campaign becomes honest
Suppose the modeled engineer reaches day seven with mixed evidence. The coding completion ritual has held twice. The design opening is much clearer, but a mock reveals that “we would migrate gradually” still has no operational content: there is no unit of cutover, comparison policy, rollback owner, or mixed-version story. The secondary project still cannot support an ownership question. A production incident at work also consumed the evening reserved for specialty reading.
The response is not to move every missed block one day to the right. That would steal from retesting and taper. Remove the specialty reading because no known round requires it. Replace a planned broad coding session with a short maintenance attempt because the coding repair is holding. Use the recovered block to trace one migration from shadow operation through cutover and rollback, and use the project block to either make the secondary example defensible or select a better one.
This mid-campaign cut is part of the method. A two-week plan that never changes after new evidence is only a calendar.
Make days seven through ten feel like the loop
The next four days test whether repairs survive time, interruption, and context switching. A useful sequence is a coding mock, a system-design mock, a behavioral or hiring-manager mock, and a primary-project deep dive. On each day, keep a short maintenance touch in another round: story retrieval after coding, a project decision after design, test design after behavioral, or a design failure pass after the project mock.
Review each attempt before adding practice. Find the first consequential place where the behavior reverted. Write one rule that could have changed that moment, then retest the same rule on a neighboring problem. After the migration answer fails, for example, the repair is not “study migrations.” It is an inspectable path:
shadow inputs and comparison -> cutover unit -> mixed-version behavior
-> rollback trigger -> rollback owner -> cleanup condition
The retest changes the prompt while preserving the demand. If the engineer can explain partner-by-partner cutover for an entitlement service, ask how the same method would handle tenant-by-tenant movement to a new storage path. A repair that works only with the original nouns may be a memorized sentence.
Daily mock exposure does not mean collecting fourteen scores. Some days need a full timed round; others need a fragment just long enough to put the corrected behavior under stress. Stop the review once the next action is clear. A page of comments often hides the one correction the following day can test.
Decide before the taper begins
By day eleven, the campaign should support a decision. For every likely round, ask whether a recent attempt reached the minimum bar and whether each primary risk has survived a retest after correction. Inspect the story and project artifacts themselves. A confident feeling cannot substitute for missing evidence, but a minor imperfection does not invalidate the whole loop.
Proceed when the minimum bars hold and the remaining risks have specific handling rules. Consider delay when a likely round still contains a repeated no-hire behavior and rescheduling is genuinely available without sacrificing the opportunity. Both conditions matter. Do not delay merely because two weeks could not produce broad mastery; it could not. If delay is unavailable, name the residual risk, reserve one narrow block for it, and prepare a recovery move for the live round.
This is also the last sensible point for scope changes. Do not discover a new curriculum on day thirteen.
Target the opportunity, then protect execution
Use days eleven through thirteen to adapt prepared evidence to the actual role. Read the job description and reliable company material for constraints, not trivia. Identify a few signals the role appears to value. Decide which stories and projects reveal those signals honestly, which architecture constraints deserve clarification, and which questions would help you understand the team’s real work.
Run the final hard rehearsal early enough to review it. After that, use short maintenance attempts: coding completion, the design opening and migration trace, story retrieval, and project decision questions. Volume should fall as the first interview approaches.
Day fourteen belongs to retrieval and logistics. Review story labels, project one-pagers, the design opening, coding test cues, company notes, and questions. Check the calendar, room, network, camera, microphone, editor, and travel or call details. Stop while attention is still good. A new algorithm family or a late rewrite of the project dossier is unlikely to become reliable overnight; fatigue can damage skills that were already reliable.
The campaign card
Keep the operational plan compact enough to revise by hand:
Day 1 coding and design diagnostics; record the first visible failures
Day 2 story retrieval, project pressure, communication review; rank 3 risks
Day 3 repair risk 1; run a short timed retest
Day 4 repair risk 2; keep coding and story retrieval warm
Day 5 repair risk 3; pressure-test ownership and evidence
Day 6 finish minimum story bank and two-project dossier; retest a neighbor
Day 7 coding mock; review the campaign and cut work that no longer earns time
Day 8 system-design mock; repair and retest one production decision
Day 9 behavioral or hiring-manager mock; test interruption and retrieval
Day 10 primary-project deep dive; run a distinct secondary-project fragment
Day 11 decide proceed, delay, or proceed with an explicit residual risk
Day 12 role targeting and final hard rehearsal
Day 13 focused retest, light maintenance, and artifact retrieval
Day 14 logistics, recall, rest, and no new material
Daily: one reviewed mock or mock fragment, one correction at most, one retest.
Protect: sleep, work obligations, minimum bars, and the final taper.
Cut first: broad reading, duplicate frameworks, comfortable repetition,
and any block that cannot name the behavior it is meant to change.
A missed block should trigger a cut, not an automatic extension. Preserve the diagnostic, the three primary repairs, the story bank, one deep primary project, a credible secondary project, daily pressure exposure, and the taper. Reduce topic breadth and full-mock volume before borrowing from sleep or abandoning a likely round.
Fourteen days cannot manufacture experience or repair every foundation. It can make strong evidence easier to retrieve, make dangerous habits less likely to recur, and reveal when the honest decision is to delay. The emergency route has done its job when the calendar no longer expresses panic; it expresses the few claims the next attempt must prove.