All You Need to Know About the Meta DS Technical Skills Interview

If there is one round in the Meta Data Scientist loop that rewards people who actually enjoy working with data, this is it.

You get a product scenario, a schema, and a live coding environment, and the job is simply to do the work: figure out what the question is actually asking, write something that answers it cleanly, and explain your thinking the whole way through. It is not a trick, and it is not trying to catch you out. It is closer to the kind of problem you would bring to a team meeting, and the best performances in this round tend to feel exactly like that.

It is worth saving the Meta Data Scientist Interview Guide as a reference, since it walks through the full interview journey, explains the real intent behind each stage, and highlights how expectations evolve as Meta Data Scientists are evaluated at different seniority levels.

The Technical Skills Interview comes up as part of the trio of interviews you'll encounter during the onsite loop (the other two are Analytical Reasoning and Analytical Execution interviews).

• Interviewing at Meta: The Keys to Success
• Meta engineering blog
• How Meta understands data at scale
• Meta research blog
• How Meta enforces purpose limitation at scale in batch processing systems
• Meta Research: Causal Inference and Experiments
• Initial Screening Deep Dive
• Product Analytics Deep Dive
• Analytical Execution Round Deep Dive
• Analytical Reasoning Round Deep Dive
• Meta Data Scientist Product Analytics Interview questions with community answers
• Meta Data Scientist Mock Interview Coaches

The interviewer gives you a product scenario grounded in a real Meta surface like Reels, Marketplace, Messenger, or Ads, and asks you to translate it into SQL while talking through your reasoning live.

The problem arrives without much warmup, and the schema is often intentionally underspecified. You will not always be told what every column means, whether a table is at the user level or the event level, or how nulls are handled, and clarifying those things before you start writing is part of what gets evaluated.

Once you begin, the interviewer is listening for how your logic develops in real time. You will be asked to explain why you chose a particular join structure, how you are handling edge cases, and what assumptions you are building on as you go.

Window functions, CTEs, time-based aggregations, and cohorting all come up regularly, and the expectation is that you can walk through each piece of the query clearly while writing it.

At some point, a complication arrives. A second table gets introduced, the scope of the question shifts, or a constraint surfaces that changes how the data needs to be read. You are expected to absorb it and continue, adjusting what needs adjusting without losing the thread of what you had already built.

The SQL question and the product case that follows are often part of the same continuous problem, so metric definitions you commit to in the query carry forward into the discussion.

Interviewers track whether both parts of your answer are consistent with each other, and a definition that shifts between the two tends to get noticed.

Questions about query efficiency come up here in ways that go beyond syntax.

Meta runs on Presto at a scale where modeling choices have infrastructure consequences, and you may be asked why you used a subquery over a CTE, or whether a particular join would hold up on a table with billions of rows.

Understanding what the query costs in production is considered part of the work.

• Write a single SQL query to compute daily active users, a 7 day rolling average, and a week over week percent change, while handling users with missing activity days and explaining how you would validate correctness at scale.
• Given raw event level data, write SQL to identify each user’s second and third sessions using window functions, then calculate the distribution of time gaps between those sessions and explain what product insight you would draw from it.
• Using SQL only, build a full cohort retention table by signup week, accounting for late arriving data, users who churn and return, and partial weeks.
• Design a metric for a two sided marketplace that balances supply and demand, explain the tradeoffs in your definition, and show how you would compute it from raw tables.
• Design an A B test for a new engagement feature, including hypothesis, success metric, guardrail metrics, sample size calculation, power assumptions, and failure modes.
• You are running dozens of experiments at once across multiple metrics, explain how you would control for multiple comparisons and how that choice affects decision making.
• Given a confusion matrix from a fraud or integrity model, compute precision, recall, F1, and AUC, then explain which metric you would optimize for and why.
• Use Bayes’ theorem to calculate the probability that a user is truly malicious given multiple independent signals, and explain how base rates affect your interpretation.
• Two experiment variants show overlapping confidence intervals but different point estimates, explain what conclusions you can and cannot draw and how you would proceed.
• When a randomized experiment is not possible, explain how you would estimate causal impact using difference in difference, including assumptions you must check.
• A core product metric drops suddenly, walk through a complete root cause analysis including hypotheses, slices, SQL queries, and how you would rule out data issues.
• Given a very slow SQL query over hundreds of millions of rows, explain how you would debug performance and optimize it without changing the result.
• Describe how you would decide whether an observed metric change is real signal or noise, including when you would use bootstrapping or simulation.
• Before writing any code, list the clarifying questions you would ask about data definitions, logging, missing values, and business context, and explain why each matters.
• You discover an analysis result that contradicts strong product intuition, explain how you would communicate this to stakeholders and guide next steps without losing trust.

At Meta, what separates strong Data Scientists is an ease with operating inside systems that change as soon as you touch them.

The work assumes that users adapt, creators respond, advertisers rebalance, and internal teams react the moment a metric is optimized or exposed, so analysis is expected to account for those reactions as part of the job rather than as follow-up concerns.

A big part of the role is being able to reason about products as systems under constant optimization. Metric movement is rarely treated as an endpoint.

There is also an expectation that you are comfortable making decisions with incomplete visibility. Privacy constraints, staggered launches, delayed logging, and imperfect instrumentation are normal operating conditions, not edge cases.

