Spokeo Data Scientist Interview Questions & Guide 2026

Interviewing at Spokeo

• Practice bank: 9+ questions
• Rounds: 1
• Typical prep: 1–2 weeks

Interview rounds

Round	Questions
Onsite	9

How hard is the Spokeo Data Scientist interview?

Difficulty	Share	Questions
Easy	0%	0
Medium	89%	8
Hard	11%	1

What Spokeo actually tests for

Topic	Share	Questions
Machine Learning	33%	3
Analytics & Experimentation	22%	2
Behavioral & Leadership	11%	1
Coding & Algorithms	11%	1
Data Manipulation (SQL/Python)	11%	1
Statistics & Math	11%	1

The 60-second brief

A Data Scientist at Spokeo plays a pivotal role in powering one of the industry's leading people intelligence platforms. Spokeo aggregates billions of public records, social media feeds, and directory listings to help users connect with others and verify identities. In this role, you are responsible for building the core intelligence that connects these disparate, messy, and highly fragmented data points into cohesive, accurate, and structured digital profiles.

Spokeo candidates report 3 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

What a Data Scientist does at Spokeo

The impact of your work is felt directly by millions of daily users who rely on Spokeo for accurate search results. Because the company deals with massive scale—billions of records across thousands of unique sources—your primary challenges will revolve around entity resolution, deduplication, and data normalization. You will design and deploy machine learning models and heuristics that can determine, with high confidence, whether two distinct records belong to the same individual or business.

This position requires a unique blend of classical machine learning expertise, strong software engineering fundamentals, and deep database empathy. At, data science is not an isolated research function; it is an active engineering discipline. You will collaborate closely with data platform engineers, product managers, and infrastructure teams to ensure your models run efficiently at scale, turning raw, unstructured public data into actionable intelligence.

The Spokeo interview process

Spokeo candidates report 3 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

Technical Screening

Much of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.

What it evaluates

• Whether the query you write matches the plan you just described
• What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
• Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly

How to prepare

• Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
• Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
• Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock

Automated Assessments

This round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.

What it evaluates

• Whether your row counts survive each join, and whether you notice on your own when they do not
• Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
• Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
• Reaching a defensible answer inside the window instead of a refined one after it

How to prepare

• Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
• Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
• Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither

Virtual Interview Rounds

Because the format is not fixed, prepare the reasoning rather than the ritual. Nearly every version of this round draws on the same underlying material: a design you can defend, a metric you can define exactly, an analysis whose assumptions you can state out loud. Only the wrapper changes, whether that is a take-home, a live case, a deep dive on past work, or a rough estimate on a whiteboard. Answers rehearsed to fit one shape stall the moment the shape differs. Practise naming the assumption behind a number, then saying how much the conclusion moves if that assumption is wrong.

What it evaluates

• Whether your justification for a method survives the question 'why not the simpler thing', including when the simpler thing would have worked
• Precision under pressure: what exactly counts as an active user, a conversion or a success, over what window, with what exclusions
• Whether you carry an argument through to a recommendation instead of stopping at a list of tradeoffs

How to prepare

• For each project you plan to mention, write the metric definition in one sentence: numerator, denominator, time window, exclusions. Say it out loud once, because vagueness shows up in speech before it shows up on paper.
• Rehearse the same project at three lengths: two minutes, ten minutes, and a deep dive on one technical decision. Cutting live is harder than it sounds.
• For your headline result, write down what would have had to be true for it to be wrong, and how you ruled that out.

Questions Spokeo candidates report

SQL and data manipulation

Decide what one row of the output means before typing a single join. Nearly every question of this kind resolves into a spine at some grain, one row per user or per session or per user-day, with measures attached to it. Build the spine first, collapse every other table down to that grain, then attach. What most often separates a strong answer from a weak one is refusing to join one fact table straight onto another: pre-aggregate the second one, or test it with EXISTS. A duplicate row on the many side multiplies a measure you already computed, and nothing in the result looks broken.

