Day 70 Β· The data interview writeup

Week 10 Checkpoint: EDA Report

You will be able to
  • Recall the week's core idioms (NumPy semantics, pandas selection, join audits, cleaning contracts) from memory
  • Execute the full pipeline β€” EDA β†’ cleaning β†’ feature plan β€” on a dataset you have never touched
  • Deliver a stakeholder-readable report with 5 defensible findings in the sentence format
  • Self-grade against the rubric and map every gap to a revisit day
Today's ~120 minutes
Spaced-rep warm-up: full Week 10 due deck10 min
Guided: idiom sprint + checklist reconstruction35 min
Practice: 15-minute reconnaissance of the fresh dataset15 min
Project: the EDA report, hard 75-minute equivalent (build core in 50)50 min
Quiz + self-grade against rubric + gap map10 min

Builds on: Day 64 β€” NumPy in anger Β· Day 66 β€” Wrangling & join audits Β· Day 67 β€” EDA checklist Β· Day 68 β€” Cleaning & validation Β· Day 69 β€” Feature engineering

The analogy

A journalist's interview only becomes journalism when the story is written β€” and written for readers, not for other journalists. Today you take everything Week 10 built and produce the writeup: a fresh dataset you have never seen, interviewed, cleaned, and turned into findings a business person can act on. No new techniques. The test is whether the checklist lives in your hands or only in your notes.

The order of the day mirrors how skill actually consolidates. First, retrieval drills: write the week's idioms from memory β€” the broadcasting rule, the join audit, the fitting discipline β€” because fetching them cold is what cements them, and Day 63 proved that re-reading is a placebo. Then the main event: the checkpoint project, done timeboxed like a real engagement. The constraint that makes it professional rather than academic: every finding must be a sentence a skeptic can check, every cleaning decision must be logged and justified, and the feature plan must name what is EXCLUDED and why. That last habit β€” documenting what you did NOT use β€” is what separates an analysis someone can trust from a notebook someone must audit.

Why this matters on the job

This checkpoint is the program's first full FDE-shaped deliverable: ambiguous data in, stakeholder-readable insight out, with the engineering receipts attached. It is the dress rehearsal for Day 77's model card, Day 83's churn project report, and Day 105's non-technical explainer β€” and the EDA-report format is literally what a customer engagement's first week produces. The retrieval drills matter for a nearer reason: Week 11 starts fitting models tomorrow, and it assumes this week's idioms are reflexes, not references.

Guided practice

guided 1

Idiom sprint β€” the week from memory

20 min
  1. Closed book, blank file. Write and RUN, from memory, one minimal working example of each: (a) center a (100, 3) array's columns via broadcasting; (b) demonstrate a slice-view mutation and its .copy() fix; (c) a boolean-mask filter with two ANDed conditions in pandas; (d) a correct .loc write that chained indexing would have botched; (e) a merge with validate="m:1" and indicator=True on two 5-row toy frames; (f) a groupby with named aggregation; (g) fit a StandardScaler on train and transform test.
  2. Diff each against your Week 10 files. Green / yellow / red as on Day 63.
  3. For every yellow/red: write a flashcard AND say aloud the production consequence of getting it wrong (row explosion double-counts revenue; leaked scaler inflates metrics…). Consequences are the glue.
  4. Time yourself. Under 15 minutes with ≀ 2 yellows is fluent; over 20 means schedule a 30-minute idiom review before Day 71.
guided 2

Checklist reconstruction + report skeleton

15 min
  1. From memory, write the seven EDA interview stages and the three leakage-interrogation questions. Diff against your Day 67 eda_checklist.md β€” card any stage you dropped.
  2. From memory, write the cleaning pipeline's five commandments (raw is read-only; script everything; log counts; contract at the end; mechanism before method). Diff against Day 68's report.
  3. Now set up the checkpoint: create eda_report.md with the five required section headers and a named stakeholder, and report_code/ with an empty run_all.py. Choose your dataset (public CSV or the seeded generator) and write ONE sentence: what decision could this data inform, and for whom? That sentence is your report's north star β€” every finding must serve it.

On your own

Pre-flight: interrogate the fresh dataset

15 min

