The data interview is not won by the fanciest model. It is won by clear thinking with data: SQL that matches the question, the metric that actually matters, and an answer that ends in what to do next. We coach you to that standard, one round at a time.
SELECT COUNT(DISTINCT a.user_id)
/ COUNT(DISTINCT s.user_id) AS week1
FROM signups s
LEFT JOIN activity a ON a.user_id = s.user_id;// week1 = 0.41
Week-one retention is 41 percent, driven by the LEFT JOIN keeping churned users instead of dropping them. The recommendation: fix onboarding, not the dashboard.
Grinding LeetCode for a data role is studying the wrong thing. The query you write either matches the question or it does not, and the gap is almost always one decision: the join, or what you did with NULL. Flip them below and watch the answer change.
The engine runs your query in this order, not the order you typed it:
Hover or tab across the stages to see where each one lands in the live query below.
SELECT COUNT(DISTINCT a.user_id) / COUNT(DISTINCT s.user_id) AS week1FROM signups sLEFT JOIN activity a ON a.user_id = s.user_id;The question
Of the users who signed up, what fraction came back in week one?
Your one decision
week1 = 0.41
Honest. The LEFT JOIN keeps churned users in the denominator, counted as not retained.
Average revenue per customer, including the ones who never ordered. In a LEFT JOIN, a NULL on the right means no matching row, not the number zero. Flip the aggregate and watch Cara.
| Customer | Revenue |
|---|---|
| Ana | $120 |
| Ben | $45 |
| Cara (no orders) | $0 |
| AVG(revenue) | $55.00 |
Right. No orders becomes an honest zero, and the average tells the truth.
"Top K per group" and "latest per user" come up constantly. The pattern is always the same: number the rows inside each partition, then keep row one.
SELECT *
FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY event_time DESC
) AS rn
FROM events
) t
WHERE rn = 1;The sibling trap is row multiplication: one customer with ten orders becomes ten rows after a join. Decide what one row should represent (the grain) before you join.
Once you see the four, the question bank stops looking random. Open each pillar, then mark the ones you can already do cold. The meter tells you, honestly, where to start.
Where do you stand? Mark each pillar you can do cold.
0 of 4 cold
Where candidates lose it
Join and NULL bugs, the wrong grain, and reaching for a subquery where a window function is cleaner.
The move that fixes it
Drill the grain, join types, what NULL means, and window functions until they are reflex, not recall.
Where candidates lose it
Calling a p-value the probability the null is true, or treating statistical significance as business impact.
The move that fixes it
Practice explaining each idea to a smart non-statistician. Plain language beats a recited definition every round.
Where candidates lose it
A vague phrase instead of a definition: active users, with no active means what, over what window.
The move that fixes it
Pin the grain, the window, and the denominator out loud before you compute anything.
Where candidates lose it
Describing the data without interpreting it, and stopping at a number with no recommendation.
The move that fixes it
State the equation, hypothesize a driver, validate against a baseline, and end in a decision someone can act on.
The thread through all four: clarify the goal before you touch SQL or a model, and end every answer with a decision a non-technical person can act on. Description is not analysis.
The bar the self-check above points at. This is the same rubric we grade your mock interviews against, so you always know what you are reaching for. The aim is every row, every round.
SQL fluency
Fluent and correct, right grain, clean window functions, no NULL surprises.
Metric definition
Precise without being asked: the grain, the window, and the denominator.
Case structure
States the equation, hypothesizes a driver, validates against a baseline.
Evaluation judgment
Metric tied to business cost, and data leakage caught before it bites.
Decision orientation
A clear recommended action, with confidence and the risks named.
Communication
Leads with the decision, one clear chart, plain language for non-technical partners.
The move most candidates fumble: they answer a fuzzy word with another fuzzy phrase. The strong answer pins down three things, the grain, the window, and the denominator. Build one yourself and feel a vague phrase become computable.
Pick the fuzzy word
What counts as active
The window
The base
The trap
“Active users,” with no definition of active, over no stated window.
Your definition
Active = a distinct user with at least one key action, counted per day, over eligible users only.
SELECT event_date, COUNT(DISTINCT user_id) AS active
FROM events
WHERE event = 'key_action'
GROUP BY 1; -- base: eligible_usersNow it is computable: the grain, the window, and the denominator are pinned.
Description is not analysis. A single number lands on your desk and the interview is everything you do next. Run the most common case of all, live: a metric moved, why?
Before anything: what decision does this support? Which segment, region, and timeframe, and is this even a real change or a tracking gap?
Decompose the metric into drivers. If you cannot write the equation, do not proceed. Structure before computation.
Bet on a single leading driver and predict its fingerprint. If X is true, I expect to see Y. This is the habit that separates analysis from fishing.
Pull the data and compare: before versus after, segment versus segment, treated versus control. Magnitude plus comparison equals insight.
State what happened, why, and what to do, with your confidence and assumptions. A number with no recommendation is an incomplete answer.
The number on your desk
DAU is down 8 percent this week.
1. Clarify the goal
Which platform and region? Is the 8 percent versus last week, or the same week last year to control for seasonality?
2. State the equation
DAU = new users + returning users. A drop lives in one or both, so I will look at each.
3. Hypothesize
If a recent release broke one platform, I expect the drop concentrated on that platform and starting on the release date.
4. Validate against a baseline
Segment DAU by platform, region, and new-versus-returning, overlay the release date. A clean discontinuity on one platform reads as a bug, not real disengagement.
5. Translate into a decision
The drop is entirely on iOS and starts on the 4.2 release, so it is most likely a tracking bug. Recommend verifying iOS event logging before any growth response.
The tell you nailed it: you predicted what each cause would look like before pulling the data. In coaching we run dozens of these live, narrated out loud, until the structure is reflexive under pressure.
You work one-on-one with mentors who went through real data recruiting cycles, not a course that talks at you. They know which fundamentals actually get tested and the pitfalls that filter strong students out early.
TODO: mentor who landed a data science internship at a top tech company
Real bio pending
TODO: mentor who landed an analytics role at a major bank or fintech
Real bio pending
TODO: mentor who shipped end-to-end DS projects in a high-growth startup
Real bio pending
TODO: real student testimonial about the data science coaching, attributed to a named student and the role they landed.
TODO: real student testimonial about the data science coaching, attributed to a named student and the role they landed.
Most rejections in this track are not a knowledge gap. They are a habit the interviewer reads in minutes. We name the failure mode, then drill the replacement until it holds under pressure.
Describes the data, does not interpret it
Always add the why, and the recommended action.
Stops at a number, no recommendation
End every answer with what to do next.
Weak SQL fundamentals, join and NULL bugs
Drill the grain, join types, NULL meaning, and window functions.
Reaches for accuracy on imbalanced data
Ask which mistake costs more: precision, recall, and PR-AUC.
Misses data leakage until it bites
Audit features for future information, and split by time.
Hands stakeholders naked statistics (the p-value was 0.03)
Translate to plain business language, decision first.
Start with a free consultation. We will look at your background and target roles, then map the one or two moves that change your odds most. No commitment, no script.
Or see exactly what each session costs on the pricing page.