A Practical 12-Week Execution Sequence

Use an execution operating system

The syllabus proposes two focused hours per day. Protect that constraint: it forces selection, exposes over-engineering, and makes twelve weeks sustainable. A typical five-day week yields ten core hours; keep any sixth session as recovery or mock-interview time rather than silently expanding scope.

The daily 110 + 10 block

The weekly rhythm

• Monday — baseline: define contract, dataset/load, success measure, and simplest working version.
• Tuesday — controlled change: change one consequential variable.
• Wednesday — failure: inject a realistic fault and trace it across the system.
• Thursday — evidence: rerun, compare, analyze slices, and capture limitations.
• Friday — explain: produce a one-page report and a five-to-ten-minute verbal walkthrough.

Before week one, record a baseline mock: one 35-minute architecture, one 30-minute coding problem, one SQL task, and two leadership answers. Score clarification, correctness, depth, failure coverage, and communication from 0–3. This is diagnostic, not a career metric.

Weeks 1–3: retrieval foundations and Qdrant depth

Search comes first because later agent and evaluation work needs a measurable grounding layer. Use one versioned corpus and query set across all three weeks so improvements remain comparable.

Week 1 — establish the retrieval laboratory

Core work: choose a disclosure-safe document corpus; define query intents and judgments; implement lexical, dense, and hybrid retrieval; calculate recall@k, MRR or nDCG as appropriate; capture p50/p95 latency and index size. Include identifier-heavy, semantic, filtered, long-document, and no-answer slices.

Acceptance test: a single command rebuilds the index and produces a report with dataset version, configuration, per-slice quality, latency, and at least five inspected errors. Explain why each metric matches the user task.

Failure: corrupt or omit a subset of relevance judgments. The report must expose dataset coverage rather than quietly comparing incomparable runs.

Week 2 — tune the complete RAG retrieval path

Core work: compare two chunking strategies; query rewrite only where justified; dense/sparse fusion; a reranker; context packing with source boundaries; and incremental indexing. Change one variable per run. Use an error taxonomy such as retrieval miss, wrong rank, filter exclusion, bad chunk boundary, stale data, and correct evidence lost during packing.

Acceptance test: recommend a pipeline for at least two query slices and reject one apparently better aggregate configuration because of latency, cost, or a critical regression. Keep all numbers as measured sandbox results, never employment claims.

Failure: add near-duplicate documents and one stale version. Demonstrate how deduplication, metadata, or recency policy affects citations.

Week 3 — operate Qdrant, not just call it

Core work: model collections, named dense/sparse vectors and payloads; create payload indexes for filters; tune HNSW/search parameters; test quantization; exercise snapshot/restore; and reason about shards, replicas, and multi-tenant layout. Qdrant’s current documentation describes dense+sparse fusion and multi-stage queries in the Hybrid and Multi-Stage Queries guide and memory/performance choices in Quantization.

Acceptance test: publish a before/after matrix for quality, filtered-query p95, throughput, memory or storage, configuration, and workload. Restore from a snapshot into a clean environment and verify document count plus sampled results.

Failure: run a selective filter without the appropriate payload index, then interrupt a migration or restore. Capture symptoms, diagnosis, mitigation, and the safer runbook.

Weeks 4–6: reliable agents, evaluation, and enterprise integration

These weeks join probabilistic behavior to deterministic controls. Use one workflow—for example, an evidence-backed enterprise request triage—so the evaluation and connector are part of the same system.

Week 4 — make the workflow resumable and bounded

Core work: draw explicit states and terminal outcomes; separate deterministic routing, model decisions, tools, and human approval; add schema validation, per-step timeouts, retry budgets, maximum steps, cost budget, checkpointing, idempotent side effects, and trace correlation. LangGraph’s current persistence documentation explains threads, checkpoints, state history, and replay concepts; verify the installed version before coding.

Acceptance test: terminate the process after a checkpoint, restart with the same run identity, and prove that completed side effects are not repeated. Every terminal state must be named: success, rejected, budget exhausted, invalid input, dependency failure, or human cancellation.

Failure: return malformed tool output, make a tool time out, and create a cycle. Show validation, bounded retry, and termination rather than an infinite repair loop.

Week 5 — build an evaluation gate that can say no

Core work: version a golden set; split retrieval, generation, tool-use, task completion, safety, latency, and cost measures; create deterministic assertions; write a human rubric; calibrate any model judge against labeled cases; add slice thresholds and a CI report. Include prompt injection, cross-tenant, no-answer, and malformed-input cases.

Acceptance test: seed a known regression and prove the gate blocks it for the correct reason. Then seed a harmless change and ensure the suite does not fail noisily. Document override authority and the evidence required.

Failure: deliberately bias a judge with order or verbosity and show disagreement against human labels. Tighten rubric or use a deterministic check where possible.

Week 6 — integrate across unreliable boundaries

Core work: design an OAuth/service-account connection, signed webhook ingestion, event queue, idempotent worker, outbox or equivalent handoff, dead-letter path, backfill, replay, and reconciliation. Define API versions, rate limits, tenant scoping, audit events, and long-running job status.