• Write a SQL query to find duplicate records in a user table where the email is identical but the registration dates differ.
• How would you optimize a database join between a table with billions of rows and a lookup table with thousands of rows?
• Given a list of names, write a function to identify and group potential phonetic matches (e.g., "Jon" and "John").

Statistics and probability

Treat a hypothesis testing question as an audit of preconditions rather than a request for a procedure. Every test carries a model of how the data were generated, and the useful part of your answer is where that model could be wrong here. Independence fails most often and gets checked least: repeated measurements on one user, or many sessions inside a single account. When units inside a cluster move together, the naive variance understates the true one and the test rejects a true null far more often than its stated level. Name the unit you are willing to call independent before you name a test.

• Explain the bias-variance trade-off and how you would diagnose a model suffering from high variance.

Machine learning and modelling

A model that clearly improves offline can move nothing online, and the useful question is why. The candidate set feeding it may already exclude the cases it would have caught. The score may enter a surface where a cap, a fallback or a business rule blunts it. Training labels may describe a population the live traffic no longer matches, because they were collected under an earlier policy. Treat the offline number as a filter rather than as proof, plan the launch as a measured rollout with a guardrail and a rollback, and say which of those gaps you would check first.

• What are the trade-offs between a Random Forest model and a Gradient Boosted Decision Tree (GBDT) in production?
• Explain the difference between L1 and L2 regularization and how they affect model weights.

Behavioural and stakeholder questions

A large share of these land on disagreement: someone wanted a different answer, a different metric, or a different date. The weak version of the answer makes the other person wrong and the data right. The strong version treats their position as a constraint you had not priced in, usually a cost, a deadline, or a commitment made outside your view. Before you say what changed their mind, say what evidence would have changed yours. That one sentence separates someone who argues with numbers from someone who reasons with them, and it is the sentence that survives the follow-up.

• How do you handle highly imbalanced datasets when training a binary classifier?
• How do you handle missing or incomplete fields (such as a missing middle name or partial date of birth) when performing record linkage?

Other topics

A large share of these questions are standard material in unfamiliar clothing: a probability puzzle, a sizing, a question about how a sample was drawn. Work them by building from quantities you can defend rather than quantities you wish you had. Write the estimate as an explicit chain, population times rate times frequency, and label where each number came from, whether it is a figure you know, a ratio you are assuming, or a guess with a range around it. Then check the total a second way. Answers rarely fail on the arithmetic. They fail because nobody sanity checked the order of magnitude.

• Given two user profiles with matching phone numbers but different addresses and names, how would you determine if they belong to the same person?

Practice exercises with worked solutions

The prompts above tell you what gets asked.

Find paid seats that never called the API

dim_user_membership carries user_id, account_id, seat_type, is_service_account, deactivated_at and last_seen_at. fct_api_request carries user_id, which is null whenever the caller is a service account or an unattended key, plus account_id, request_at and http_status. For a single account, list every licensed_paid seat with is_service_account = false and deactivated_at null that issued no request at all in the trailing 90 days, returning user_id and last_seen_at. A first draft writes NOT IN against a subquery over fct_api_request.user_id. State exactly what that draft returns and why, then write the correct query.

How a strong candidate works it

• Read the column comment first: user_id is nullable on the fact, so the subquery almost certainly contains at least one NULL for any account that runs a service account or an unattended key.
• Work the three-valued logic out loud. x NOT IN (a, NULL) expands to NOT (x = a OR x = NULL); the second disjunct is UNKNOWN, so for any x not equal to a the whole predicate is UNKNOWN and the row is filtered out. The draft returns zero rows, which reads as full seat utilisation.
• Rewrite as NOT EXISTS with the 90-day and status predicates inside the correlated subquery. Putting them in the outer WHERE instead turns the anti-join into a different question and silently changes the answer.
• Correlate on both user_id and account_id. A membership is (user_id, account_id) and one person can hold memberships in several accounts, so correlating on user_id alone marks a seat as active because that human was busy somewhere else.
• Filter the seat side to seat_type = 'licensed_paid', is_service_account = false and deactivated_at IS NULL, and say what the resulting count means next to contracted_seats on the current subscription row.

