The Twelve-Week Deep Plan

When four more weeks change the work

In the first design session of a modeled campaign, a senior backend engineer is asked to sketch a deployment platform for hundreds of internal services. The engineer knows the expected vocabulary: control plane, workers, leases, idempotency, eventual consistency. Then the reviewer asks two ordinary questions.

What must never happen twice? What should the platform do when a worker loses contact halfway through a rollout?

The answer dissolves into components. Nothing establishes which state is authoritative, which action may be retried, or how the system distinguishes a slow worker from an abandoned rollout. More architecture boxes do not rescue the design. The missing foundation is the ability to reason about ownership, state transitions, and recovery under uncertainty.

Eight weeks could improve the presentation and rehearse several likely cases. It would be a poor deadline for learning this foundation, using it in unfamiliar systems, receiving outside criticism, and proving after a delay that the repair held. The engineer chooses twelve weeks because the extra month has a specific job.

That is the threshold for this route. Use it when a domain change, specialist role, or repeated foundation failure needs a full learning cycle:

failed attempt -> narrow repair -> unfamiliar application -> feedback
               -> delayed retest -> loop pressure -> target decision

More time is not safer by itself. It creates room for another course, another question bank, and another month of postponing evidence. A twelve-week plan earns its length only when an important weakness becomes judgment the candidate can retrieve on a surface they did not rehearse.

Give the extra month a boundary

The engineer is moving from product-backend work toward infrastructure platform roles. Production ownership, incident response, mentoring, and service design are already credible strengths. The baseline exposes three high risks:

• unfamiliar coding prompts conceal graphs inside dependencies, permissions, or routing, and the engineer begins implementing before naming the model;
• platform designs use specialist terms but do not establish state ownership, retry safety, migration boundaries, or operational responsibility;
• project answers describe successful platform work without showing how adoption was earned across teams.

The plan is allowed to repair those three risks. It is not allowed to become a distributed-systems curriculum. Consensus, queues, multi-tenant controls, rollout safety, and observability may enter when they change a decision in a case. They do not deserve blocks merely because infrastructure engineers are expected to know the words.

Capacity comes next: two ninety-minute weekday sessions, one shorter retrieval session, one longer weekend block, and a protected day without preparation. Reviewer time is booked now for Weeks 2, 6, 9, and 10. The candidate cannot borrow unlimited evenings from work and recovery simply because the calendar is long.

The resulting campaign has four kinds of work. Maintenance keeps coding, story retrieval, project depth, and design openings warm. Repair isolates a behavior that repeatedly fails. Deepening supplies the minimum specialist model needed to make a sound decision. Transfer asks for the same judgment under new nouns, constraints, and follow-up pressure.

The order matters. Deepening without transfer produces notes. Transfer without repair reproduces the same mistake in more cases. Specialist study without maintenance can create a candidate who sounds informed about platforms and unexpectedly rusty everywhere else.

Every substantial block must therefore leave evidence: working code, a design with explicit decisions, a recorded answer, reviewer notes, or a dated retest. Reading may support that evidence. It cannot substitute for it.

Weeks 1–2: find the failure underneath the vocabulary

The opening fortnight samples every likely round. The engineer completes timed coding prompts, two platform-shaped design cases, behavioral retrieval, and pressure sessions on a primary and secondary project. These are rough attempts, not performances delayed until the background reading feels complete.

The deployment-platform case reveals more than “weak distributed systems.” When pressed, the engineer cannot say whether the control plane owns desired state or execution state, what identity makes a rollout action safe to retry, or which observations justify reassigning work. That produces a usable repair statement:

Before drawing components, name the authoritative state, its owner, the
allowed transitions, the retry identity, and the evidence required for
recovery.

The hidden-graph failure becomes equally concrete: list nodes, edges, direction, traversal state, and termination conditions before choosing the implementation. The project failure becomes a question rather than a slogan: which adoption constraint did the engineer personally discover, which choice followed, and what evidence changed the rollout?

The second design case uses a job scheduler, not a deployment platform. The same state question still causes trouble. The reviewer also notices that the engineer gives several technically possible choices without making a recommendation. This is recorded as a communication symptom of the same uncertainty, not opened as a fourth repair program.

By the end of Week 2, the campaign has a target-role profile, three observable risks, correction rules, baseline artifacts, reviewer dates, and an exclusion list. “Study infrastructure” has disappeared from the plan. The work is now narrow enough to begin.

Weeks 3–5: repair one decision at a time

Foundation repair starts with the smallest model that can survive questioning. For stateful platform cases, the engineer traces one operation through time: request accepted, desired state recorded, work assigned, progress observed, timeout or failure detected, work retried or reconciled, result exposed to the caller. At each transition the engineer must say who owns the state, which facts are durable, and what makes a repeated action safe.

This does not produce a universal platform architecture. It produces a way to find the dangerous decision. In one case, duplicate execution is tolerable but duplicate publication is not. In another, the action itself must carry a stable identity. A migration case adds a compatibility window and rollback boundary. An incident exercise asks what operators can observe when desired and actual state diverge.

The coding repair follows the same discipline. One familiar dependency prompt is used to correct the modeling step; later prompts hide the graph inside permissions and routing. Immediate repetition confirms that the rule was understood. A different prompt several days later tests whether the rule can be retrieved.

The platform-adoption story is rebuilt from evidence. The engineer separates the inherited constraint, the teams affected, the personal decision, the alternative rejected, the rollout method, the adoption signal, and the remaining limitation. A reviewer then asks only follow-ups. If the answer falls back into “we,” the attribution repair remains open.

