Meta Senior Data Analyst Interview Preparation Guide

Direct answer. Database statistics are the summarized information (row counts, distinct-value counts, value distributions or histograms) the optimizer uses to estimate how selective a predicate is and how large an intermediate result will be; running ANALYZE (or the equivalent) refreshes that summary, and stale or missing statistics are one of the single most common root causes of a bad query plan.

Structured elaboration. Without statistics, or with statistics that no longer reflect the table's current state, the optimizer is estimating blind, which usually biases it toward whatever plan looked reasonable the last time statistics were accurate, not the plan that's actually cheapest now. Symptoms that point at stale or missing statistics: a plan that recently changed for the worse with no query or schema change on your end; a large gap between EXPLAIN's estimated row count and EXPLAIN ANALYZE's actual row count for the same predicate; and a table that has grown, shrunk, or shifted its data distribution significantly (a bulk load, a mass deletion, a new category of values appearing) since the last time statistics were collected.

Data volume growth alone doesn't require statistics to be refreshed constantly if the shape of the distribution stays similar; what actually matters is whether the DISTRIBUTION the optimizer is reasoning about has changed, not just the row count. A table that doubles in size but keeps the same proportional value distribution needs a much less urgent refresh than a table where a new, highly skewed category of values just started appearing.

Worked example. After a one-time bulk import that added a new region value representing 40% of a previously much smaller table, a query filtering on that region can go from "the optimizer correctly avoids an index because that value used to be tiny" to "the optimizer should now prefer a scan, but statistics still say it's tiny, so it wrongly reaches for an index and pays for many scattered lookups instead."

Trade-offs and pitfalls. Refreshing statistics has a real cost (it scans some or all of the table, depending on the sampling strategy) and running it too aggressively on a very large, frequently-changing table can itself become an operational concern; the practical balance is triggering it after events likely to shift a distribution (large loads, deletes, migrations) rather than purely on a fixed schedule, and scheduling routine refreshes to run during low-traffic windows where the scan cost is least disruptive.

A two-sided marketplace with network effects needs a north star that reflects value created for BOTH sides simultaneously, because optimizing for only one side (say, supply growth) can silently starve the other side and collapse the marketplace's core value proposition.

North star and supporting structure

A reasonable composite north star is successful matches per active period (for example, completed transactions where both a buyer and supplier were satisfied), rather than a one-sided metric like total listings or total buyer signups, because it only counts when the marketplace actually did its job for both parties at once.

Match quality

Measure match quality not just by whether a transaction completed, but by post-transaction signals from both sides: repeat-transaction rate (did the buyer come back, and did the supplier get repeat business from the same or similar buyers), dispute or refund rate (a proxy for mismatched expectations), and a lightweight post-transaction rating from both parties. A marketplace can show a healthy raw transaction count while match quality quietly degrades (rising disputes, falling repeat rate), which is exactly the pattern that predicts an eventual collapse in trust on one or both sides.

Guarding against gaming between the two sides

Because suppliers and buyers can each be incentivized to game a shared metric in opposite directions (suppliers padding listings to look active without real intent to fulfill; buyers browsing without intent to inflate engagement-looking metrics), pair the north star with side-specific guardrails: a minimum supplier fulfillment rate (listings that actually convert to completed transactions, not just posted) and a minimum buyer follow-through rate (browsing sessions that convert to genuine transaction attempts), so growth in the composite north star can't be manufactured by one side inflating activity that never produces a real match.

Trade-offs and pitfalls

A composite metric like 'successful matches' is harder to instrument and explain to stakeholders than a simple count (total listings, total signups), and it requires both sides' data to be reliably joined; the trade-off is worth it because a one-sided metric will eventually reward exactly the kind of imbalance (loads of supply, no real demand, or vice versa) that kills a marketplace's core value.

Direct answer
In an unexpected 60 seconds, say the bottom line first, the single most likely driver or cause second, and the one thing you need from them third. There isn't time for context or a build-up; you get one shot at the headline.

Structured elaboration
The discipline here is deciding, before you open your mouth, which one fact matters most right now, because you genuinely won't have time to cover more than that plus a brief reason and an ask. This means having a small mental inventory ready in advance for anything you're actively tracking that leadership might reasonably ask about, so you're not composing the headline for the first time in the elevator itself.
If the situation is too complex to compress honestly into three sentences, it's better to say so explicitly ("this needs more than 60 seconds to do justice, can I send you a two-line summary today and we grab 10 minutes tomorrow?") than to force an oversimplified or misleading version just to fill the time.