Strong Data Scientists can clearly distinguish between what the data supports reliably, what it points toward directionally, and what remains unresolved, and they shape recommendations around that reality instead of waiting for perfect measurement.

Moving forward responsibly without overstating certainty is part of the job.

1. Query construction and problem framing

Interviewers are watching how you handle the space between receiving the prompt and writing the first line. Candidates who restate the problem, surface assumptions, and outline an approach before touching the keyboard read as more senior than candidates who produce a correct query through trial and error. The distinction matters because the round is testing analytical judgment, not typing speed. What gets scored is whether your solution feels like it came from a structured thinker or from someone who got lucky with syntax.

2. Reasoning transparency throughout

The live format exists specifically to observe process. Interviewers track whether your logic is visible as you work, whether you name things clearly, and whether your decisions have audible rationale behind them. A query that works but arrives silently is scored lower than one that arrives with a clear account of why it was built that way. The expectation is that you narrate your reasoning the same way you would in an actual product review, where the work has to be legible to someone who wasn't in the room when it was done.

3. Edge case recognition and mid-problem adaptability

At some point in the problem, the interviewer will introduce a constraint, a wrinkle in the data, or a change in scope. What gets evaluated is whether your reasoning bends cleanly or requires a full restart. Candidates who absorb the new information and adjust in place, softening a conclusion, narrowing a definition, rewriting a single clause, score better than candidates whose logic only holds under the original assumptions. Fragile reasoning tends to surface here even when the initial query was strong.

4. SQL mechanics and execution under pressure

Window functions, CTEs, complex joins, and aggregations are all in scope. The expectation is not fluency for its own sake but the ability to write clean, efficient, and correct queries against a product dataset while explaining tradeoffs in data modeling choices. Interviewers also note how you handle errors and null values, since those situations reveal whether you understand what the data is actually doing or whether you're pattern-matching to a query structure you memorized.

When you run out of time

Candidates sometimes hit the time limit before a complete solution is written. Interviewers are prepared for this and will ask you to walk through the query logic verbally.

A clear, structured verbal account of how you would have completed it can still produce a positive signal. What it cannot recover, however, is a situation where the approach itself was underspecified from the start.

How Meta-level behavior shows up in the technical skills round

The coding environment is a communication surface, and the best candidates treat it that way from the first line. Naming choices, intermediate steps, assumptions left visible in a comment, all of it is doing work, and the query reads as if someone else will pick it up and maintain it later, because at Meta, someone will.

Framing comes before writing, and not in a performative way. It comes first because an executable solution to the wrong problem is a liability, and the restatement at the top of the problem is how you show that you understand the difference between the question that was asked and the question that is actually worth answering.

When a constraint arrives mid-problem, the move is to treat it as information the real dataset would have surfaced anyway.
The adjustment that follows should feel local and deliberate. A clause changes, a window narrows, a definition tightens, without the rest of the query needing to come apart. That is what reasoning resilience looks like at the execution level, and interviewers read it the same way they would read it in a product review.

Edge cases get named before the interviewer names them. At Meta's scale, null values, unexpected population boundaries, and logging gaps are not exceptions to plan around after the fact. They are expected conditions, and candidates who build for them without being prompted signal that they have worked with real production data, not just practice sets.

The SQL itself should reflect product awareness without being asked for it. Time windows chosen with user behavior in mind rather than just data availability, cohort definitions that account for how a population actually shifts under the product conditions being analyzed, modeling choices that come with an audible rationale. These things separate candidates who understand what the data is measuring from candidates who are producing output. Efficiency at Meta's scale is part of that conversation too, not a footnote.

Leaving a decision partially open when the data does not support closing it is one of the stronger signals in this round. A query that honestly surfaces an ambiguity reads as more senior than one that lands on a clean answer by quietly resolving an assumption the interviewer never knew was being made.

And when time runs out before the solution is complete, the verbal account that follows still has to be specific. What would the remaining logic have done, where do the known risks sit, what would need to be validated before this could be used in a real context. That is a different thing from summarizing an intention, and interviewers can tell the difference immediately.

The code working and the analysis being right are two separate questions, and the candidates who do well in this round are the ones who hold both at the same time.

• The SQL question almost always comes attached to a product context, and the product context is not decoration. Candidates who treat it as such end up writing technically correct queries that answer the wrong question. Read the scenario before you read the schema.
• The SQL and product sense portions are connected — the case question that follows is often built directly on what you just queried. If you defined your metric loosely in the SQL, that imprecision follows you into the product discussion, and the interviewer notices the inconsistency even if you don't.
• The exact SQL flavor you use does not matter. What matters is how accurately and quickly you can translate a business question into a query that gets the answer. Candidates who spend time signaling dialect knowledge are spending time they do not have.
• Find a solution that works first, then iterate to refine it. A working query you can improve is a better position than a perfect query you never finish.
• Window functions show up consistently enough that being slow with them is a real liability. Not because the interviewer is testing syntax, but because hesitation on the mechanics makes your reasoning harder to follow in real time, and this is a round where your reasoning needs to be audible the whole way through.
• The ambiguity in the prompt is usually intentional. Candidates who surface it early and clarify before writing look like people who have worked with real production data, where the question is always at least partially underspecified.
• When time runs out before the solution is complete, what follows still has to be specific. What would the remaining logic have done, where do the known risks sit in what you have already written, what would need to be validated before this goes anywhere near a dashboard. That is a different thing from summarizing an intention, and interviewers can tell immediately.