Expected result (15 min): A list of user_id and last_seen_at for licensed, non-service, active memberships on that account with no request in 90 days. The NOT IN draft returns zero rows whenever the account has any service-account or unattended-key traffic, and returns the right answer only by accident on accounts that have none.

Check yourself

• The NOT EXISTS result and the LEFT JOIN ... IS NULL result return identical user_id sets.
• Idle seats plus seats with at least one request in 90 days equals the total licensed non-service active membership count for the account.
• Forcing a NULL into the subquery (union a SELECT NULL) leaves NOT EXISTS unchanged and empties the NOT IN version, which demonstrates the failure on demand.

Follow-ups

• Adding AND user_id IS NOT NULL to the subquery also fixes NOT IN. Why is NOT EXISTS still the form you would leave in the repository?
• last_seen_at looks like a shortcut for the whole query. What does it actually record, and where does it disagree with API activity?
• This is a seat-reduction risk list. What threshold would you attach before handing it to an account team, and what happens to seats below it?

Audit daily usage rows for grain and arithmetic violations

You are handed fct_usage_daily as a pandas DataFrame with account_id, workspace_id, sku_code, usage_date, billable_quantity, included_quantity_applied, overage_quantity, list_amount_cents, discount_amount_cents, net_amount_cents, cogs_cents, is_restated, first_written_at and restated_at. The declared grain is one row per (account_id, workspace_id, sku_code, usage_date). Write audit(df) returning a DataFrame with one row per failing check: check name, failing row count, and one example key. Cover at minimum grain duplication, negative quantities or amounts, the identity net = list - discount, billable = included + overage, and rows where is_restated is true but restated_at is null.

How a strong candidate works it

• Check the grain before anything else with df.duplicated(subset=key, keep=False), and count rows rather than groups so a key appearing twice contributes 2 — if the grain is broken every arithmetic count below it is uninterpretable.
• Express each invariant as a boolean Series over the whole frame. The cent columns are integers and compare exactly, so use !=; the numeric(18,6) quantity columns need np.isclose with atol=1e-6 because included + overage is a decimal sum.
• Handle null as its own failure mode. Comparisons against NaN return False, so a check written as rows_that_pass = (a == b - c) silently files every null-amount row wherever the negation happens to land; build each check as violations = ~condition | column.isna().
• Collect the checks as a list of (name, mask) pairs and assemble the output in one pass, so adding a check is one line and every check reports in the same shape.
• Order the output with structural failures (grain, null keys) above arithmetic failures, and report zero-count checks too — a check that silently disappears when it passes is indistinguishable from a check that was never run.

Expected result (20 min): One row per check with failing_rows as an integer count of rows rather than groups, and a JSON-serialisable example key for any check with a non-zero count; a single doubled key contributes 2 to the grain check.

Check yourself

• df.groupby(key).size().max() == 1 if and only if the grain check reports zero.
• When the net check reports zero, sum(net_amount_cents) == sum(list_amount_cents) - sum(discount_amount_cents) exactly.
• Running audit on df.sample(frac=1, random_state=0) gives identical counts; the checks must not depend on row order.
• Corrupting one net_amount_cents by a single cent raises exactly one check's count by exactly 1.

Follow-ups

• Which of these should block a dashboard refresh and which should only warn?
• Rows with is_restated = true legitimately change value after first write. How do you make yesterday's audit result reproducible?
• How would you extend this to catch a partition that is missing entirely rather than wrong?

Define success for widening the free usage allowance

A proposal triples the free-tier included allowance on the requests_thousands SKU. Finance expects the count of weekly active organisations to rise. You have fct_usage_daily (billable_quantity, included_quantity_applied, overage_quantity, net_amount_cents, cogs_cents, is_restated), dim_account (account_status, is_internal, converted_to_paid_at) and fct_api_request (traffic_class, http_status, environment). Define the primary metric this change should be judged on, two guardrails, and the numeric decision rule you would agree before launch. State explicitly how the obvious metric can be satisfied without the product getting better for anyone.