Worked example
Running into the CEO after a platform incident the night before: "Quick update: last night's outage is fully resolved, root cause was a config error in a recent deploy, no customer data was affected. We're adding an automated check this week to catch that class of error before it ships again." Three sentences, no jargon, and it anticipates the two questions a CEO would ask next (is it fixed, will it happen again) without waiting to be asked.

Trade-offs and pitfalls
The most common failure is trying to cram too much in, which usually means the listener walks away with a blur of facts rather than one clear takeaway. The second is using the moment to raise something that genuinely needs more context or nuance than 60 seconds allows, which can create a false impression that's worse than saying nothing until you have proper time.

A join or filter that compares a text-typed column to a numeric-typed column forces an implicit cast on one side, and depending on the engine and direction of that cast, rows can either silently fail to match or the query can become far slower than expected because the cast defeats an index.

The mechanism

If `orders.order_id` is stored as `VARCHAR` and `payments.order_id` as `INT`, a join condition `orders.order_id = payments.order_id` typically forces the engine to cast one side to match the other. If the cast direction converts the INT side to text using a different formatting convention than the VARCHAR side actually uses (leading zeros, whitespace), rows that are conceptually the "same" ID never match. Even when the cast is logically correct, a cast applied to an indexed column usually prevents the index from being used for that comparison, turning an indexed lookup into a full scan.

Worked example

An `order_id` of `'007'` (text) and `7` (integer) look like the same real order to a person, but a naive cast may not reconcile the leading zero, causing that specific pair to silently fail to join, undercounting matched orders without any error being raised.

Trade-offs and pitfalls

The durable fix is at the schema level: pick one type for a shared key across every table that uses it, and migrate the outlier rather than relying on an implicit cast at query time indefinitely. Where an immediate schema change isn't possible, make the cast EXPLICIT in the query (`CAST(orders.order_id AS INTEGER)`) so the behavior is visible and testable, and add an automated check comparing match rates before and after any type-related schema change, since a silently reduced join rate is exactly the kind of regression that won't throw an error and will only show up as an unexplained drop in downstream aggregates.

Direct answer

Once you know a partner function is measured on something different from you (speed versus quality or risk, for example), you scope your asks to be small and cheap under their metric, and you change what "status" means when you talk to them: short, action-oriented signals instead of the detailed risk narrative you'd give your own stakeholders. You're not changing what you need, you're changing how you package it so it doesn't read as a tax on the thing they're rewarded for.

Structured elaboration

1. Diagnose the incentive, don't assume it. Confirm what the partner function is actually measured on (deploy velocity, ticket close time, uptime, cost) rather than inferring it from how they push back. Different sub-teams within the "same" function can be measured differently.
2. Scope the ask to the smallest unit that gets you what you need. If they're speed-measured, don't ask for a broad, standing review of everything; ask for a narrow, well-bounded check on the specific surface that carries the risk you actually care about, and let everything else pass without friction.
3. Translate the ask into their currency. Instead of framing a request around your risk language, frame it around what it costs (or saves) them in their terms: incident response hours avoided, rework avoided, a compliance gate they'd otherwise hit later and more expensively.
4. Change the shape of status, not just the ask. For a speed-measured partner, give a compact signal (blocked/not blocked, a count, a single risk flag) they can act on in seconds. Save the fuller narrative for your own stakeholders who need the detail. Sharing the same long-form update with both audiences under-serves the partner who needs to move fast.
5. Keep a floor. Adapting your ask to their incentive has a limit: there's a minimum you can't compromise below without failing your own mandate. Know that floor before the conversation so "scoping down" doesn't quietly become "giving up the requirement."
6. Revisit as trust builds. Early asks are necessarily narrow and low-trust. As the partner sees your asks are well-scoped and your status updates are reliable, you can often widen the ask (a slightly broader review surface, more lead time) because they've learned you're not going to slow them down for nothing.

Worked example

A platform team is measured on release velocity; a security-minded partner function is measured on defect and incident rates. Rather than asking the platform team to route every change through manual security review (a direct tax on their velocity metric), the ask is scoped to only changes that touch a named risk surface, such as authentication or payment code. Everything else ships without added friction. Status to the platform team is a single weekly line: "2 changes in the review queue, 0 blocking, both cleared by Thursday." The fuller write-up, with rationale and residual risk, goes to the security function's own leadership, not to the platform team, because that's not the audience that needs it to act.

