Data Science Interview Questions for Startups: SQL, Metrics, and ML

Data science interview questions at startups can feel scattered: write SQL, explain an experiment, diagnose a metric drop, then decide whether a model is even warranted. That is the point. A small team usually needs someone who can move from a messy event table to a decision without waiting for a specialist in every lane. This guide gives you realistic prompts, strong answer patterns, and a ten-day practice plan.

What startup data science interviews are really testing

At a startup, a data scientist may work across product analytics, experimentation, basic data modeling, and the data plumbing needed to make the analysis possible. The interviewer is less interested in whether you can recite every algorithm. They want evidence that you can choose a useful question, inspect imperfect data, state your assumptions, and explain what should happen next.

Prepare two stories from your own work or coursework. One should show a decision you changed with data. The other should show what you did when the data, definition, or result was wrong. Use a compact structure: context, decision, analysis, result, and what you would do differently. If the company moves quickly, practice delivering each story in 90 seconds before offering details.

A ten-day prep plan for startup data science roles

Do not spend ten days rereading notes. Produce one small artifact each day. You will build material you can reuse in a screen, a live exercise, or a take-home.

Keep a “definition sheet” as you practice. For every metric, write the numerator, denominator, time window, population, and exclusions. This habit prevents a common interview failure: giving a polished answer to an undefined question.

SQL interview questions for data scientists, with answer patterns

Ask clarifying questions before typing: What database is this? Are timestamps UTC? Can a user generate duplicate events? Does “active” mean any event or one named event? These examples use PostgreSQL syntax. Its window-function documentation explains that window functions calculate across rows related to the current row without collapsing them into one row, which makes them useful for cohorts and rankings.

Question 1: What is day-seven retention by acquisition date?

Assume events(user_id, event_name, occurred_at) and treat a user’s first session_started date as the acquisition date. Say that you are counting each user once, then write this:

WITH first_active AS (
  SELECT user_id, MIN(occurred_at::date) AS cohort_date
  FROM events
  WHERE event_name = 'session_started'
  GROUP BY 1
),
cohort_size AS (
  SELECT cohort_date, COUNT(*) AS new_users
  FROM first_active
  GROUP BY 1
),
returned AS (
  SELECT f.cohort_date, COUNT(DISTINCT f.user_id) AS returned_users
  FROM first_active f
  JOIN events e
    ON e.user_id = f.user_id
   AND e.event_name = 'session_started'
   AND e.occurred_at::date = f.cohort_date + 7
  GROUP BY 1
)
SELECT c.cohort_date,
       c.new_users,
       COALESCE(r.returned_users, 0) AS returned_users,
       ROUND(100.0 * COALESCE(r.returned_users, 0) / c.new_users, 1)
         AS day_7_retention_pct
FROM cohort_size c
LEFT JOIN returned r USING (cohort_date)
ORDER BY 1;

Then explain the limits. This measures return exactly seven calendar days later, not return at any point during the following week. You would exclude incomplete cohorts, confirm the business definition of activation, and check whether bots or internal accounts belong in the denominator.

Question 2: Where does a signup funnel break?

Assume events(user_id, session_id, event_name, occurred_at). The question is: among sessions with a signup, what share create a project and invite a collaborator in that same session?

WITH session_steps AS (
  SELECT user_id,
         session_id,
         MAX(CASE WHEN event_name = 'signed_up' THEN 1 ELSE 0 END) AS signup,
         MAX(CASE WHEN event_name = 'created_project' THEN 1 ELSE 0 END)
           AS project,
         MAX(CASE WHEN event_name = 'invited_collaborator' THEN 1 ELSE 0 END)
           AS invite
  FROM events
  WHERE event_name IN ('signed_up', 'created_project', 'invited_collaborator')
  GROUP BY 1, 2
)
SELECT SUM(signup) AS signup_sessions,
       SUM(CASE WHEN signup = 1 AND project = 1 THEN 1 ELSE 0 END)
         AS project_sessions,
       SUM(CASE WHEN signup = 1 AND project = 1 AND invite = 1
                THEN 1 ELSE 0 END) AS invite_sessions,
       ROUND(100.0 * SUM(CASE WHEN signup = 1 AND project = 1 THEN 1 ELSE 0 END)
             / NULLIF(SUM(signup), 0), 1) AS signup_to_project_pct,
       ROUND(100.0 * SUM(CASE WHEN signup = 1 AND project = 1 AND invite = 1
                               THEN 1 ELSE 0 END)
             / NULLIF(SUM(signup), 0), 1) AS signup_to_invite_pct
FROM session_steps;

A careful candidate flags one missing check: this query proves that steps occurred in the same session, not that they occurred in the intended order. If order matters, add timestamps for each step and require signup_at <= project_at <= invite_at. That sentence often distinguishes someone who can write SQL from someone who can trust a result.

Question 3: Which accounts should a customer-success team call first?

Assume account_daily_usage(account_id, plan, usage_date, active_seats). First aggregate the last 28 days at the account grain. Then rank within a plan, so the team does not compare enterprise accounts with small-team accounts.

WITH account_usage AS (
  SELECT account_id,
         plan,
         SUM(active_seats) AS active_seats_28d
  FROM account_daily_usage
  WHERE usage_date >= CURRENT_DATE - INTERVAL '28 days'
  GROUP BY 1, 2
),
ranked AS (
  SELECT account_id,
         plan,
         active_seats_28d,
         ROW_NUMBER() OVER (
           PARTITION BY plan
           ORDER BY active_seats_28d DESC, account_id
         ) AS usage_rank
  FROM account_usage
)
SELECT account_id, plan, active_seats_28d, usage_rank
FROM ranked
WHERE usage_rank <= 10
ORDER BY plan, usage_rank;

