Prompt
An interviewer says the role needs "basic SQL." What should you be ready to do, and how would you prove it with a short practice set?
Answer shape
- State the business question before the syntax.
- Name the row grain: one row per customer, order, event, account, ticket, or day.
- Use joins, grouping, `CASE`, null handling, date filters, and CTEs in realistic combinations.
- End with a sanity check so the interviewer trusts the metric.
Run the 30-minute version.
- Minutes 0-5: write down the tables you expect: `users`, `orders`, `refunds`, `events`, or `tickets`.
- Minutes 6-15: solve monthly active buyers, repeat purchase rate, average order value, top customers excluding refunds, and orders by signup cohort.
- Minutes 16-22: explain each output grain and how nulls, duplicates, many-to-many joins, or refunded orders could break the result.
- Minutes 23-30: say the answer out loud. If you cannot explain the grain in one sentence, rewrite the query.
What to be ready for
- `SELECT`, `WHERE`, `ORDER BY`, and `LIMIT`.
- Inner joins and left joins, including what drops from the result.
- `GROUP BY`, `HAVING`, and aggregate functions.
- `CASE` for buckets, flags, and business logic.
- Null handling with `COALESCE` or explicit filters.
- Subqueries or CTEs to keep a query readable.
- Date filters and date grouping.
- Window functions if the role touches analytics depth.
Common miss
Candidates often memorize syntax but skip the metric grain. A query can run and still answer the wrong question. In a data analyst interview, saying "one row per customer per month" before you aggregate is a senior signal, even in a basic screen.
Healthcare-claims variation
If the interview mentions healthcare or insurance data, practice with a tiny fake claims table: `claim_id`, `patient_id`, `provider_id`, `service_date`, `diagnosis_code`, `procedure_code`, `claim_status`, `billed_amount`, and `paid_amount`.
- claims per month by status
- rejection rate by provider
- average paid amount by procedure code
- duplicate claims for the same patient, date, and provider
- days between service date and paid date
- top diagnosis codes by paid amount
Practice truthful explanations. Do not claim production healthcare data experience if you only practiced on a small sample.
Move from basic SQL to interview judgment.
The Product Analytics packet adds timed case prompts, worked answers, SQL follow-ups, metric debugging, and recommendation practice for data analyst and product analytics loops.
Direct purchase note
This is the public $59 self-guided packet path. If a coaching or mock-interview session already gave you access, use that access instead of buying the same packet again.
Public checkout is for self-guided packet buyers.
If a coaching, mock-interview, or private session already gave you packet access, use that private access and do not buy the same packet again. The public $59 checkout is for candidates buying the self-guided Product Analytics or Leadership packet directly.
Use Product Analytics for SQL, metrics, experiments, and product cases. Use Leadership for conflict, failure, ambiguity, influence, and final-round stories.
Run one timed rep before checkout.
Pick the risk you can fix today. Do the rep, then buy the packet only if it matches the round in front of you.
- SQL or OA: say the row grain first, solve one baseline query, then name the edge case that could break it.
- Product case: start with the decision, then give the metric view, segment, risk, and recommendation.
- Leadership loop: choose one conflict, failure, or ambiguity story and name the operating change you owned.
Last-mile check: pick the packet for the round you could lose.
Use the rep on this page first. If the weak spot is SQL, metrics, experiments, or product cases, get Product Analytics. If the weak spot is conflict, ambiguity, or final-round stories, get Leadership. Public checkout is $59 and separate from any private session access.