Trade-offs & pitfalls

• Pitfall: scoping the ask down so far it stops actually managing the risk it exists to manage. Know your floor before you negotiate.
• Pitfall: assuming the incentive instead of confirming it. Guessing wrong (e.g., treating a team as purely speed-driven when they're also on the hook for a compliance metric) leads to asks that miss what would actually land.
• Pitfall: sending the same status update to every audience. It either over-informs the speed-measured partner (who tunes it out) or under-informs your own stakeholders (who need the detail to make decisions).
• Senior differentiator: treating the ask size and the status format as things you design deliberately around the incentive gap, and revisiting that design as trust changes, rather than a fixed communication style you use with everyone.

Direct answer

Managing this well means never accepting or rejecting a scope-change ask in the room where it is raised. Do a quick, honest impact analysis first, negotiate from that analysis rather than from pressure to please the stakeholder in the moment, document whatever is decided, and communicate in a way that shows the original timeline is being protected, not abandoned.

Structured elaboration

1. Acknowledge the request without committing in the room: a mid-review ask for significant new requirements deserves a real look, not an on-the-spot yes or no, so the first move is agreeing to assess impact and come back with options.
2. Run a quick impact analysis: estimate the added effort the new requirement genuinely requires, and identify what it would displace, the delivery date, an already-committed piece of scope, or another stakeholder's promised deliverable, since scope changes rarely come free even when nobody says so out loud.
3. Negotiation tactics: bring the impact analysis as the basis for a small set of concrete options, add the requirement and move the date by the estimated amount, add it now and cut an already-planned, lower-priority piece of scope to make room, or defer it to a follow-up phase and hit the original date, letting the requesting stakeholder choose among real trade-offs instead of being told no.
4. Document the decision: a short, written record of what was requested, the impact analysis, the options presented, and which option was chosen and by whom, so a later resurfacing of the same request has a clear record rather than a memory of a hallway conversation.
5. Communicate to protect trust and the timeline: tell the broader project stakeholders what changed and why, framed around the trade-off that was chosen, so the timeline change reads as a deliberate, documented decision rather than a slip that happened to the project.

Worked example

Mid-way through building a quarterly sales-performance dashboard, a stakeholder from finance asks, in the review meeting, to add a new requirement: breaking every metric down by a newly created regional structure that did not exist when the project was scoped. Acknowledging without committing: the response in the room is that this is a real ask worth evaluating properly, with a follow-up by the next business day.

Impact analysis: the new regional breakdown touches every existing metric and requires a new mapping table that does not yet exist, estimated at 2 additional weeks of work against a project with 3 weeks left before its committed delivery date. Negotiation: three options were brought back. Add the regional breakdown and move the delivery date by 2 weeks. Add it now by dropping a lower-priority piece of already-planned scope, a year-over-year comparison view, to make room within the 3 remaining weeks. Or defer the regional breakdown to a fast-follow release 2 weeks after the original date ships as planned. Documentation: a one-paragraph decision record captured the request, the 2-week estimate, the three options, and the choice once made. The finance stakeholder chose the fast-follow option, so the broader project stakeholders were told the original date and scope were unchanged, with the regional breakdown explicitly scheduled 2 weeks later, framed as a deliberate addition rather than a delay.

Trade-offs and pitfalls

Saying yes to a scope addition in the room to avoid an uncomfortable moment quietly guarantees a schedule miss nobody actually agreed to. Presenting the impact analysis without real options reads as a rejection dressed up as data rather than a genuine negotiation. Skipping documentation because the decision felt clear in the meeting invites the stakeholder to later remember a different version of what was agreed. Communicating the change only to the requesting stakeholder leaves other stakeholders to discover the revised scope or date on their own.

Direct answer

The underlying finding stays identical, but you change altitude, vocabulary, and level of supporting detail. An executive gets the headline, the business impact, and the recommended decision in one or two lines up front. The implementation team gets the mechanism, the caveats, and enough of the underlying data to act on it correctly.

Structured elaboration

• Altitude: conclusion-first for the executive, versus enough method detail for the team to trust and reproduce the diagnosis.
• Vocabulary: business-impact language (revenue, risk, timeline) for the executive, technical specifics (segments, funnels, thresholds) for the team.
• Format: a one-slide or one-paragraph summary versus a working document with a data appendix.
• What must never change: the number itself and the direction of the conclusion, in both versions.

Worked example

Finding: onboarding drop-off at step 3 is costing an estimated 6% of new signups per month.
Executive version: "we're losing about 6 of every 100 new signups at the step-3 confirmation screen, fixing it could recover meaningful revenue this quarter, recommend prioritizing it."
Team version: "62% of that drop-off happens on mobile between form submit and confirmation render, median time to abandon is 9 seconds, this looks like a loading-state issue on mobile specifically."
Both versions agree on the 6% headline number and the recommendation to prioritize the fix.

Trade-offs and pitfalls

The two versions can quietly drift into different conclusions if you're not careful, always trace both back to the same underlying analysis. Over-simplifying for the executive can also strip out the one caveat that would have changed their decision, so pick what to omit deliberately, not by default.

What the interviewer probes next

Expect a question about what happens when the executive summary gets forwarded on without you in the room, and how you prevent it from being read out of context.

Direct answer. When an anomaly is confined to a specific slice from the start (one country, one platform version), the investigative approach differs from open-ended segmentation: the slice is already known, so the work is determining WHICH of product, data, or an external factor specific to that slice is responsible, using the fact that the anomaly's boundary is itself informative.

Structured elaboration. The shape of the boundary is the first clue: if the affected slice maps cleanly onto something that shipped or changed specifically for that slice (an app version, a regional feature flag, a localized release), that's the leading hypothesis and should be checked first, since it directly explains why the anomaly respects that exact boundary. If no such change exists, check for a data-layer explanation specific to that slice: does that country or platform depend on a different data pipeline path, a different software development kit (SDK) version, or a region-specific server or content delivery network (CDN) that could fail independently of the rest of the system. Only after both are ruled out should an external, market-specific factor (a local regulatory change, a local competitor action, a local holiday) become the leading hypothesis, since it's usually the hardest to verify and the least common cause in practice.

Worked example. Retention decreased only for users in Country A and only on Android 12 specifically (the intersection, not either dimension alone). Checking release history shows no country- or OS-version-specific feature shipped recently. Checking the data pipeline shows Android 12 devices in that specific country route through a different push-notification provider due to a regional compliance requirement, and that provider's delivery rate dropped sharply starting the same week; users not receiving re-engagement notifications explains the retention drop directly, and it's a data/infrastructure cause (a third-party delivery failure), not a product regression.

Trade-offs and pitfalls. A double-intersection anomaly (one country AND one OS version, not either alone) is a much stronger clue than a single-dimension one, since it usually points at something structurally specific to that combination (a particular routing path, a particular compliance rule) rather than a broad product issue; don't stop investigating after checking each dimension separately if the anomaly doesn't fully reproduce along either dimension alone.

Direct answer

Beyond CTR (click-through rate), a healthy recommender needs signals for whether users are genuinely satisfied, whether they keep returning, and whether the catalog they see stays diverse rather than collapsing onto a shrinking set of popular items. A useful set covers retention, engagement quality, diversity, novelty, explicit satisfaction, and the downstream business outcome the recommender exists to serve. Feedback loops are detected by checking whether rising engagement on these input signals is paired with falling quality on outcome signals over a longer horizon than the model's own feedback window.

Structured elaboration

Detecting harmful feedback loops

• Concentration tracking: monitor exposure concentration with the Gini coefficient (a 0-to-1 measure of how unequally impressions are spread across items, 0 is perfectly even, 1 is all impressions on one item) or category entropy over time; rising concentration alongside falling diversity is the classic signature of a popularity loop, where popular items get recommended more because they were recommended more.
• Lagged correlation: correlate this period's exposure concentration against next period's retention and engagement quality, not the same period's, since the damage from a loop shows up with a lag.
• Held-out exploration: keep a small, lightly personalized slice of traffic as a floor, and compare its long-horizon retention against the fully personalized slice.
• Offline counterfactual checks (an advanced technique, beyond what most interviews expect in depth): inverse propensity weighting (reweighting logged interactions to estimate what a different policy would have produced) can flag a policy that looks good on logged CTR but would underperform under a different exposure distribution.

Worked example

Illustrative, hypothetical figures across two weekly snapshots:

$\text{CTR relative change} = \frac{6.2\% - 5.0\%}{5.0\%} = 24\%\text{ increase}$
$\text{Retention relative change} = \frac{42\% - 36\%}{42\%} \approx 14.3\%\text{ decrease}$
$\text{Concentration change} = 35\% - 20\% = 15\text{ percentage points}$

CTR and concentration are both climbing while the retention of the recommender's heaviest users is falling, exactly the pattern a CTR-only dashboard would report as a win. Reading concentration and lagged retention alongside CTR catches the loop before it shows up in company-level revenue.

Trade-offs & pitfalls

• Every added metric has a monitoring and alerting cost; proposing ten metrics with no owner or cadence for any of them is a common senior-sounding but hollow answer. Pick the smallest set that actually changes a decision.
• Entropy and Gini-based diversity metrics can be gamed by injecting low-quality items just to raise the number; pair diversity metrics with a satisfaction or retention guardrail.
• Offline counterfactual methods reduce, but do not eliminate, bias from confounding; treat them as a prioritization signal for what to A/B test, not a replacement for the online test.
• Long-horizon metrics (30- to 90-day retention) are most likely to catch a feedback loop but are also slowest to move; pair them with a faster leading indicator such as weekly concentration or entropy.

Checklist

• Confirm randomization unit (user_id) and one row per user in experiments.
• Define treatment groups to compare (e.g., control vs treatment).
• Choose tests: chi-square for categorical (device, country), standardized mean difference (SMD) or t-test for continuous (lifetime_spend).
• Flag covariates with p < 0.05 or |SMD| > 0.1 as imbalanced.
• Inspect top countries/devices if small counts exist; consider stratified checks.

SQL: counts/proportions for categorical + chi-square stat; means/stddev + SMD for spend

WITH joined AS (
  SELECT e.group,
         u.user_id,
         u.device,
         u.country,
         u.lifetime_spend
  FROM experiments e
  JOIN users u USING (user_id)
),
-- categorical: device
device_counts AS (
  SELECT device, "group",
         COUNT(*) AS cnt
  FROM joined
  GROUP BY device, "group"
),
device_totals AS (
  SELECT "group", SUM(cnt) AS grp_total FROM device_counts GROUP BY "group"
),
device_expected AS (
  SELECT d.device, d."group", d.cnt,
         (SUM(d.cnt) OVER (PARTITION BY d.device) * t.grp_total::float / SUM(d.cnt) OVER ()) AS expected
  FROM device_counts d
  JOIN device_totals t ON d."group" = t."group"
),
device_chi AS (
  SELECT device,
         SUM( (cnt - expected)*(cnt - expected) / NULLIF(expected,0) ) AS chi2_stat
  FROM device_expected
  GROUP BY device
),
-- continuous: spend summary and SMD between two groups (assumes two groups: 'control' and 'treatment')
spend_stats AS (
  SELECT "group",
         COUNT(*) AS n,
         AVG(lifetime_spend) AS mu,
         STDDEV_POP(lifetime_spend) AS sigma
  FROM joined
  GROUP BY "group"
),
smd AS (
  SELECT
    abs(s1.mu - s0.mu) / NULLIF( sqrt( ( (s0.sigma*s0.sigma)*(s0.n-1) + (s1.sigma*s1.sigma)*(s1.n-1) ) / NULLIF(s0.n + s1.n - 2,0) ), 0) ) AS SMD
  FROM spend_stats s0 JOIN spend_stats s1 ON s0."group" <> s1."group"
  WHERE s0."group" = 'control' AND s1."group" = 'treatment'
)
SELECT
  'device_chi2' AS check_type, jsonb_agg(jsonb_build_object('device', device, 'chi2', chi2_stat)) AS result
FROM device_chi
UNION ALL
SELECT 'spend_smd', jsonb_build_object('SMD', MAX(SMD)) FROM smd;

Imbalance logic

• For device/country: chi-square p-value (compute externally from chi2 and df) — p < 0.05 indicates imbalance. If SQL-only, large chi2 suggests imbalance; inspect devices with largest contributions.
• For lifetime_spend: SMD > 0.1 (small), >0.2 (moderate) indicates meaningful imbalance. If imbalanced, consider re-randomization, stratification, or adjustment in analysis (covariate adjustment).