Acceptance test: the same event delivered repeatedly produces one intended side effect; a missed webhook is found by reconciliation; a dead-lettered item can be repaired and replayed with an audit trail.

Failure: crash after the external side effect but before local acknowledgement. Explain why “exactly once” is not a magic transport property and how idempotency plus reconciliation controls the outcome.

Weeks 7–9: data, platform, reliability, and security

Now deploy the same system under realistic operational constraints. The interview goal is to explain what happens after the happy-path demo.

Week 7 — PostgreSQL and replayable ingestion

Core work: normalize the transactional core; use JSONB deliberately; add indexes from query shapes; inspect EXPLAIN (ANALYZE, BUFFERS) safely on test data; exercise transactions, locks, and a deadlock; apply tenant isolation and row-level security; build a checkpointed ingestion path with validation, deduplication, lineage, and quarantine.

Acceptance test: show the slow query, plan, hypothesis, change, new plan, and trade-off. Replay an ingestion partition without duplicating rows. Prove a cross-tenant negative test. PostgreSQL’s official Using EXPLAIN chapter is the primary reference for reading plans.

Failure: feed a malformed PDF-derived record, duplicate an input file, and create lock contention. The pipeline should quarantine or retry without losing lineage.

Week 8 — deploy with explicit lifecycle behavior

Core work: build a small multi-stage image; define configuration and workload identity; deploy the API, worker, and dependencies; set requests/limits; create startup, readiness, and liveness probes with different semantics; add autoscaling assumptions, rolling update, rollback, and a rough cost model. The Kubernetes guide distinguishes how startup, readiness, and liveness probes affect container lifecycle and traffic.

Acceptance test: a slow-starting process is not killed prematurely, an unready instance receives no traffic, a deadlocked process recovers, and a bad release rolls back. State which behavior each probe is designed to observe.

Failure: point readiness at a fragile downstream dependency and observe the amplification. Redesign it to represent whether this instance can serve its contract without creating a fleet-wide outage.

Week 9 — observe, budget, threaten, and recover

Core work: instrument request and agent-step traces, structured logs, metrics, quality samples, token/cost use, and correlation IDs; define user-centered SLIs/SLOs; create actionable alerts; threat-model prompt injection, retrieval poisoning, data leakage, tool abuse, secrets, and cross-tenant access. The OpenTelemetry Python guide provides current instrumentation examples; the OWASP GenAI prompt-injection entry is a useful adversarial checklist.

Acceptance test: use one trace to locate a latency or failure cause, run an incident drill, and produce a short postmortem with detection, mitigation, root cause, correction, and learning. Show preventive and detective controls for a high-risk AI path.

Failure: disable a dependency, exhaust a quota, and place hostile instructions in retrieved content. Verify degradation, bounded retries, human-safe messaging, and alerts tied to action.

Weeks 10–12: convert engineering proof into interview performance

The final phase does not add a new platform. It compresses what you built into timed designs, coding fluency, truthful stories, and role-specific simulations.

Week 10 — four timed system designs

Design an enterprise RAG platform, a governed agent platform, an enterprise connector, and an evaluation platform. Use 45 minutes each: discovery, estimates, APIs/data flow, security/tenancy, failure handling, SLO/observability, cost, rollout/migration/rollback, and rejected alternatives. Record the session and score whether assumptions preceded components.

Acceptance test: each design contains a definition of done, one scale estimate, one critical trust boundary, three failure modes, and a phased rollout. Re-run the weakest design later without reading the first solution.

Failure: have a mock interviewer change a core constraint at minute 20—for example, data cannot leave a private network. Adapt the design without discarding the entire reasoning chain.

Week 11 — coding, SQL, API, and debugging under time

Run mixed sets: maps/windows, stacks/intervals, trees/graphs, heap/greedy, and one basic DP; SQL joins/aggregation/windows/plans; an async API; and an unfamiliar bug. Five high-quality algorithm problems in the week is the syllabus baseline, but quality means a second attempt, edge cases, invariant, and complexity—not merely an accepted submission.

Acceptance test: keep a scorecard for clarification, pattern selection, correctness, tests, complexity, and communication. Re-solve misses from a blank editor after 48 hours. For practical work, include timeout, authorization, idempotency, and failure tests.

Failure: introduce a misleading test, a cancellation bug, and a SQL tie ambiguity. Practise detecting a flawed premise rather than coding around it.

Week 12 — full-loop simulation and application pack

Run at least two role-specific loops: recruiter pitch, resume deep dive, technical discussion, coding/practical task, system design or FDE case, cross-functional scenario, leadership story, and written follow-up. Use the live role compiler from Chapter 10 and re-check availability before each simulation.

Acceptance test: every major topic—search, agents, evaluation, integration, data/platform, reliability, security, customer architecture, leadership—has one credible story or artifact. Gaps are stated, not hidden. The second simulation shows a specific improvement from the first.

Failure: remove a favorite story, challenge a metric’s provenance, and ask for a design in a different domain. The pack should survive without memorized wording or invented precision.