How a strong candidate works it

• Name the mechanism before naming any metric. A larger allowance moves quantity out of overage_quantity into included_quantity_applied, so net_amount_cents falls while cogs_cents is unchanged, and accounts that previously sat under the production volume floor now cross it without paying anything. A count of active accounts therefore moves for reasons that have nothing to do with the product.
• Set the primary metric at the account grain: weekly active organisations with at least one successful request (http_status < 400) in a workspace where environment = 'production' and traffic_class in ('interactive','batch'), over accounts with is_internal = false. Report accounts that existed before launch separately from the post-launch signup cohort, so the number is not quietly an acquisition metric.
• Attach the two guardrails that close the gaming routes. First, gross margin per account, (sum(net_amount_cents) - sum(cogs_cents)) / sum(net_amount_cents) computed per account per month and reported as a distribution, specifically the count and revenue share of margin-negative accounts. Second, the free and trial share of weekly active organisations.
• Add the conversion link the change is supposed to buy: free-to-paid conversion within 90 days for the affected cohort, read from converted_to_paid_at. Without it, the primary metric rewards permanent free use indefinitely.
• Write the decision rule with numbers before launch: ship if weekly active organisations rise by at least the pre-agreed threshold, 90-day free-to-paid conversion does not fall, and the count of margin-negative accounts stays under a stated cap. Note that the margin guardrail can only be read after the metering settling window has closed, since fct_usage_daily rows restate in place.

Expected result (20 min): A two-part readout: the simulated change in weekly active organisations split by whether the account was already active, and the change in the count and revenue share of margin-negative accounts. The answer names the primary metric (weekly active organisations on qualifying production workloads), two guardrails (the per-account margin distribution and the free/trial share of actives), a pre-agreed numeric rule, and states plainly that the primary metric alone can be satisfied entirely by accounts that will never pay.

Check yourself

• Simulated net_amount_cents can only fall or stay flat for every account; any account whose simulated revenue rises means the allowance was applied in the wrong direction.
• cogs_cents must be byte-identical before and after, because an allowance changes what is charged, not what is served.
• The sum of per-account margins must reconcile to the aggregate margin computed directly from fct_usage_daily totals over the same accounts and months.

Follow-ups

• Weekly active organisations jump 14% in the first week after launch. How much of that can you attribute to the change with no control group, and what would you need to do better?
• An account settles at usage permanently just below the new allowance and never pays. Does your primary metric count it as a success, and should it?

Monthly logo churn triples with no change in satisfaction

Monthly logo churn, computed as churned accounts divided by all paying accounts, tripled last month. Contracts are annual. From fct_subscription_period (account_id, term_start_date, term_end_date, amendment_type, auto_renew, booked_at, superseded_by_id, is_current) and dim_account (account_id, churned_at, account_status, employee_band, acquisition_channel), rebuild churn on the renewal-eligible base, separate calendar effects from customer behaviour, and state whether retention actually changed. Note that churned_at is sometimes set when the record was updated rather than at term end.

How a strong candidate works it

• Rebuild the denominator as accounts whose term_end_date falls in the month. An account eleven months from renewal sits in the current denominator while being structurally incapable of entering the numerator, so on annual contracts the published rate understates the truth by roughly the reciprocal of the annual renewal fraction and moves with the signing calendar.
• Plot the renewal-eligible base by month across two years. A signing surge twelve months earlier reproduces itself as an eligibility surge now, and a rate whose denominator ignores that tracks the sales calendar rather than customer sentiment.
• Date each churn by term_end_date, never by churned_at or an update timestamp. Inspect the distribution of churned_at minus term_end_date: a backlog cleared in one batch appears as a mass at a single date and shifts losses into whichever month the operations team did its paperwork.
• Apply the 45-day grace for late renewal paperwork so the most recent month and a half is marked not reportable, rather than printing a number that will rise once the paperwork lands.
• Compare corrected gross logo retention against its own trailing distribution, and if a real change survives, cut it by employee_band, acquisition_channel and plan_tier before proposing any cause.