State the business caveat. High usage might identify healthy accounts, not accounts at risk. Ask whether the team needs accounts with falling usage instead. Then change the query to compare the most recent 14 days with the prior 14 days. That follow-up shows you do not mistake a query for a decision.

Statistics and A/B testing questions: concise answers that hold up

A startup interviewer may give you little traffic and an impatient product manager. Your job is to make uncertainty visible without becoming vague. A controlled experiment with randomization and proper design is a way to assess a feature’s causal impact on customer behavior, rather than comparing two unrelated time periods, as Microsoft Research explains.

“What does a p-value tell you?” Say: “It describes how incompatible the observed data are with a specified statistical model. It is not the probability that the null hypothesis is true, and it does not tell us effect size or business value.” That matches the American Statistical Association’s guidance. Add that you would report the estimated lift and an interval, then make the decision against the cost of being wrong.

“How would you set sample size?” Say: “I need the baseline rate, the smallest change worth acting on, the significance level, desired power, and the unit of randomization. Then I would calculate the sample and convert it into runtime using eligible traffic.” NIST’s proportion-test guidance similarly starts with the change to detect, significance, and power when deriving a required sample size (NIST).

“The result is not significant. Do we ship?” Say: “Not yet. I would look at the estimated effect and interval, confirm the test had a useful chance to detect the minimum effect, and check guardrails. A wide interval means we learned little, not that the variants are equivalent.”

“What is a novelty effect?” Say: “A new interface can get temporary extra attention, or a changed workflow can slow experienced users at first. I would inspect treatment-control differences over time, segment new versus returning users, and avoid declaring victory from the first few days.” Kohavi and coauthors describe both novelty and primacy effects, as well as the risk of over-reading early experiment trends (paper).

Product data science case: diagnose an activation drop

Example: hypothetical. A collaboration startup sees weekly activation fall from 520 of 1,000 new workspaces to 420 of 1,000 after a new onboarding flow ships. Define activation as “a new workspace creates a project and invites one teammate within 24 hours.” The interviewer asks what you would do.

Start with the decision: should the team pause, roll back, or keep shipping? Say you would not jump from the 10-point drop to a rollback. First, validate the metric and its instrumentation.

1. Confirm the comparison. Check the calendar dates, traffic source mix, geography, platform, and the exact release exposure. Verify that the new code still emits created_project and invited_teammate events.
2. Check the metric tree. Break activation into signup → project creation → teammate invitation. Calculate counts and conversion at every step. A loss only at invitation points to a different problem than a loss immediately after signup.
3. Segment before storytelling. Compare web, iOS, Android, new and returning users, app version, and acquisition channel. Look for a concentrated drop before claiming a broad product failure.
4. Separate measurement from behavior. If one app version shows the drop and its event volume abruptly falls, inspect logging first. If event logs are healthy and project creation drops, review the new screen, errors, and session recordings with the product team.
5. Choose a safe next move. If the evidence shows a large, concentrated harm and a rollback is reversible, pause exposure. If the evidence is noisy, run a clean holdout and set a decision window. Keep guardrails such as error rate, support contacts, and completion time beside activation.

A strong spoken answer sounds like this: “I would first verify the event contract and exposure dates. Then I would locate the first broken funnel step and slice the change by platform and version. If the decline is real and concentrated in the new flow, I would recommend pausing exposure while engineering checks that step. I would not average across platforms and call it a product result.”

Practical machine learning questions: show restraint and rigor

“When would you not use machine learning?” Start with the decision and the alternative. “If a clear rule, a better form, a queue change, or a simple threshold solves the user problem, I would test that first. I need enough reliable labels, a stable prediction target, an owner who can act on the score, and a way to measure harm before I build a model.” This makes you sound practical, not anti-ML.

“How would you evaluate a churn model?” Say: “I would define churn and the prediction horizon first. I would split by time if deployment predicts the future, choose a metric that matches the intervention capacity, and compare against a simple baseline. I would report performance by relevant segments and evaluate whether outreach changes outcomes, not only model scores.”

“What is leakage?” Say: “Leakage is information used during training that would not exist when the model makes a real prediction. A future cancellation date or a post-outcome support ticket can make offline performance look excellent and production performance fail.” The scikit-learn documentation advises splitting data before preprocessing and fitting transformations on training data only; mention that you would apply the same discipline to features and time windows.

For any ML prompt, finish with one question: “What action changes when this score changes?” If nobody can answer, the model is not yet the project.

How to approach a data science take-home without overbuilding

First ask for the time expectation, evaluation criteria, allowed tools, and whether the company wants production-quality code or an analysis sample. The broader guidance in How to Ace a Take-Home Assignment can help you scope the work. For data-specific practice, use the legacy guide on data analyst interview questions to rehearse clear SQL explanations.

Deliver a small, reviewable package:

• A README with the business question, dataset grain, assumptions, and how to run the work.
• One notebook or script with a short setup section, checks for missingness and duplicates, and readable output.
• A two-page memo or five-slide summary: recommendation, evidence, limitations, and next experiment.
• A short “what I would do with another week” section. This gives reviewers an honest view of your priorities.

Do not bury the recommendation below exploratory charts. Lead with the decision and then show enough evidence for someone to challenge it. Before the final interview, prepare two questions about the role’s data access, metric ownership, and decision process. Add a few from these questions to ask in a startup interview if the team has not covered them.

Next steps

1. Choose one product you know and write its activation definition in one sentence.
2. Recreate the retention and funnel queries with your own table names, then explain every denominator out loud.
3. Practice the activation-drop case in five minutes. Record yourself and remove any sentence that does not end in a check, decision, or question.
4. Build one small take-home sample and update your startup resume with the business result, your method, and a link to the work if it is shareable.