Four lessons, about 45 minutes. The last module before the capstone — how you run yourself as an analyst once the honeymoon of "new hire learning everything" is over.
Three months from now, Chidi asks you to rerun an analysis you did in your second week. If the only record of how you built it lives in your memory, you're rebuilding it from scratch. A short doc per real piece of analysis — what question it answered, where the data came from, what cleaning decisions you made, and where the final file lives — turns that rebuild into a five-minute task.
The habit isn't documenting everything exhaustively. It's documenting the handful of things you'd genuinely be annoyed to have forgotten.
Once branch managers realise you exist, requests arrive faster than you can process them one at a time in your head. A simple queue — request, requester, scope agreed (per module 1.4), status, deadline — is the difference between a manageable job and a job that quietly runs your evenings.
| Columns that matter | What was asked, scope actually agreed, who asked, when it's due, current status. |
| The discipline it enables | When a fifth urgent request lands, the queue lets you show — not just claim — that four other genuinely urgent things are already ahead of it, and negotiate honestly about order. |
A recruiter or hiring manager gives a portfolio roughly thirty seconds before deciding whether to look closer. A dump of every SQL query you've ever written fails this test completely. Three real case studies, each following problem → approach → decision it actually changed, pass it.
A one-paragraph case study: "Sahara Mart's nine branches reported sales inconsistently, making week-over-week comparisons unreliable. I built a Power Query pipeline that standardised every branch's export automatically, then a Power BI dashboard replacing a fragmented WhatsApp-thread reporting process. Branch managers now check one number instead of arguing about nine different ones every Monday."
Notice the shape: a real problem, a real approach, and a real, specific consequence — not "I learned SQL and Power BI," which says nothing about judgement or impact.
An analyst take-home assignment is rarely testing whether you can write correct SQL in isolation — it's testing the whole course's worth of judgement, compressed into two hours: did you profile the data first, did you catch an obvious data quality problem, did you state your assumptions, did you communicate the finding clearly.
A take-home that's technically correct but skips all four of these looks like someone who can execute instructions. One that includes them looks like someone who can be handed an ambiguous problem and trusted with it — which is the actual job.
Pick a real piece of work from earlier in this course — a drill, an analysis, anything with a genuine before-and-after.
Pick your strongest piece of work from modules 1–9 — the fan-out join catch in module 3, the nine-problem cleanup in module 4, the dashboard from module 6, or another. Write it up as a portfolio case study, in under 400 words, following lesson 10.3's structure: problem, approach, decision it actually changed or would change.
Whether you can compress real, technically detailed work into something a non-technical reader would actually finish reading and come away impressed by — which is precisely the compression module 9's whole discipline has been building toward, applied to your own work instead of a hypothetical finding.
You now have all ten modules' disciplines. The capstone drops you into a new client's genuinely messy week and asks whether they hold up together, under real pressure, without a lesson telling you which one applies.