How this course works
Work each customer case in the course's loop — written answer first, strong answer second, rubric third — and plan the hours so the loop fits.
On this page
Thirty-four lessons and thirty exercises, and the exercises are the course. A lesson gives you the frame and the numbers; an exercise puts you in a room with a customer, a volume, a deadline and one decision, and asks for your answer in writing. The strong answer and the rubric are there to mark you, and they only work if you write before you read them.
What an exercise is
Every exercise has the same five sections in the same order. The situation is a concrete scenario in 100–200 words: who the customer is, what volume they handle, what the deal promised. The question is one decision or one estimate, never a definition. A strong answer shows the reasoning, ends in a number or a decision, and names the evidence that would reverse it. Rubric is four to six bullets, each an observable thing the answer did. Where answers go wrong is two or three weak answers and why each loses.
| kind | the question asks you to… | count |
|---|---|---|
| case | decide what to do, and say what evidence would change it | 8 |
| estimate | produce a number from stated assumptions, arithmetic shown | 5 |
| design | lay out a mechanism — a credential list, a RACI, an output schema — and defend it | 6 |
| critique | find what is wrong with a given document, demo or result, and say what to do instead | 8 |
| code | implement one solve() against a stated contract; a test runner proves it | 3 |
The three code exercises run on the same runner as the DSA course's problems — the mechanics of the solving loop there apply here unchanged.
The loop
Read the module's lessons first; they hold the numbers the exercises assume. Open the exercise, read the situation and the question, and stop. Write your answer: 45 minutes on a clock, in a document, not in your head. For an estimate that means the assumptions, the arithmetic and the number; for a case, the decision, the reasoning and the evidence that would reverse it. Then open the strong answer. Score yourself against the rubric bullet by bullet, binary: either the page does the thing the bullet names or it does not. Write one line naming the bullets you missed. A week later, same situation with one number changed, blank page.
A pass through the first case in the course, the kickoff that asked for a chatbot, shows what the loop produces. A regional insurer takes 1,200 claims a working day; 28 handlers triage at a median 11 minutes each, 7 of those minutes spent finding the governing wording in 340 pages of policy PDFs and 4 deciding the route; the deal promised 30% faster triage in 8 weeks, and the VP of Claims opens the kickoff asking for a chatbot. A typical first written answer scores 3 of 5: it separates the ask from the outcome, proposes a definition of done with a number, a date and a measurer, and keeps the sponsor's goal intact, but never uses the 7/4 split to say where the minutes are. The one-line note reads "locate the minutes before choosing the build". A week later the split is the first thing on the page: 30% of 11 minutes is 3.3 minutes, and half of the retrieval step covers it with no new interface.
Why the order is the method
The mistake is to read the strong answer first. It reads as obvious, every sentence of it, and the natural response is "I would have said that". Recognition is cheap. The interview and the customer both pay for production: a number and a decision, on a clock, from a blank page. The rubric is written so that vocabulary cannot satisfy it — "uses the 7/4 split to locate where the minutes are" is either on your page or it is not — but reading first turns every bullet into a recognition test, and recognition tests are passed by default. Readers who read first produce, a week later, the strong answer's phrasing without its arithmetic, which is the exact failure an interviewer listens for.
The 45 minutes is the length of the case round in a typical FDE loop, and the last module turns eight of the exercises into the four rounds of your own mock. Writing is the role's medium, and a decision you can only say out loud is one you have not finished. The retry a week later separates two kinds of miss: a bullet missed once is noise; a bullet missed twice is a gap in the frame, and the lesson, not the exercise, is where that gets fixed.
The numbers the course uses
Every estimate runs on named constants so no two exercises contradict each other. The contracted per-million-token input rate is r, and output is priced at 4r. No model cost in the course is a dollar figure; it is a multiple of r, and the customer multiplies by their own contract. Tokens are counted at an assumed 0.75 words per token, so a 3,200-word prompt is about 4,300 tokens. Capacity arithmetic is borrowed from the system-design course rather than re-taught: 1 million requests a day is about 12 QPS, peak is 2–5 times the average, and Little's Law gives concurrency as arrival rate times residence time. The insurer's claims arrive 08:00–18:00 with 60% between 09:00 and 12:00, so the peak is 720 claims in 3 hours, about 0.067 a second; at a mean residence of 8 seconds that is 0.067 × 8 ≈ 0.5 requests in flight — one worker with a small queue. Each figure is labelled as an assumption so you can substitute yours.
How the modules fit
The nine modules after this one are in the deployment's order. Discovery before the deal, because you cannot score a deal you have not heard the customer describe. The deal before architecture, because the pilot's shape depends on what was promised. The three-day prototype runs on a one-off export and comes before the data plumbing that replaces it. Data before prompts, prompts before evals, evals before the security review, rollout and handover after all of them, and the interview last because every round draws on the nine before. One deployment — the insurer's claims-triage pilot — carries most of the exercises, so the 1,200 claims a day you meet in module 1 are the token budget in module 3, the 200-case eval set in module 6 and the rollout gates in module 8.
In an interview
Every rubric reads aloud unchanged as a hiring manager's question, so the thirty rubrics are the question bank. What is being tested, in every round, is whether you reach a number and a decision with the arithmetic visible, inside the time, and then say what evidence would reverse you. A customer tests the same thing a week at a time: a scoping doc with a definition of done, or a status that says "on track"; a weekly update with a number that moved, or a list of things done.
The mistake that loses points is answering in the strong answer's vocabulary — "separate the ask from the outcome", "define done before building" — without the arithmetic that does it. A rubric bullet names an act, not a phrase; a page with the phrase and no number scores zero on that bullet, and the interviewer scores the same way.
Check yourself
1. You have five hours a week for six weeks. An exercise takes about an hour: 45 minutes writing, 15 scoring. Do you do all thirty once, or fewer with retries?
Fewer. 30 hours covers 30 exercises once and leaves zero retries, and a retry is the only thing that tells you whether a missed bullet was noise or a gap. Do two per module for modules 1–8 and all four interview-round exercises (20 hours), then spend 10 on retries of the ten lowest scores. An interview in two weeks reverses this: the four module-9 rounds first, each retried once, nothing else.
2. You scored 3 of 5 on the chatbot kickoff, missing "uses the 7/4 split" and "says what would have to be true for the chatbot to be the right first build". Reread the lesson or retry next week?
Reread first. The two misses are one miss: you never located the minutes, so you could not say when a chatbot would be right (when the search step is already under 3 minutes and the handlers' time goes to questions the policy set does not answer). A retry alone reproduces the gap, because the frame lives in map the workflow before the model, not in the exercise.
3. You opened the strong answer of an estimate before writing. What is the exercise worth now, and what do you do with it?
As a test, nothing for a fortnight: the number is in your head. As a lesson, most of its value: double the daily volume, halve the prompt, and redo the arithmetic, because the method bullets ("converts words to tokens with a stated ratio") still test when the final number no longer does. Retry the original in two weeks rather than one.