Before the full build, run the 15-minute reconnaissance you would do in a customer's conference room: load the fresh dataset, run the identity and gaps passes (shape, dtypes, head, isna map, value_counts on key columns), and write down β€” in exactly three bullets β€” the three biggest risks you can already see (a suspicious column, a skew, a missingness pattern, a possible unit issue, a candidate leak).

Constraints: 15 minutes, no cleaning yet, no plots beyond two quick histograms. The skill being drilled is triage β€” deciding where the report's effort should go BEFORE spending it. If you chose the seeded generator, expect to find at least one planted issue in this pass; if you chose a public dataset, whatever you find is real, which is better.

Hints: grain first ("what does one row mean?") β€” misunderstanding grain invalidates every later number; then the columns a stakeholder would ask about first.

Ship before you stop

The Week 10 checkpoint: a stakeholder-ready EDA report

Execute the full pipeline on your fresh dataset in a hard 75-minute timebox: EDA per your checklist, cleaning with logged repairs and a validation before/after count, and the feature plan with encodings and exclusions β€” delivered as eda_report.md + report_code/run_all.py (which reproduces every number in the report from the raw file in one command). If you use the offline option, generate it with: rng = np.random.default_rng(seed=70) β€” 2,000 e-commerce sessions with columns [session_id, ts (string dates), device, pages_viewed, duration_min (log-normal), revenue (zero-inflated), converted], then plant: 3% "unknown" devices, 25 duplicate sessions, revenue in cents for device=="mobile", and a discount_applied_at_checkout column generated FROM converted (the leak). Commit everything, then self-grade against the rubric and write your gap map (miss β†’ revisit day).

Rubric β€” check what you completed (0/6)

Common mistakes & misconceptions

  • Skipping the recall drills to "save time for the project". The drills are why next week's modeling flows; the project alone only exercises what you already retrieve easily.
  • Choosing a dataset you already know. Familiarity hides the very gaps this checkpoint exists to expose β€” fresh data or the provided generator, no exceptions.
  • Blowing the timebox on plot polish. Stakeholders act on ranked sentences with numbers; a report that is 80% done everywhere beats one perfect histogram.
  • Reporting findings without denominators or with precision the n cannot support β€” "conversion is 3.847%" from 400 sessions is Day 60 amnesia.
  • Cleaning interactively and reporting numbers your run_all.py cannot reproduce. If the script and the report disagree, the report is fiction.
  • Writing the feature plan without an EXCLUDED section. What you left out (and why) is half the evidence that you can be trusted with the modeling next week.
Knowledge check

Q1. You merge sessions (2,000 rows) with a device-metadata table and end with 2,041 rows. Which single keyword would have turned this silent bug into a loud error?

Q2. A column in the fresh dataset predicts the target almost perfectly. Per this week's discipline, it belongs…

Q3. Your report says "mobile revenue looks 100Γ— higher than desktop". Before publishing this as a finding, this week says to first suspect…

Go deeper β€” curated resources

docspandas User Guide (reference while building) β†—15 mincourseGoogle Technical Writing β€” writing for non-specialist readers β†—25 mincourseKaggle Learn β€” Pandas & Data Cleaning (targeted review of weak spots) β†—20 min
If you have a third hour
  • Read a real Kaggle EDA notebook critically β†— β€” Find a highly-voted EDA notebook for any dataset and grade it against your rubric: where are the denominators? The excluded features? The honest negatives? Critiquing others' EDA is the fastest way to sharpen your own.
Done means
  • Idiom sprint completed with ≀ 2 yellows (or the review session scheduled)
  • eda_report.md shipped with all five sections and five sentence-format findings
  • run_all.py reproduces the report's numbers from raw data in one command
  • Self-grade done: rubric score recorded, every gap mapped to a revisit day
How this connects

← Back: Everything here is this week compressed: Day 64's arrays under Day 65–66's pandas, Day 67's interview, Day 68's contracts, Day 69's feature plan. The report-writing bar comes from Day 63's "no claim without an interval" standard.

Forward β†’: Tomorrow (Day 71) the feature matrix you planned meets its first model β€” sklearn fit/predict on exactly this kind of prepared data. Day 77's model card and Day 83's churn report are this document plus a model; Day 105 and Day 168 push the stakeholder-writing muscle further.