Full Retrospective and Application Kickoff: a Complete Pass Over the Interview Bank, a Knowledge Map, Month-Two Application Cadence, Public Launch of the Site

Overlay the course map with your own trace

On the second day a runner also does something else: overlay the official course map with the trace from their watch. The course map tells you where the long climbs are, where the turnaround is, and at which kilometre the aid stations sit; the trace tells you where you deviated from plan. Either alone is useless — with only the map you do not know where you went wrong, and with only the trace you do not know that the lost pace was because a 3-kilometre climb sat there.

The knowledge map is that course map, and yesterday's weak-point list plus this morning's three-color marking are your trace. The map has four layers matching the four weeks:

• Layer one, single-agent principles (W1): how one agent thinks. The output is a CLI agent with tools, events, and sessions, finally packaged as an HTTP service.
• Layer two, productionizing (W2): how a group of agent processes stay alive. The output is mini-koda — a gateway plus a worker pool, brought up with one compose command.
• Layer three, multi-agent orchestration (W3): how a group of agent roles collaborate, and how to prove the collaboration works. The output is mini-multi-agent, wired into mini-koda over authenticated HTTP.
• Layer four, advanced and engineering (W4): making this system secure, open, accurate, and pleasant, and then talking about it.

The point is not the layering, it is the edges. A diagram of nodes with no edges is a table of contents rather than a map — a table of contents is on the site's home page and not worth half an hour of drawing. Drawing an edge has one criterion, applied strictly: draw an edge from A to B only when B cannot be understood without A. "A and B both involve message queues" does not count, that is parallel placement in one layer; "the window's ceiling cannot be understood without understanding the context window" does, that is a genuine prerequisite. By that criterion, purely curricular edges like "D14 finishes deployment before D15 covers multi-agent" get deleted — that is not a dependency, it is a calendar.

Drawn to that criterion, the four-layer map looks like this. The Mermaid source below can be pasted anywhere Mermaid is supported (a GitHub README, an online editor, a notes app that supports it) and renders directly, which also makes it easy to adapt into your own version:

graph TD
  subgraph W1["W1 single-agent principles"]
    D1T["D1 tokens and the context window"]
    D1S["D1 streaming and SSE"]
    D2["D2 tool calling and the agent loop"]
    D4["D4 provider abstraction and tiered routing"]
    D5["D5 tool reliability and three reversibility tiers"]
    D6["D6 context compression and sessions"]
    D7["D7 packaging as an HTTP service"]
  end
  subgraph W2["W2 productionizing"]
    D8["D8 splitting gateway and worker"]
    D9["D9 the message bus and at-least-once"]
    D10["D10 sharding and leases"]
    D11["D11 the run state machine and ordering"]
    D12["D12 vector memory and chunking"]
    D13["D13 cron scheduling and the cost ledger"]
    D14["D14 multi-replica deployment and graceful shutdown"]
  end
  subgraph W3["W3 multi-agent orchestration"]
    D15["D15 whether to split, and the graph model"]
    D16["D16 supervisor dynamic routing"]
    D17["D17 Planner-Executor-Critic and budgets"]
    D18["D18 the summarization node and the checkpointer"]
    D19["D19 cross-service auth and idempotency"]
    D20["D20 proactive jobs and interruption control"]
    D21["D21 evaluation and tracing"]
  end
  subgraph W4["W4 advanced and engineering"]
    D22["D22 security and least privilege"]
    D23["D23 MCP and Skills"]
    D24["D24 hybrid search and reranking"]
    D25["D25 the frontend streaming experience"]
    D26["D26 answering system design"]
    D27["D27 resume and project packaging"]
  end
 
  D1T --> D2
  D1T --> D6
  D1T --> D13
  D1S --> D7
  D1S --> D11
  D1S --> D25
  D2 --> D5
  D2 --> D23
  D4 --> D26
  D5 --> D22
  D6 --> D12
  D6 --> D18
  D7 --> D8
  D8 --> D9
  D8 --> D19
  D9 --> D10
  D9 --> D11
  D9 --> D13
  D10 --> D14
  D11 --> D18
  D11 --> D25
  D11 --> D26
  D12 --> D24
  D13 --> D20
  D13 --> D21
  D13 --> D26
  D15 --> D16
  D15 --> D17
  D17 --> D18
  D17 --> D21
  D21 --> D27

What is genuinely valuable in this map is the long cross-layer edges. D5's three reversibility tiers reach all the way to D22's least privilege — 17 days apart, and they are two halves of one thing: D5 drew the line for which operations are irreversible, and D22 turned that line into allowlists and argument caps in code. Or D1's token accounting connecting to D13's cost ledger and on to D26's capacity estimate, one causal chain across three weeks. The answers that separate candidates in interviews travel these long edges: asked how you control cost, tracing up the edge to tokens being the unit of billing and length and down to rate limiting and degradation reads as having a system; somebody who answers only "use a smaller model" has one isolated node in their head.

