Take-home assignment review, the questions asked about your work

Before the call

Reopen your submission the day before and write down three things: your main finding in one sentence, the biggest assumption you made, and the weakest part of the analysis. Most review questions are versions of those three.

Stage 1: understanding the brief

"Summarise what you were asked and what you found in two minutes."

Lead with the answer, not the process. "The brief asked why repeat purchases fell in Q2. I found most of the fall comes from customers acquired during the March sale, who repeat less than earlier cohorts; existing customers' repeat rate is roughly flat." Then one sentence on how you got there.

Reviewer is checking: whether you can state a conclusion without walking through every step.

"Was anything in the brief ambiguous? What did you do about it?"

Name it and your decision. "'Repeat purchase' wasn't defined, so I used a second order within 60 days and noted it. With 90 days the conclusion holds." If you emailed a question and got no reply, say so.

Stage 2: the data

"What problems did you find in the data?"

Be specific: duplicates, missing values, a test account, dates in two formats, refunds recorded as negative orders. Say what you did with each and how many rows it affected.

"How do you know your totals are right?"

This is where the checks at the end of this article earn their keep. "I reconciled total revenue per month against the summary sheet provided; they match within ₹1 of rounding, except April, where I found 14 duplicated orders."

Reviewer is checking: that you checked before you concluded. A candidate who never reconciled anything usually fails here.

Stage 3: method and choices

"Why this metric and not another?"

Tie it to the question. "Repeat rate per cohort, because the overall rate mixes new and old customers and the mix changed after the sale."

"Why this chart?"

"A line per cohort, because the comparison is across time and cohorts; a single bar chart of overall rate would hide the mix effect." If a chart in your submission is weak, say so before they do.

"Walk me through this query."

Explain the grain first — "one row per customer per cohort month" — then the joins and filters. Interviewers often pick the most complex query to test whether you wrote it yourself and understand it.

Stage 4: confidence

"How confident are you in the conclusion?"

Separate the finding from the explanation. "Confident that the March cohort repeats less — the gap is large and consistent across months. Less confident about why; the data doesn't show acquisition channel, so I can't tell if it's the discount or the audience."

"What would change your mind?"

A good answer names specific evidence. "If channel data showed March customers came through the same channels as earlier ones, the discount explanation would weaken."

Stage 5: the extension

"If you had another week, what would you do?"

Two or three concrete items, prioritised: "Get channel data to test the explanation; check whether March buyers bought only discounted items; set up a monthly cohort report so this is visible sooner."

"Here's a new fact: the March sale was also our first campaign on a new app platform. Does your answer change?"

This tests whether you can update live. Think aloud: it offers a second explanation — platform, not discount — and you would split the March cohort by platform to separate them.

Sanity checks to run before submitting

These catch the errors reviewers find most often. The table is a tiny hypothetical orders extract:

CREATE TABLE orders (order_id TEXT, customer_id TEXT, order_date TEXT, amount INTEGER);
INSERT INTO orders VALUES
 ('O1','C1','2026-03-02',800),('O2','C2','2026-03-05',1200),
 ('O2','C2','2026-03-05',1200),                          -- duplicated row
 ('O3','C1','2026-04-10',-800),                          -- refund stored as negative
 ('O4','C3','2026-04-12',650),('O5','TEST','2026-04-15',1),
 ('O6','C4',NULL,900);

-- 1. Duplicated keys
SELECT order_id, COUNT(*) AS copies FROM orders GROUP BY order_id HAVING COUNT(*) > 1;

-- 2. Rows that should not count as sales
SELECT
  SUM(amount < 0)               AS negative_rows,
  SUM(customer_id = 'TEST')     AS test_rows,
  SUM(order_date IS NULL)       AS undated_rows
FROM orders;

-- 3. Monthly totals before and after cleaning, to report the difference
WITH clean AS (
  SELECT DISTINCT order_id, customer_id, order_date, amount FROM orders
  WHERE amount > 0 AND customer_id <> 'TEST' AND order_date IS NOT NULL
)
SELECT substr(o.order_date, 1, 7) AS month,
       (SELECT SUM(amount) FROM orders r WHERE substr(r.order_date,1,7) = substr(o.order_date,1,7)) AS raw_total,
       (SELECT SUM(amount) FROM clean c WHERE substr(c.order_date,1,7) = substr(o.order_date,1,7)) AS clean_total
FROM orders o
WHERE o.order_date IS NOT NULL
GROUP BY month;

The first query finds O2 twice. The second finds one refund, one test row and one undated order. The third shows March at 3,200 raw against 2,000 clean, and April at −149 raw against 650 clean — a difference you should state in your write-up, along with how you treated the refund (excluded here as not a sale; reasonable only if the brief is about gross orders).

Common review-call mistakes

• Defending a mistake the reviewer has found instead of acknowledging it and saying how it changes the result.
• Reading slides aloud rather than answering the question asked.
• Claiming causation from a correlation in the data.
• Not knowing how many rows were dropped in cleaning.

For turning findings into a structured case answer, see the sales-dip root-cause case; for SQL behind the checks, see SQL join and NULL questions. Take-home style case projects with review sessions run through the Data Analyst programme.