Meanwhile, the other rounds receive maintenance rather than equal shares of the calendar: a timed coding problem, a design opening, story retrieval, and a project question each week. A difficult foundation may dominate attention; it does not get permission to erase the likely loop.

At the end of Week 5, the engineer can reason through the original deployment case cleanly. That is encouraging and insufficient. The next phase removes the familiar surface.

Weeks 6–8: make the repair travel

Transfer begins when the prompts stop advertising what they require. The engineer works through an observability platform, a build service, a tenant configuration system, a storage migration, and an incident involving stuck work. These cases share no canonical diagram. They do share decisions about ownership, partial failure, adoption, operational burden, and safe change.

The first Week 6 review goes badly in a useful way. Asked about tenant configuration propagation, the engineer reaches too quickly for the deployment-platform design. The reviewer changes the constraint: customers must read their own update immediately, while background consumers may lag. The borrowed architecture no longer fits.

The correction is not another component. It is to state the product promise before selecting the propagation policy: which reader needs which freshness, what stale state can damage, and how repair will be observed. Three days later, a search-indexing case tests the same move with different data and failure costs. The engineer makes a recommendation, names what remains asynchronous, and gives a recovery path without copying the earlier diagram.

Broader case coverage is valuable only in this sense. New cases should put a repaired idea under different pressure. Random variety merely makes the study log longer.

The project work also has to travel. The engineer practices the adoption story as evidence for influence, migration judgment, developer experience, and delivery under constraint. The facts remain the same, but the emphasis changes with the question. A truthful project becomes reusable without becoming a memorized speech.

By Week 8, a repair can be retired only when it has survived a delayed test on an unfamiliar surface without a hint. If a correction works only on the case that taught it, it remains open. If more than three severe repairs are open, the candidate narrows the target roles or postpones a lower-value topic rather than expanding the weekly capacity.

Weeks 9–10: let a loop disturb the plan

Two loop-shaped simulations now test switching cost and recovery. Each joins independent coding, system-design, project, and behavioral work with realistic breaks and one reviewer record. When reviewer access is limited, two or three rounds can form a near-complete day, but convenient fragments spread across a week do not reveal how one miss affects the next round.

The first simulation exposes a new problem. The specialist reasoning is mostly sound, but after uncertainty in the design round the engineer explains every alternative at length. The following project answer is also slow to reach the personal decision. More study would worsen this. The correction is to state the recommendation, the binding constraint, and the consequence before opening the alternatives.

That rule is practiced in a short design fragment, then left alone. Four days later, the second simulation asks for a multi-tenant build service. The engineer establishes ownership and failure policy, makes one recommendation, and changes it when a compliance constraint appears. The project answer begins with the adoption decision and survives questions about a team that declined to migrate.

The correction ledger records this as changed behavior, not a lesson understood. Severe findings remain open until a later attempt supplies the proof. Another mock is never a substitute for processing the last one.

Weeks 11–12: choose where the evidence belongs

The final fortnight turns from broad transfer to actual opportunities. The engineer compares target roles by ownership, likely round weight, specialist surface, and the projects that honestly fit. A product-infrastructure role may value safe migrations and cross-team adoption. A storage-heavy role may expose a foundation that this campaign did not repair. Both may be attractive; only one may match the evidence now available.

One company-shaped simulation happens early enough to correct a narrow miss. After that, the volume falls. Coding and design openers stay warm. Project and story cues remain retrievable. Interview logistics, questions for the team, and recovery take over. A broad new topic is not allowed to occupy the taper because an empty evening feels undeserved.

Proceed with priority companies when every likely round has recent evidence, the specialist claims survive unfamiliar cases, severe mock findings have passed delayed retests, and both projects withstand truthful questions about personal decisions and trade-offs. The primary project should sustain thirty to forty-five minutes; the secondary should sustain at least fifteen.

Resequence companies when an early loop would provide useful calibration without spending the best-fitting opportunity. Narrow the targets when the specialist evidence fits some roles much better than others. Delay when a likely round still repeats a severe failure or when two or more likely rounds lack recent proof.

The plan is complete only when Week 12 can be lighter. If the last week must carry foundation repair, extensive mocks, and new case families, the calendar has reached its end but the campaign has not.

Keep the proof on one card

The campaign needs a record compact enough to govern the next week:

Target       infrastructure platform roles
Capacity     two 90-minute blocks; one retrieval block;
             one weekend evidence block; one protected rest day

Open risks   hidden graph modeling
             state ownership and recovery under partial failure
             platform adoption with truthful personal attribution

Weeks 1–2    sample the whole loop; name failures and exclusions
Weeks 3–5    repair narrow foundations; maintain every likely round
Weeks 6–8    retest through unfamiliar cases and follow-up pressure
Weeks 9–10   run two loop-shaped simulations; process each finding
Weeks 11–12  fit evidence to real roles; decide; taper

Close a risk only after an unprompted delayed retest on a new surface.
Every week leaves an attempt, decision, reviewer note, or retest.

This engineer finishes twelve weeks knowing less about infrastructure than an unbounded syllabus could contain. The important change is elsewhere. A prompt can hide the familiar mechanism, a reviewer can change the constraint, and a failed round can disturb the sequence. The engineer can still find the state, make the decision, explain the limit, and recover.

That is what the extra month bought. Interview week can now protect the work instead of trying to finish it.

Related links

• Choose Your Preparation Path
• Convert the Diagnostic into a Plan
• Deliberate Practice
• The Mistake Taxonomy
• The Mock Interview Engine
• The Eight-Week Standard Plan
• Interview Week