Control the plan instead of obeying it blindly

A sequence is useful only while it targets current constraints. Review the evidence every Friday and change the next week only for a recorded reason.

The weekly scorecard

When time is lost

Do not compress every missed task into the next week. Preserve dependency order and acceptance tests. Drop polish, extra frameworks, frontend work, and duplicate artifacts first. If an interview arrives early, branch into a three-day role sprint: live requirements, top two proof gaps, one mock, then return to the plan.

What not to over-prepare

For these target roles, foundation-model pretraining pipelines, optimizer derivations, distributed training internals, CUDA kernels, state-space-model mathematics, and transformer history have lower expected return unless a live posting explicitly asks. Learn enough to make an informed build/use/fine-tune decision, then return to production retrieval, evaluation, integration, reliability, and architecture.

Interview playbook

Use the twelve-week work as evidence, not as a claim of prior production experience. Label sandbox work explicitly and connect it to real judgment you can defend.

Proof answer: Contract → Baseline → Change → Failure → Evidence → Decision

1. Contract: user task, constraints, and success definition.
2. Baseline: simplest measured system and dataset/load.
3. Change: one variable and the hypothesis behind it.
4. Failure: injected or observed fault and diagnosis.
5. Evidence: quality/latency/cost/operability result with limits.
6. Decision: ship, reject, narrow, or gather more evidence.

Common traps

• Presenting twelve mini-demos with no shared dataset, architecture, or narrative.
• Reporting only aggregate quality and average latency.
• Calling an injected sandbox failure a real production incident.
• Changing multiple variables and attributing the result to one of them.
• Spending the final week polishing slides instead of running mocks.
• Using a library’s feature names as a substitute for understanding lifecycle and failure behavior.

Question bank

Use these as weekly retrospectives and mock-interview prompts.

Proof artifact: the twelve-week evidence repository

Build one repository or portfolio folder that tells a coherent engineering story. Keep sensitive employer material out; use disclosure-safe or synthetic data and label sandbox claims.

Structure and steps

README.md                 # user problem, architecture, how to reproduce
evidence/weekly-log.md    # hypothesis, result, limitation, next decision
retrieval/                # corpus manifest, judgments, benchmark configs
agent/                    # state model, permissions, checkpoints, evals
connector/                # contracts, idempotency, replay, reconciliation
platform/                 # deployment, probes, telemetry, threat model
designs/                  # four timed architecture records
interview/                # story index, scorecards, mock retrospectives

1. Tag a baseline before each controlled change and record dependency versions.
2. Automate one clean setup and one evaluation command; include expected runtime and resource needs.
3. Add a decision ledger that links every claimed improvement to raw evidence and limitations.
4. Record five short walkthroughs: retrieval, agent/eval, integration, operations/security, and architecture.
5. Create a final role index showing which files support which active requirement.

Metrics

• Twelve weekly acceptance tests with pass/fail and evidence link.
• At least one quality, latency, cost/resource, and reliability measure where relevant.
• At least one important slice and one limitation in every benchmark report.
• Time-to-reproduce from a clean environment and time-to-explain in a ten-minute walkthrough.
• Mock score improvement by dimension; do not turn practice scores into employment claims.

Deliberate failure injection

Maintain a failure manifest: missing judgments, stale duplicate documents, slow filtered search, killed agent process, malformed tool output, biased judge, duplicate webhook, malformed ingestion record, lock contention, bad readiness dependency, provider outage, and indirect prompt injection. For each, capture expected behavior, actual signal, containment, repair, regression test, and remaining risk.

What to present

Open with a one-page architecture and evidence map. Demonstrate one clean run and one failure/recovery, then show the decision ledger and a role-specific index. Keep the full repository available for follow-up, but lead with the smallest evidence that answers the interviewer’s question.

Chapter review

The twelve weeks form a dependency chain: measurable retrieval, bounded agents, gates, reliable boundaries, operable deployment, and finally interview compression. The schedule is successful when it produces repeatable evidence and better decisions.

Glossary

Acceptance test

The observable condition that must pass before a week or artifact is considered complete.

Evidence log

A dated record of hypothesis, configuration, result, limitation, decision, and next action.

Controlled change

An experiment that changes one consequential variable while keeping comparison conditions stable.

Failure manifest

A catalog of injected faults, expected behavior, observed evidence, and recovery controls.

Blank-editor reattempt

Solving a missed problem again from scratch after delay to test retained reasoning.

Scope guard

An explicit rule for what is dropped when time or complexity exceeds the plan.

Mastery checklist

• I can state the weekly proof and acceptance test for all twelve weeks.
• My corpus, judgments, configurations, loads, and dependency versions are recorded.
• Every important artifact includes a deliberate failure and recovery evidence.
• I distinguish sandbox results from production experience every time.
• I use role relevance and evidence gaps to adjust the sequence.
• I have four timed designs, a coding/SQL scorecard, six truthful stories, and two full mocks.
• I can reproduce and explain the final repository without hidden manual steps.