Follow-ups

• Some contracts in the window have not reached their renewal date. When does this require a survival estimator rather than a simple rate, and which one would you use?
• How do you report churn to an audience that wants a monthly number when the underlying event is annual and lumpy?

Announce a metric fix that cuts the headline number

Weekly active organisations, the count on the company dashboard, has never excluded rows where dim_account.is_internal is true, and it counts traffic with traffic_class in synthetic_monitor and load_test. Correcting both reduces that count by 11 percent and removes most of the growth reported over two quarters. The figure appears in a board deck and in two teams' quarterly goals, one written on the count and one on the weekly active organisation ratio, whose denominator is accounts whose account_status was in ('trial','free','active_paid') through the week. Decide the order in which you tell people, what the dashboard shows during the transition, and what you propose happens to goals already set against the old definition.

How a strong candidate works it

• The interviewer is probing whether you can land a correction as an operational change with a plan attached, rather than as an announcement other people then have to clean up after.
• Quantify each exclusion separately before telling anyone: internal accounts, synthetic monitors, load tests. Three known quantities are a discussion; one alarming total is an argument.
• Be precise about which side of the metric each exclusion touches, because one team's goal is on a count and the other's is on a ratio. The traffic-class filters remove requests, so they shrink the numerator only. Dropping internal accounts removes them from the ratio's denominator as well, since internal accounts carry ordinary account_status values and therefore sit in that denominator. Internal accounts are active in almost every week while the real base is not, so the numerator loses a larger share than the denominator and the ratio falls by less than the count does. Compute both and say which one the 11 percent is before anybody assumes.
• Check whether the trend changes, not only the level. A constant 11 percent shift is a rebasing and nothing more. A shift that widens over time means the reported growth was partly internal or synthetic, which makes the existing goals unachievable as written and changes what you are asking teams to do.
• Sequence the disclosure: the metric owner and the two teams whose goals move first and privately, then the board channel with a written bridge, then the dashboard. The dashboard is last because a number that changes without explanation is read as instability rather than as a fix.
• Run both series for one reporting period with the bridge visible, restate history rather than letting the series break at a date, and set the date the old series is removed.
• Propose the goal treatment yourself: rebase each target by the shift measured on the metric that target is written against, rather than leaving each team to negotiate individually, which is where corrections of this kind usually die.

Follow-ups

• One team's quarterly goal is now unreachable. Rebase the target or let it miss, and what does each choice teach the organisation?
• How would this have been caught when the metric was first defined?
• What else on that dashboard shares this failure mode, and how would you find out this week?

Where candidates lose points

Reading consumption metrics before the metering lag window has closed

Usage pipelines land late and correct themselves, which is exactly what is_restated and restated_at record. A dashboard queried on day T sees a partially populated tail for the last several days, so the most recent points always slope downward and always look like a regression. Analysts then explain the artefact, and sometimes ship a change to fix it. Establish the empirical settling time by measuring how much a given usage_date's total moves between first_written_at and its final value, exclude that many trailing days from every reportable figure, and never compare a fresh period against a settled one.

Comparing accounts that received a sales or customer-success touch against those that did not

Assignment of coverage is deliberate and pulls in both directions at once: the largest accounts get a named owner because they are valuable, and the accounts showing distress get one because they are at risk. The comparison therefore mixes a strong positive selection with a strong negative one, and the naive estimate can come out with either sign depending on which assignment rule dominated during the period examined. Nothing about matching on observed size fixes this, because the risk signal that triggered coverage is usually the same signal that predicts the outcome. It needs either an actual randomised or staggered rollout of coverage, or a design built on a capacity constraint or territory boundary that assigns coverage for reasons unrelated to account health.

Sizing estimates built on unnamed, unrevisable assumptions

Write each assumption as a named number you can change, then show the arithmetic so the interviewer can challenge one input instead of the whole answer. Finish by saying which assumption the result is most sensitive to, which matters more than the point estimate.

Reaching for a model before the target metric exists

