The Data Analyst Answer That Instantly Builds My Confidence

Interview Insights · Data Analyst

The Data Analyst Answer That Instantly Builds My Confidence

SECTION 01Why asking about the grain sounds senior

The grain of a table is what one row represents. One row per order, per order item, per customer per day, per page view. It sounds basic, yet it is the root of many wrong reports. If an orders table has one row per item and you sum the order-level delivery fee, you overcount it once for every extra item.

When I give a candidate a schema and they ask, 'Is this one row per order or per item?', I know they have been burned by this before, or have learned from someone who was. That single question tells me more about their real experience than a perfectly memorised definition of a LEFT JOIN.

Interviewer: Total delivery fee collected last month?

Candidate:
SELECT SUM(delivery_fee)
FROM order_items
WHERE order_date >= '2026-10-01'
  AND order_date <  '2026-11-01';

-- Looks fine, but if delivery_fee repeats on every
-- item row of an order, this total is inflated.

Candidate: Quick check first: is order_items one row per
item? If yes, delivery_fee probably repeats per item.

SELECT SUM(delivery_fee) AS total_fee
FROM (
  SELECT order_id, MAX(delivery_fee) AS delivery_fee
  FROM order_items
  WHERE order_date >= '2026-10-01'
    AND order_date <  '2026-11-01'
  GROUP BY order_id
) per_order;

-- Collapse to one row per order, then sum.
-- Better still: use the orders table if it has the fee.

Notice the date filter uses 'greater than or equal to the first day' and 'less than the first day of the next month'. That avoids missing rows with a time part on the last day, another detail that quietly signals care.

SECTION 02Five quick checks I want to hear before any result

The second half of the confidence-building answer is validation. You do not need a long data quality framework. Five fast checks catch most problems: row counts, duplicates on the key, NULLs in important columns, value ranges, and a reconciliation with a known total.

In an interview, you do not have to run them all. Naming them, and showing you know what each one protects against, is enough. In a take-home assignment, include them in your notebook so the reviewer can see them.

import pandas as pd

orders = pd.read_csv('orders.csv', parse_dates=['order_date'])
customers = pd.read_csv('customers.csv')

print('rows:', len(orders))
print('duplicate order_id:', orders.duplicated('order_id').sum())
print(orders[['amount', 'customer_id']].isna().sum())
print(orders['amount'].describe())
print('date range:', orders['order_date'].min(), orders['order_date'].max())

merged = orders.merge(customers, on='customer_id', how='left',
                      validate='many_to_one')
assert len(merged) == len(orders), 'join changed row count'

print('total amount:', round(merged['amount'].sum(), 2))

-- Compare my report total with the finance ledger
SELECT 'report' AS source, SUM(amount) AS total
FROM orders
WHERE status = 'delivered'
  AND order_date >= '2026-10-01' AND order_date < '2026-11-01'
UNION ALL
SELECT 'ledger', SUM(credit_amount)
FROM finance_ledger
WHERE entry_type = 'sale'
  AND entry_date >= '2026-10-01' AND entry_date < '2026-11-01';

-- If they differ, list the gap by day to find
-- where the definitions or timings disagree.

The validate='many_to_one' argument in pandas is a small feature that few freshers know. It raises an error if the customers table has duplicate customer IDs, which would otherwise silently multiply your order rows. Mentioning it in an interview is a strong signal.

SECTION 03How to phrase the answer in different rounds

The same habit sounds different depending on the round. In a SQL round it is a clarifying question. In a case round it is a statement about data reliability. In a project discussion it is a story about a check that saved you.

The mistake is to wait until the end and say 'and then I would validate it'. That sounds like an afterthought. The confident version weaves validation into the beginning and the end of the answer, so the interviewer hears it as part of how you work.

Interviewer: Signups jumped last week. What happened?

Candidate: Before I look for a business reason, I would
rule out a data reason. Three quick checks:
1. Did tracking change? A new form or a duplicate event
   firing would inflate signups.
2. Are the new signups real? Check for many accounts from
   the same email domain or device.
3. Do signups in the product database match the analytics
   tool for that week?

If all three are clean, I would then split the jump by
channel and campaign to find the business cause.

"In my sales dashboard project, my monthly revenue was
higher than the total in the raw file. I found that the
product lookup table had the same product ID twice after
a category rename, so the merge doubled some rows.

I fixed the lookup, added an assert that row counts stay
the same after every merge, and now I check one total
against the source before I build any chart."

SECTION 04A validation checklist for every analyst project

Paste this checklist into the first cell of every notebook or the first page of every project document. Over time it becomes automatic, and you will naturally talk about it in interviews.

BEFORE I ANALYSE

[ ] I can say what one row means in each table
[ ] I know the primary key of each table
[ ] I checked duplicates on that key
[ ] I listed NULL counts for important columns
[ ] I checked min and max for amounts and dates
[ ] I know the time zone of the date columns

AFTER EVERY JOIN OR MERGE

[ ] Row count before: ______  after: ______
[ ] If it changed, I can explain why
[ ] I used the join type I meant (inner vs left)
[ ] Unmatched keys counted and reviewed
[ ] pandas: validate= argument used where possible

BEFORE I SHARE ANY NUMBER

[ ] One headline total matches a trusted source
[ ] Differences are listed with a reason
[ ] Metric definition written in one sentence
[ ] Filters stated (dates, status, region)
[ ] One limitation written down honestly

If any box is empty, the number is a draft.

SECTION 05Small habits that make interviewers trust your numbers

Confidence is built from small, repeated signals. These habits create them without making your answers longer.

• Say the grain out loud — Start technical answers with one sentence about what each row represents. It takes five seconds and prevents most errors.
• Name one check, not ten — Pick the single most relevant validation for the question. A focused check sounds experienced; a long list sounds memorised.
• Use real numbers in stories — When you describe a project bug, mention the actual row counts you saw in your own work, so the story sounds lived rather than rehearsed.
• Separate data and business causes — When a metric moves, first rule out tracking or pipeline changes, then look for business reasons.
• Write definitions down — Keep a one-line definition for every metric in your project README. Interviewers often ask how you defined it.

SECTION 06Interview Q&A — Data validation answer

SECTION 07Test yourself — Data validation answer quiz

SECTION 08Frequently asked questions

SECTION 09Related reads