How to use it: color the reds from your marking onto the matching nodes by day number. If reds cluster upstream of a node, what needs work is the upstream one — unable to explain D11's ordering nine times out of ten means D9's at-least-once was not absorbed, rather than the state machine being hard. That is a map's one advantage over a list: a list tells you where you went wrong and a map tells you where to start fixing. So draw this yourself; copying mine is worth almost nothing, because the reasons for the edges are not in your head.

This map stops at day 30, and under every node there is a course's worth of depth. So here is a second one — its edges are not "prerequisite" but "expands into": going out from a node means spreading that single day into a whole course. The two kinds of edge cannot share one diagram; mixing them voids the criterion above.

graph LR
  subgraph MAP["Nodes in the 30 days"]
    N2["D2 tool calls and the agent loop"]
    N6["D6 context compaction and sessions"]
    N12["D12 vector memory + D24 hybrid search"]
    N15["D15 multi-agent graph model"]
    N21["D21 evals and tracing"]
    N22["D22 security and least privilege"]
    N23["D23 MCP and Skills"]
    N25["D25 frontend streaming UX"]
  end
  subgraph EXT["Expands into a dedicated course"]
    MCA["Coding Agent in 21 days"]
    CE["Context engineering in 5 days"]
    RAG["RAG in 14 days"]
    DRAMA["AI short-drama pipeline in 14 days"]
    EVAL["Agent evals in 7 days"]
    SEC["Agent security in 5 days"]
    MCP["MCP in 7 days"]
    SKILL["Agent Skills in 7 days"]
    FEUX["Frontend agent UX in 7 days"]
  end
  N2 -.-> MCA
  N6 -.-> CE
  N12 -.-> RAG
  N15 -.-> DRAMA
  N21 -.-> EVAL
  N22 -.-> SEC
  N23 -.-> MCP
  N23 -.-> SKILL
  N25 -.-> FEUX

Expansion edges read the opposite way from prerequisite edges: prerequisites run upstream and answer "where do I start fixing", expansions run downstream and answer "where do I dig once it is fixed". Reds clustered on D12 and D24 send you to RAG in 14 Days, on D21 to Agent Evals and Observability in 7 Days, on D22 to Agent Security in 5 Days. The three free courses (prompt engineering, Claude, Codex) have no edges on the diagram — they are entrances rather than extensions, so pick them up whenever. Every dedicated course starts from zero and none requires the order on this diagram; the full list is on the courses page.

Next season's training and entry cadence

A runner does not race a marathon every week. A season is planned: volume in training weeks, tapering in race weeks, the most important race at the top of the form curve, with two smaller races ahead of it as tests. Applying is planned the same way, rather than "spray everything the moment the resume is fixed."

The four-week table below is a template; adapt it to your own interview density — somebody who can take three interviews a week and somebody with one have completely different cadences.

The table itself holds little information, and what is valuable is the three reasons behind its ordering:

Why referrals precede direct applications. They are fundamentally different paths: a direct application's resume passes an applicant-tracking system's keyword filter and then HR's bulk screen; a referral lands directly with a hiring manager or a team member, and many companies give referrals their own response deadline. More importantly, a referral is a favor and can usually be used on one person only once — have a friend send a 60-point resume today and you cannot ask them to resend the 85-point version two weeks later. So referrals belong after the resume is finalized and before direct applications: use the scarcest, non-repeatable channel first and the infinitely repeatable one second.

Why not to apply to your first choice first. The person sitting in your first interview and in your fifth is not the same person. Your self-introduction's rhythm, your pauses under follow-ups, and whether you lead with the conclusion or the background can only be calibrated by real interviews — mock interviews fix half, and the other half surfaces only with somebody opposite who can genuinely reject you. Put your first choice in the middle or later part of week 2 with two or three similar roles ahead of it. That is not wasting others' time: you would have considered those seriously anyway, and only the order differs.

Why the review must land within 30 minutes. Half an hour after an interview you still remember the interviewer's words, which term you stalled on, and what their second follow-up was; by the next day all of it collapses into "that did not feel great," and "did not feel great" cannot be split into practice actions. Copy D28's weak-point list's four columns — symptom, root cause, the smallest action to practice tomorrow, how to verify — and do not rename them: laying every review of month two side by side, the entry recurring in one column is your real problem.

The last five checks before launch

