As a Data Scientist at Zynga, you play a pivotal role in shaping the future of gaming experiences. Your expertise in data analysis and modeling directly influences product development, user engagement, and overall business strategy. By harnessing large datasets and employing statistical methodologies, you will drive insights that enhance gameplay and optimize user retention across diverse gaming platforms.
This position is critical due to the scale and complexity of Zynga’s user base. With millions of players worldwide, your work will not only affect individual games but also contribute to the company’s strategic decisions and innovations. Collaborating closely with product teams, engineers, and marketing, you will tackle challenges ranging from player behavior analysis to predictive modeling, ultimately ensuring that Zynga remains at the forefront of the gaming industry.
Candidates can expect a dynamic environment where analytical thinking and creativity are valued. You will engage in meaningful projects that test your problem-solving skills and allow for significant contributions to the company’s success.
Phone Screening
reportedMost candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.
What to demonstrate
- Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
- Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
- The substance of the questions you ask back, which an experienced screener reads as a level signal
How to prepare
- Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
- Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
- Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered
Technical Evaluation
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
In-Depth Technical Interviews
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
PracHub editorial advice for the preparation topics above.
Testing revenue with a difference in means on a heavy-tailed spend distribution.
Player spend is approximately log-normal with a long Pareto-like tail, so the variance of the sample mean is dominated by a few accounts and the central limit approximation converges slowly at realistic sample sizes. A t-test on raw ARPDAU can flip sign when one account buys a large currency pack. Winsorising or capping at a pre-registered percentile, or testing conversion and conditional spend separately, fixes the variance problem, but note the cost: capping biases toward zero exactly when the true effect lives in the tail, so state the cap before you look.
Randomising players individually for a change that acts on a shared pool.
Matchmaking parameters, queue populations, tradeable-item supply and event leaderboards are shared resources: a treated player is matched against a control player, and treated supply lands in the control arm's market. The treatment leaks across arms, so the measured difference understates or reverses the true effect, and the control arm is no longer a clean counterfactual. Cluster by region and mode, or switchback on time slices with a burn-in long enough to clear carryover in the shared state.
SQL that silently fans out on a one-to-many join
State the grain of each table and the grain you want in the result before writing the join. Pre-aggregate the many side to the join key, or use EXISTS or a window function, and verify with a row count against COUNT(DISTINCT id) rather than trusting that the numbers look plausible.
Averaging per-user rates to produce a population rate
Decide which quantity you want: the mean of per-user ratios and the ratio of summed numerator to summed denominator are different estimands, and heavy users dominate one but not the other. For a ratio metric, aggregate numerator and denominator separately and use the delta method for its variance.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the Central Limit Theorem.
Explain the Central Limit Theorem.
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Say what the estimate is of, and over what population it generalises.
- Translate the result into the decision it informs, in one plain sentence.
Follow-up
- How would you explain this result to someone who does not know statistics?
- Which assumption here is most likely to be violated in practice?
What are the assumptions of a linear regression model?
What are the assumptions of a linear regression model?
Approach
- Set a baseline first, so any model has something honest to beat.
- Check what information would not exist at prediction time, and exclude it.
- Say how the offline result would be validated online before it is trusted.
Follow-up
- What would you monitor after launch to know the model is still valid?
- Where could label leakage enter this setup?
Sink to faucet ratio per currency from a signed ledger
You are given ledger, a pandas DataFrame with one row per signed currency movement: ledger_id, player_id, occurred_at (UTC timestamp), currency_code, delta_amount (signed int64), flow_type in {faucet, sink, transfer, correction}, source_system, is_reversal (bool). Implement sink_to_faucet(ledger) returning one row per (currency_code, week_start) with faucet_units, sink_units and ratio = sink_units / faucet_units. Sink units are reported as positive magnitudes. Rows with flow_type in {transfer, correction} and rows with is_reversal true are excluded from both sides. A currency-week with zero faucet volume must return a null ratio rather than raise or return infinity.
Approach
- Filter first, aggregate second: build one boolean mask for flow_type in ('faucet','sink') and is_reversal == False, apply it once, so the exclusion cannot be applied to one side of the ratio and forgotten on the other.
- Derive week_start by flooring occurred_at to the Monday of its ISO week: occurred_at.dt.normalize() minus pd.to_timedelta(occurred_at.dt.weekday, unit='D'). Avoid dt.isocalendar().week on its own, which drops the year and collapses week 1 of two different years into one bucket.
- Split the aggregate by sign rather than by abs(): faucet_units = sum of delta_amount where flow_type == 'faucet', sink_units = sum of -delta_amount where flow_type == 'sink'. Taking abs() of the whole column hides a faucet row carrying a negative delta, which is a real data bug you want surfaced.
- Pivot to one row per (currency_code, week_start) and divide under a guard so faucet_units == 0 yields NaN, not inf; downstream charts silently drop NaN and silently rescale on inf.
- Run the same aggregate once with the is_reversal filter removed and diff the two results. Any currency whose ratio moves materially is telling you that clawbacks or customer-service corrections are being read as genuine economy flow.
Worked solution 20 min
- Apply the single inclusion mask and assert that the filtered frame contains only the two flow types you intend.
- Add the week_start column by weekday subtraction and confirm every value is a Monday at 00:00 UTC.
- Aggregate faucet and sink magnitudes separately with a groupby on (currency_code, week_start), then join the two results on that key with an outer join so a currency-week with sinks but no faucets survives.
- Divide under a where() guard and return the frame sorted by currency_code then week_start.
Follow-up
- The definition drops the reversal row but leaves the original entry it undid inside the aggregate. Defend that choice or change it, and say which direction the ratio moves either way.
- The soft currency has held a ratio near 0.8 for six weeks. What do you look at next, and what evidence would let you say the economy is nevertheless fine?
- How would you report this when a single live-ops event contributed 60 percent of the week's faucet volume?
How would you optimize a slow-running SQL query?
How would you optimize a slow-running SQL query?
Approach
- State the window function and its partition and ordering out loud before writing it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Follow-up
- How does the query change if the join becomes one-to-many?
- What breaks if events arrive late or out of order?
Describe the process of normalizing a database.
Describe the process of normalizing a database.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Say which table is the grain you start from, and join outward from it.
Follow-up
- How does the query change if the join becomes one-to-many?
- What breaks if events arrive late or out of order?
Stitch crash-fragmented sessions into play blocks with gaps and islands
fct_session has session_id, player_id, session_start_ts, session_end_ts (NULL when the client crashed), duration_seconds (NULL alongside it), platform and ended_reason. A crash splits one sitting into two rows seconds apart. Group consecutive sessions for the same player and platform into play blocks, starting a new block when the gap from the previous end to the next start is 120 seconds or more. For NULL ends, impute session_start_ts plus that player's median duration_seconds on the same platform. Return one row per block.
Approach
- Build the imputed end in its own CTE: COALESCE(session_end_ts, session_start_ts + the median duration as an interval). Compute the median with PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY duration_seconds) grouped by player_id and platform over the non-NULL rows, then join it back. Players with no non-NULL session have no median, so decide explicitly whether to drop them and report how many.
- Get the previous end with LAG(imputed_end) OVER (PARTITION BY player_id, platform ORDER BY session_start_ts, session_id). The session_id tiebreak matters because two sessions can share a start timestamp on a device that relaunched instantly.
- Flag a block boundary where prev_end IS NULL (the first session in the partition) OR session_start_ts - prev_end >= interval '120 seconds', and cast that flag to an integer.
- Turn flags into block ids with SUM(flag) OVER (PARTITION BY player_id, platform ORDER BY session_start_ts, session_id ROWS UNBOUNDED PRECEDING). This is the gaps-and-islands step. The ROWS frame here is explicit, not load-bearing: session_id is unique, so every row is its own peer group and the default RANGE frame would produce the same block ids. What actually keeps two sittings apart is the session_id tiebreak, which is why it has to appear in all three window clauses.
- Drop that tiebreak and the ordering stops being total, which breaks the step in one of two ways depending on the frame. Under the default RANGE, sessions sharing a start timestamp are peers, so each receives the tie group's closing cumulative total, they share a block id, and two genuinely separate sittings merge. Under ROWS they get distinct ids, but the order inside the tie is unspecified, so which session opens the block, and the LAG that fed the boundary flag, can differ between runs on identical data.
- Aggregate by (player_id, platform, block_id) for MIN(session_start_ts), MAX(imputed_end), COUNT(*), the summed in-session seconds and BOOL_OR(ended_reason = 'crash') to mark blocks stitched across a crash.
- State the direction of the imputation bias: if the imputed end lands earlier than the true end, the gap is overstated and the query under-stitches, so the crash-stitch rate under this rule is a lower bound.
Worked solution 35 min
- Compute per-(player_id, platform) median duration_seconds over rows where it is NOT NULL, and count how many players have no median at all.
- Build the imputed_end CTE and confirm no NULL ends remain among the rows you kept.
- Add LAG, the boundary flag and the cumulative-sum block id in one CTE, all three carrying the same PARTITION BY (player_id, platform) and the same ORDER BY (session_start_ts, session_id). If the three orderings disagree, the flags and the ids are computed over different sequences and the block boundaries land on the wrong rows.
- Aggregate to block grain and spot-check a player known to have crashed: their two adjacent rows should share one block id.
- Recompute with the threshold at 30 and at 600 seconds and watch the block count move. A threshold that changes nothing means crashes are not in fact producing adjacent rows.
Follow-up
- The 120-second threshold is an assertion. How would you pick it from the distribution of inter-session gaps instead?
- Under your imputation, does the block count over-count or under-count real sittings, and which direction would you rather err in for a crash-impact readout?
- A player is on two platforms at once. Should that be one block or two, and what does your partition key currently decide for you?
Given a dataset of player actions, how would you identify trends in us…
Given a dataset of player actions, how would you identify trends in user engagement?
Approach
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
- Name one primary metric, then the guardrail that stops it being gamed.
Follow-up
- Which segment would you cut first, and what would that rule out?
- How would you detect that the metric is being gamed rather than genuinely improving?
What metrics would you consider to evaluate the success of a game laun…
What metrics would you consider to evaluate the success of a game launch?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Restate the decision this analysis has to support, and who acts on the answer.
- Fix the population and the time window before naming any metric.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How do you prioritize tasks when managing multiple projects?
How do you prioritize tasks when managing multiple projects?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
If tasked with improving retention rates for a game, what data would y…
If tasked with improving retention rates for a game, what data would you analyze, and why?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Restate the decision this analysis has to support, and who acts on the answer.
- Decompose the metric into the rates that drive it, and say which one you would check first.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
Describe how you would design an experiment to test a new game feature…
Describe how you would design an experiment to test a new game feature.
Approach
- Name the guardrails that would stop a launch even on a positive primary result.
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Decide the analysis before seeing data, including how long it runs and when you look.
Follow-up
- What would you do if you could not randomise at all?
- What would you conclude if the result is positive but the test is underpowered?
Explain the difference between supervised and unsupervised learning.
Explain the difference between supervised and unsupervised learning.
Approach
- Work from the decision backwards to the evidence you would need.
- State your assumptions explicitly before working the problem.
- Clarify what is being asked and what a complete answer would contain.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Recover a causal effect from a catch-up grant threshold
Halfway through a seasonal event, every player below pass tier 20 was automatically granted 500 premium currency; players at tier 20 or above received nothing. The grant was not randomised, and tier is visible to players throughout. Using fct_currency_ledger (source_system, delta_amount, occurred_at), the midpoint tier snapshot, and fct_iap_transaction, estimate the effect of the grant on net revenue over the remaining three weeks. State the design, the bandwidth and functional form, the estimand you can defend, and the single test that can invalidate the whole thing.
Approach
- Identify the design: assignment is a deterministic step function of a known running variable, midpoint tier, at a known cutoff of 20, so this is a sharp regression discontinuity. The comparison is between players just below and just above 20, not between the granted and ungranted populations as a whole.
- Specify estimation: local linear regression on each side of the cutoff with a triangular kernel and an MSE-optimal bandwidth, reporting bias-corrected robust confidence intervals rather than conventional ones, which undercover at the MSE-optimal bandwidth. Report the estimate at half and double the bandwidth as sensitivity. Avoid high-order global polynomials, which are known to manufacture discontinuities at the boundary.
- Handle the discreteness. Tier is an integer with few mass points near the cutoff, so treat the running variable as discrete, cluster standard errors by tier value, and be explicit that the effective sample is the handful of tiers inside the bandwidth, not the row count.
- State the estimand honestly: a local average treatment effect at tier 20 for players sitting at the cutoff at the midpoint. It supports the decision 'should the cutoff move' and does not support 'what would this grant do for a tier-5 player'.
- Run the invalidating test: manipulation of the running variable. Tier is visible and the grant was announced, so players had both the motive and the means to stall just below 20. Test the density of the running variable at the cutoff for bunching, and test that pre-determined covariates are continuous there: install cohort, platform, pre-midpoint spend, matches played before the announcement. Bunching or a covariate jump kills the design, and a donut specification excluding the tiers adjacent to the cutoff is a diagnostic, not a repair.
- Check for co-located confounds and mechanism. Anything else that switches at tier 20, a reward unlock or a shop gate, is inside the estimate, because RD identifies the combined effect of everything that changes at the cutoff. Then use fct_currency_ledger to confirm the granted 500 was actually spent within three weeks; a grant that sits unspent cannot have moved revenue through the claimed mechanism.
Worked solution 40 min
- Build the analysis table: midpoint tier as the running variable, a treated indicator for tier below 20, and net revenue over the following three weeks from fct_iap_transaction at a fixed maturity.
- Fit local linear regressions either side of 20 with a triangular kernel at the MSE-optimal bandwidth, and report the bias-corrected robust interval.
- Repeat at half and double the bandwidth, and at placebo cutoffs of 15 and 25.
- Run the density test at the cutoff and the continuity tests on install cohort, platform, pre-midpoint spend and pre-announcement matches.
- Measure the sink volume of the granted currency in fct_currency_ledger within three weeks, split either side of the cutoff, as the mechanism check.
- Write the estimate as a LATE at tier 20, with the validity tests attached to it rather than in an appendix.
Follow-up
- The density test shows a spike just below tier 20. What can you still estimate, and what would you refuse to report?
- Would you randomise the grant next season, and what would you have to give up to run it?
- The estimate at the cutoff is +$0.42 per player. How would you turn that into a recommendation about where the cutoff should sit?
Net ARPDAU fell nine percent while net revenue stayed flat
Net ARPDAU over a trailing 28 days fell from $0.152 to $0.138 week over week, a 9.2% drop, while summed price_usd_net for completed transactions is flat to within 1%. Finance wants to know whether monetisation weakened. You have dim_player (player_id, install_ts, install_country, acquisition_channel, is_test_account), fct_session (player_id, session_start_ts) and fct_iap_transaction (player_id, purchase_ts, price_usd_net, status). Deliver a one-paragraph verdict and the query behind it.
Approach
- Before touching segments, recompute both sides of the ratio separately for each of the two weeks, using the metric definition and nothing more: numerator is summed price_usd_net over rows with status='completed', denominator is the count of distinct (player_id, date(session_start_ts)) pairs. status is the row's current state, so a transaction that has since flipped to refunded or chargeback already fails status='completed' and has already left the numerator; subtracting refund value on top of that filter removes it a second time and breaks the numerator-times-denominator rebuild below. A ratio can only move through its numerator or its denominator, and confirming which one moved costs one query and eliminates half the hypothesis space.
- Quantify the implied denominator move: if the numerator is flat and the ratio fell by a factor of 0.152/0.138, player-days must have risen by about 10.1%. Check that the observed player-day count matches that figure; if it does not, the numerator is not as flat as reported, and the first suspects are mechanical: a different status filter, a different UTC day boundary between fct_session and fct_iap_transaction, or a window that is not the same length on both sides.
- State the one refund caveat that does survive, as a bound rather than a correction. This table exposes only the current status, with no status_changed_at or refund_ts, so both weeks are read as of query time and the older week has had a week longer for purchases to flip to refunded. That biases the recent week's numerator upward relative to the older one, which pushes ARPDAU up, the opposite direction from the observed fall; it therefore cannot manufacture the 9.2%, though it can hide a small real numerator decline. Say so and move on.
- Cut the new player-days by install cohort age, acquisition_channel and install_country. Look specifically for players whose install_ts falls inside the window, since an install spike enters the denominator immediately but cannot contribute purchase volume at the same rate.
- Compute net revenue per player-day restricted to players who were already active before the window opened. If that figure is flat, monetisation of the existing population did not change and the whole move is denominator composition.
- Confirm is_test_account=false is applied on both weeks and that no new automated or QA population entered fct_session, since test traffic creates player-days with structurally zero revenue.
- Report the verdict as a decomposition, not a direction: state the player-day growth, the channel and country it came from, and the unchanged per-player-day revenue of the pre-existing base.
Follow-up
- The campaign driving the new installs will run for another six weeks. What do you forecast ARPDAU does, and what would you monitor to distinguish a healthy dilution from a bad one?
- Which metric would you put beside ARPDAU on the same chart so this question does not get asked again next month?
- How would your answer change if the new installs were concentrated in one install_country with a much lower local price point?
Instead of guessing where the week should go, day one measures it under a fixed rubric and allocates the remaining hours in proportion to the gaps. The method is deliberately rigid: the allocation is written down before any studying starts and is not renegotiated when a topic turns out to be unpleasant.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Diagnostic, scored before you study anything
- Sit a 100-minute timed diagnostic in four blocks: 30 minutes of SQL across three prompts, 25 minutes of short-answer statistics, 25 minutes on one modelling or case prompt, and 20 minutes delivering one behavioural story aloud.
- Score each block from 0 to 3 on a fixed rubric where 3 is correct and fluent, 2 is correct but slow or prompted, 1 is partially correct, and 0 is stuck, grading the output rather than how the attempt felt.
- Allocate the hours for days two to five roughly in proportion to 3 minus the score in each block, write the allocation down, and commit to not revising it midweek.
Deliverable: A scored rubric and a fixed hour allocation for the rest of the week.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Largest gap: find the boundary rather than the subject
- Break the weakest area into five named sub-skills (for query work: grain control, window frames, date arithmetic, set logic with NULLs, and reading a query plan) and rate each one, so the rest of the week targets a sub-skill instead of a subject.
- Solve three problems chosen to sit just above where the rating drops off, and for each write the first move you failed to make.
- Re-solve one of them from memory four hours later, on paper, with nothing open.
Deliverable: A five-item sub-skill map with the two blocking sub-skills circled.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Largest gap: drill the blocking sub-skill
- Do eight short repetitions of the same shape rather than eight different problems, so what you practise is the pattern and not the puzzle.
- Write the rule you now hold in one sentence, then test it against a case built to break it: a ranking function over a column with ties, or a two-sample test on observations that are obviously dependent.
- Have someone else read your one-sentence rule and find the precondition you left out.
Deliverable: One rule statement with its preconditions attached and one counterexample that would have caught the incomplete version.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Second gap, plus maintenance on your strongest area
- Run the same sub-skill map and boundary protocol on the second-largest gap, compressed into half the day.
- Spend 25 timed minutes on your strongest area to stop it decaying, choosing the hardest problem you can still finish rather than an easy warm-up.
- Compare how the two areas fail: whether you lose time on recall, on setup, or on arithmetic, because the fix differs for each.
Deliverable: A second sub-skill map plus a one-line diagnosis of how each area fails you.
Practice prompt ↗Practice prompt ↗Worked solution ↗05The gap that is not a skill
- Record yourself answering one technical and one behavioural prompt, then count two things in the playback: how many seconds before your first clarifying question, and how many sentences you started without knowing where they ended.
- Rewrite your three most-used stock phrases into shorter versions, and practise saying "I do not know, here is how I would find out" without softening it into a guess.
- Deliver one answer again with a hard 90-second limit to force structure before detail.
Deliverable: Two recordings with a counted improvement in time-to-first-question.
Practice prompt ↗Practice prompt ↗06Retest under day-one conditions
- Sit the same 100-minute diagnostic structure with new prompts of comparable difficulty and score it on the identical rubric.
- Compare block by block, and for any block that did not move, change the method rather than adding hours: a block stuck at 1 usually means the practice was too varied, not too short.
- Write which single block you would still lose the offer on.
Deliverable: A second scored rubric placed next to the first, with one named remaining risk.
Practice prompt ↗Practice prompt ↗07Full loop under interview conditions
- Run a 60-minute mock covering the two blocks that moved least, with an interviewer instructed to interrupt and change direction.
- Write your recovery script for the moment you go blank: restate the question, state your assumption, name the first thing you would check.
- Reduce the week to the rule statements you wrote, each with its preconditions attached, then say every one of them out loud without reading it and cut any you cannot state in a single sentence, since a rule you have to reconstruct mid-answer will not survive being interrupted.
Deliverable: A one-page card holding the recovery script and only the rules you could state from memory.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
An answer without a quantity is hard to interrogate, so interviewers keep probing until they find one. Come with the baseline, the change, the window it was measured over, and how confident you were. If the effect never got measured, say so and say what you would have measured. Fabricated precision is worse than an honest gap.
Describe a situation where you had to persuade a team to adopt your da…
Describe a situation where you had to persuade a team to adopt your data-driven recommendation.
Approach
- Name the disagreement or constraint, and how you resolved it with evidence.
- Pick a story where you drove the decision, not one where you observed it.
- Close with what you would do differently, concretely.
Follow-up
- What would you do differently if you ran that project again?
- How did you know the outcome was caused by your change?
Allocate one analyst-week across three competing escalated requests
Three requests land in the same week and you have five working days. The economy team wants a sink-to-faucet audit per currency after a faucet change shipped ten days ago. Live-ops wants a readout on an event that ends Friday, because the next event is configured from it. Acquisition wants 90-day net revenue per install by channel for a budget meeting in three weeks, and two of the channels launched six weeks ago. All three owners have escalated. Give your allocation, the reasoning you give each owner, and what you refuse or defer.
Approach
- Sort by decision deadline and by reversibility rather than by escalation volume. The event readout is perishable because the population and the live-ops configuration that produced it stop existing on Friday and the next event's config depends on it. The budget meeting is three weeks out. The economy audit has no external deadline but a compounding cost.
- Kill the part that cannot be done correctly at any effort level, and kill it in a ten-minute conversation rather than four days of work. Net revenue per install at 90 days requires cohorts that have reached 90 days of maturity; channels that launched six weeks ago have not, and extrapolating them produces a number that will slope with cohort age. The honest deliverable is matured channels only, with the immature ones listed as excluded and dated for when they qualify.
- Split the economy request into the decision-relevant core and the rest. One day gets the sink-to-faucet ratio per currency_code for the weeks before and after the faucet change, with reversals, transfers and cs_grant excluded, plus the balance percentile curve. A ratio below 1 sustained means balances are accumulating and premium shortcuts will stop selling, which is worth knowing this week. The full per-source audit can wait.
- Give the event readout the largest block, because it is the one with a hard expiry and a downstream configuration decision. Scope it to a decision memo, not a dashboard.
- Publish the allocation in one place with a one-line reason per item, so any escalation argues with the reasoning rather than with you, and the owners can see each other's deadlines.
- Hold back roughly one day. Something breaks most weeks, and an allocation with no slack fails in a way that damages all three commitments instead of one.
Follow-up
- The acquisition owner says a rough number is better than nothing for a budget meeting. What exactly do you give them?
- How would you decide whether the economy audit is genuinely urgent rather than merely important?
- Two weeks of this pattern in a row. What structural change do you propose, and to whom?
Explain a wide revenue interval to a non-technical executive
A 14-day test of a new currency-pack price is done. Net ARPDAU is up 4.1% with a bootstrap 95% interval of -1.8% to +10.3%. Paying conversion is up 0.6 percentage points with a much tighter interval. In both arms the top 1% of payers hold 42% of net revenue. An executive with no statistics background asks whether this is a win, yes or no, and has ten minutes. Give the explanation, the recommendation, and the claim you refuse to make.
Approach
- Answer the decision first, in one sentence, then explain. An executive who waits ninety seconds for a recommendation stops listening to the reasoning.
- Convert the interval into stakes in their units. Translate -1.8% to +10.3% of net ARPDAU into a monthly or annual dollar range at current active player-days, and say which end you would budget against.
- Explain the width with a fact they already believe rather than with sampling theory: 42% of net revenue sits on 1% of accounts, so a handful of large purchases move the average. That is a property of the business, not a defect of the test, and it is why a conversion number of the same length is far tighter.
- Offer the conversion result as the part of the decomposition that does have enough sample, and be explicit that it is a different claim: more people paid, and the size of the average payment is where the uncertainty lives.
- Price more data honestly. The interval narrows roughly with the square root of exposure, so halving its width needs about four times the runtime. Give the calendar date that implies and say whether the decision is worth waiting for.
- Name the claim you will not make, so nobody reports the point estimate as fact after you leave the room.
Follow-up
- The executive suggests capping the top payers and rerunning the numbers to tighten the interval. What do you say?
- Bootstrap intervals can undercover on a very heavy tail. How would you check whether yours is trustworthy at this sample size?
- If the interval had been -0.4% to +1.2%, would your recommendation change, and why?
- 01
Describe a situation where you had to persuade a team to adopt your data-driven recommendation.
- 02
Three requests land in the same week and you have five working days. The economy team wants a sink-to-faucet audit per currency after a faucet change shipped ten days ago. Live-ops wants a readout on an event that ends Friday, because the next event is configured from it. Acquisition wants 90-day net revenue per install by channel for a budget meeting in three weeks, and two of the channels launched six weeks ago. All three owners have escalated. Give your allocation, the reasoning you give each owner, and what you refuse or defer.
- 03
A 14-day test of a new currency-pack price is done. Net ARPDAU is up 4.1% with a bootstrap 95% interval of -1.8% to +10.3%. Paying conversion is up 0.6 percentage points with a much tighter interval. In both arms the top 1% of payers hold 42% of net revenue. An executive with no statistics background asks whether this is a win, yes or no, and has ten minutes. Give the explanation, the recommendation, and the claim you refuse to make.
Is this an official Zynga interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Zynga. Rounds and questions reflect what candidates have reported, not a process Zynga has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult are the interviews, and how much preparation time is typical?
The interviews can be moderately challenging, particularly in technical areas. Candidates often find that 2-4 weeks of dedicated preparation is beneficial to cover core concepts and practice problem-solving.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates typically demonstrate a strong grasp of technical skills, effective communication, and the ability to apply analytical thinking to real-world problems. Additionally, showcasing a genuine interest in gaming can set you apart.
PracHub interview research ↗What is the culture and working style at Zynga?
Zynga promotes a collaborative and innovative work environment. Employees are encouraged to share ideas and insights, contributing to a player-first mentality. Expect an emphasis on teamwork and data-driven decision-making.
PracHub interview research ↗What is the typical timeline from the initial screen to an offer?
The timeline can vary, but candidates often find that the entire process takes 4-6 weeks from the initial application to receiving an offer. This includes various interview rounds and evaluations.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Unity Data Scientist Interview Questions & Guide 2026
Modeling drills for Unity data scientist prep: choosing a baseline, reading regression coefficients honestly, handling class imbalance, and defending a model you would actually ship.
Ubisoft Data Scientist Interview Questions & Guide 2026
Take-home style practice for data scientists preparing for Ubisoft: a messy dataset, a fixed time budget, and a written analysis, reviewed for whether it states its assumptions and whether a reader could reproduce your numbers.
Scopely Data Scientist Interview Questions & Guide 2026
Timed practice for Scopely data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.
Skillz Data Scientist Interview Questions & Guide 2026
Experiment-design practice for Skillz data scientist candidates, covering randomisation units, power, minimum detectable effect and the traps that invalidate a result.