Before naming an algorithm, write down the label, the prediction time, and the action that changes when the score crosses a threshold. If you cannot say what decision the output drives, any modelling choice is guesswork dressed up as method.

Weakness triage, driven by a day-one diagnostic

Instead of guessing where the week should go, day one measures it under a fixed rubric and allocates the remaining hours in proportion to the gaps. The method is deliberately rigid: the allocation is written down before any studying starts and is not renegotiated when a topic turns out to be unpleasant.

Day 1 — Diagnostic, scored before you study anything

• Sit a 100-minute timed diagnostic in four blocks: 30 minutes of SQL across three prompts, 25 minutes of short-answer statistics, 25 minutes on one modelling or case prompt, and 20 minutes delivering one behavioural story aloud.
• Score each block from 0 to 3 on a fixed rubric where 3 is correct and fluent, 2 is correct but slow or prompted, 1 is partially correct, and 0 is stuck, grading the output rather than how the attempt felt.
• Allocate the hours for days two to five roughly in proportion to 3 minus the score in each block, write the allocation down, and commit to not revising it midweek.

Deliverable: A scored rubric and a fixed hour allocation for the rest of the week.

Day 2 — Largest gap: find the boundary rather than the subject

• Break the weakest area into five named sub-skills (for query work: grain control, window frames, date arithmetic, set logic with NULLs, and reading a query plan) and rate each one, so the rest of the week targets a sub-skill instead of a subject.
• Solve three problems chosen to sit just above where the rating drops off, and for each write the first move you failed to make.
• Re-solve one of them from memory four hours later, on paper, with nothing open.

Deliverable: A five-item sub-skill map with the two blocking sub-skills circled.

Day 3 — Largest gap: drill the blocking sub-skill

• Do eight short repetitions of the same shape rather than eight different problems, so what you practise is the pattern and not the puzzle.
• Write the rule you now hold in one sentence, then test it against a case built to break it: a ranking function over a column with ties, or a two-sample test on observations that are obviously dependent.
• Have someone else read your one-sentence rule and find the precondition you left out.

Deliverable: One rule statement with its preconditions attached and one counterexample that would have caught the incomplete version.

Day 4 — Second gap, plus maintenance on your strongest area

• Run the same sub-skill map and boundary protocol on the second-largest gap, compressed into half the day.
• Spend 25 timed minutes on your strongest area to stop it decaying, choosing the hardest problem you can still finish rather than an easy warm-up.
• Compare how the two areas fail: whether you lose time on recall, on setup, or on arithmetic, because the fix differs for each.

Deliverable: A second sub-skill map plus a one-line diagnosis of how each area fails you.

Day 5 — The gap that is not a skill

• Record yourself answering one technical and one behavioural prompt, then count two things in the playback: how many seconds before your first clarifying question, and how many sentences you started without knowing where they ended.
• Rewrite your three most-used stock phrases into shorter versions, and practise saying "I do not know, here is how I would find out" without softening it into a guess.
• Deliver one answer again with a hard 90-second limit to force structure before detail.

Deliverable: Two recordings with a counted improvement in time-to-first-question.

Day 6 — Retest under day-one conditions

• Sit the same 100-minute diagnostic structure with new prompts of comparable difficulty and score it on the identical rubric.
• Compare block by block, and for any block that did not move, change the method rather than adding hours: a block stuck at 1 usually means the practice was too varied, not too short.
• Write which single block you would still lose the offer on.

Deliverable: A second scored rubric placed next to the first, with one named remaining risk.

Day 7 — Full loop under interview conditions

• Run a 60-minute mock covering the two blocks that moved least, with an interviewer instructed to interrupt and change direction.
• Write your recovery script for the moment you go blank: restate the question, state your assumption, name the first thing you would check.
• Reduce the week to the rule statements you wrote, each with its preconditions attached, then say every one of them out loud without reading it and cut any you cannot state in a single sentence, since a rule you have to reconstruct mid-answer will not survive being interrupted.

Deliverable: A one-page card holding the recovery script and only the rules you could state from memory.