The final action of thirty days is genuinely publishing this learning site — not "it runs locally" but somebody opening the link and seeing it. That step has the least technical content (pick a platform, connect the repository, set environment variables, hit deploy) and no small teaching value: it is the first thing you built this month with real users, and a system with real users is judged by entirely different standards than a program on your own machine.

How to click deploy needs no explanation from me; each platform's docs are clearer than I would be. What needs saying is the five checks before you click, all direct callbacks to D22:

The third is the easiest to get wrong and most worth expanding. Rendering content on the frontend and hiding it with CSS is not access control — that prints the answers on the back of the exam paper for anybody to flip over. The correct shape has the server decide whether this session has permission, and content it does not never enters the response body at all. You met that sentence on D22 with a different subject: D22 said prompts govern intent and code governs permission, so however thoroughly the model is persuaded it cannot reach a tool outside the allowlist; here it is that the frontend governs display and the server governs permission, so however the browser edits the DOM it cannot obtain a chapter that was not purchased. The same sentence, two settings — every scheme that persuades a layer not to do something is probabilistic, and only making it unable to obtain the thing is a deterministic gate.

The second's irreversibility also deserves stating. Once a secret has been in a public repository, deleting that commit is useless: forks, mirrors, and crawlers scanning the whole internet for keys took it long ago. The only correct handling is treating it as leaked and rotating immediately. That comes up frequently in interviews too: the question after "how do you manage secrets" is often "what if one leaks," and answering "delete the commit" ends it.

The last sentence connects to D27's integrity line. Once the site is live it becomes something on your resume that can be clicked — including those three repositories' READMEs, architecture diagrams, and the numbers you measured. Being clickable means every sentence on it must survive being clicked. Write "supports automatic failover across providers" in a README and an interviewer really will open the link and look. That is not pressure, it is these thirty days' largest asset: on the vast majority of candidates' resumes, not one line can be verified on the spot.

Source Reading

Hands-On Lab

Today's output is not code, it is a knowledge map and an application plan. Both go into files in the repository — that is what makes you dig them out and revise them next week, whereas anything written on paper is lost by tomorrow.

1. Take pass one over all 127 questions, doing one thing per question: explain it aloud, then mark green, yellow, or red. Skip a red immediately to the next. A little over two hours later you have a color table distributed by day number.
2. Draw your own knowledge map to the four-layer structure, naming nodes in your own words and drawing an edge only when B cannot be understood without A. Then color the reds' day numbers onto the matching nodes and see which chains' upstreams the reds cluster in.
3. Take passes two and three: pass two touches only red and yellow, and pass three only what is still red after pass two. Re-mark colors after each pass, and record anything not green after two passes on the weak-point list.
4. Write month two's application plan: fill the four-week table with specific company names and dates, and for week 1's 5 referrals write who specifically and through which connection. A cell whose name you cannot fill in is what to sort out first this week.
5. Go through the site's five checks item by item, deploy once satisfied, then open any paid chapter in a browser that has never logged in and confirm you see the preview section rather than the full text.

Interview Questions

Today's three questions are in the bank below, all about review and expression: how to sequence revision, how to organize scattered knowledge into one map, and how to explain your month in 3 to 5 minutes. The technical questions filled the previous 29 days, and today's three test how that same knowledge gets communicated. Expand a question and read the analysis before the key points — question 3 is your opening line in every interview of month two and is worth rehearsing several times.

Checklist and Tomorrow

• Go through the full 30-day interview question bank, marking questions you're still not fluent in
• Draw a knowledge map covering the single agent, mini-koda, multi-agent, and advanced topics
• Set a plan for month-two application cadence, and publicly launch the site
• State the three-color marking's three criteria, and explain why pass one only marks and does not dwell
• For every edge on the knowledge map, give the specific reason B cannot be understood without A
• The site is live, and a paid chapter opened in a logged-out browser shows the preview section
• Answer at least 2 of the 3 interview questions without looking at the key points

There is no day 31, so this section closes not with tomorrow's preview but with what to do on month two's first day.

Three things, in order: in the morning, send your resume to at least one person who has genuinely built agents, ask them to pick holes, and finalize it that day rather than dragging a second round; in the afternoon, send those 5 referrals one by one, each with a line on what you built and why you want to be there, rather than mass-sending one paragraph; in the evening, open that four-week table and block week 2's three interview slots on the calendar — block the slots first and somebody will come to fill them.

Over these thirty days you wrote a streaming CLI chat program, split a gateway from workers, built a message bus, leases, and a state machine, drew a multi-agent graph, gave it evaluation, security boundaries, and retrieval, and finally turned all of it into three repositories somebody can click. The technical part is behind you. What remains is simpler and more grinding: telling the same story, to different people, twenty or thirty times. Take your time, and good luck.