As a Data Scientist at Rockstar, you are at the intersection of world-class creative output and data-driven strategy. You are not just crunching numbers; you are providing the analytical backbone for some of the most influential titles in the gaming industry. Your work directly impacts player experience, marketing effectiveness, and the long-term engagement strategies that define how millions of users interact with our games.
This role requires a unique blend of technical rigor and a genuine passion for the medium. Whether you are modeling player behavior, optimizing marketing spend, or analyzing complex telemetry from live services, your insights must translate into tangible business decisions. You will operate in a dynamic environment where the scale of data is immense and the demand for high-quality, actionable storytelling is constant.
The culture at Rockstar is deeply embedded in gaming. Successful candidates demonstrate not just technical proficiency, but a clear, enthusiastic connection to the gaming industry and the specific titles we produce.
HR Screen
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 Interviews
reportedMuch of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.
What to demonstrate
- Whether the query you write matches the plan you just described
- What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
- Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly
How to prepare
- Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
- Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
- Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock
Take-Home Assessment
reportedBefore any modelling, the dataset is itself the first test. Take-home data usually carries something broken: rows duplicated at an unexpected grain, a join that silently drops part of the population, timestamps stored in more than one timezone, or missingness correlated with the outcome. An hour spent profiling row counts, key uniqueness and date ranges is not overhead, because it decides whether every number after it is real. What separates submissions is whether you report the defects you found and adapt the analysis to them, rather than modelling over them quietly and hoping the aggregate absorbs it.
What to demonstrate
- Whether you established the grain of each table and checked row counts after every join, and said so in the writeup
- Whether data defects you found are surfaced with their effect on the conclusion, instead of being dropped without comment
- Whether filters and exclusions are reproducible from the submitted code, with the size of the excluded population quantified
How to prepare
- Write a short profiling script you can point at any unfamiliar table: row count, distinct key count, null rate per column, and the min and max of every date field, then run it before anything else
- Write the funnel or the join chain as one query and check the row count at each grain, so a silent fan-out shows up as a number rather than as a wrong answer later
- On a past dataset, list every exclusion you applied and how many rows each one removed, then draft the single sentence about it you would put in a report
Final Panel Interview
reportedWhere a loop includes a partner from outside the data team, that conversation usually carries the same weight as the technical ones and gets the least preparation. The person opposite you will not follow a derivation and does not need to. They are working out whether having you involved would make their decisions better or slower. The failure mode is not being too technical. It is answering a question about a decision with a description of your method, leaving the translation to them. What they carry into the debrief is the sentence you handed them, not the analysis underneath it.
What to demonstrate
- Whether a statistical result arrives as something the partner could act on, with the one caveat that would change their decision kept and the rest left out
- Whether you can state what you need from their side, in their terms: instrumentation that does not exist yet, a definition they own, or a holdout they have to agree to
- Whether uncertainty is given as a range someone can plan against, rather than as hedging that invites them to ignore the result
- Whether you ask what decision is actually on the table before explaining anything
How to prepare
- Take a result you know well and write the version for someone who stops reading after one sentence, then the three-minute version, and check the short one is not the long one with the qualifications stripped out
- For a past project, list everything you asked a non-technical partner for and how you phrased it, then rewrite each ask so it names what goes unmeasured without it
- Practise saying where a result does not apply, out loud, in one sentence that a partner could repeat accurately to someone else
PracHub editorial advice for the preparation topics above.
Booking revenue at gross, on purchase day, for cohorts of different ages.
Revenue matures: the platform fee is known immediately, but refunds and chargebacks land over weeks, and later purchases keep accruing to the same cohort. Comparing a two-week-old cohort with a one-year-old cohort therefore compares two different maturities, and any trend chart built that way slopes in the direction of cohort age. Quote cohort revenue at a fixed age, and exclude cohorts that have not reached it rather than extrapolating them.
Treating the account as the person, and the calendar week as neutral time.
Reinstalls, multi-platform play and shared accounts split or merge humans relative to player_id, which inflates install counts and deflates retention denominators in ways that correlate with platform and campaign. Meanwhile daily actives spike on release day and decay over the following week, so a week-over-week read aliases the content calendar. Anchor comparisons to time since release or to matched days in the release cycle, and report identity-sensitive metrics with an explicit statement of which identity key was used.
Explaining an aggregate move without decomposing the mix shift
Split the change in the aggregate into within-segment movement and movement in segment weights before you explain it. Every segment's rate can fall while the overall rate rises, purely because volume shifted toward segments that already had higher rates.
Crediting a treatment for regression to the mean
Selecting a group because it is extreme (lowest-engagement users, accounts having their worst month, the bottom decile of a score) moves that group's expected next-period value back toward the average even under no treatment, by exactly as much as the selecting measure is imperfectly correlated with its own later value. Compare against units that met the same selection rule and went untreated, or use two pre-periods so the bounce-back is visible before the intervention starts. A pre-post number on a group chosen for being extreme measures the selection rule, not the treatment.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How would you approach building a churn prediction model for a live-se…
How would you approach building a churn prediction model for a live-service game?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Set a baseline first, so any model has something honest to beat.
- Pick an evaluation metric that matches the cost of each error type, not a default.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- Where could label leakage enter this setup?
Rebuild running balances and find the first ledger divergence
Using the same ledger frame plus balance_after (int64), rebuild each player's running balance per currency_code by accumulating delta_amount in (occurred_at, ledger_id) order, then report the first row per (player_id, currency_code) where your computed balance disagrees with balance_after. You may not use cumsum, groupby().cumsum() or expanding(); accumulate explicitly. Assume each group starts from a balance of zero. Reversals and corrections do count toward the balance. Return player_id, currency_code, ledger_id, computed_balance, balance_after and diff, sorted by absolute diff descending.
Approach
- Sort once on (player_id, currency_code, occurred_at, ledger_id). The ledger_id tiebreak is load-bearing: entries routinely share occurred_at to the second, and an unstable order manufactures divergences that move between runs.
- Accumulate in one pass over itertuples with a dict keyed by (player_id, currency_code), resetting to zero when the key changes. One pass is O(n) and beats any reshape; the ban on cumsum is about showing the accumulation, not about speed.
- Record the first index per key where computed != balance_after and then stop tracking that key. After a break every later row inherits the same offset, so reporting all of them buries the single row that matters.
- Keep reversals and corrections in the accumulation. They are genuine balance movements, which is the exact opposite of the rule for flow aggregates, and mixing the two rules up is the common error in this domain.
- Sort the output by abs(diff) descending. A one-unit diff is usually a rounding artefact somewhere upstream; a six-figure diff is a lost grant, and the ordering puts the second kind on the first screen.
Worked solution 25 min
- Sort on the four-column key and reset the index so positional recording is unambiguous.
- Walk the frame once, carrying a dict of running balances and a set of keys already flagged, appending a record the first time a key disagrees.
- Assemble the flagged records into a frame, compute diff = computed_balance - balance_after, and sort by its absolute value descending.
- Spot-check by re-accumulating one flagged group by hand from its first row and confirming the break lands on the reported ledger_id.
Follow-up
- Your check assumes each group starts at zero. How would you distinguish a player whose early history was trimmed by a retention policy from one who genuinely started at zero?
- Divergence appears on exactly one currency and only after a specific date. What is your next query?
- How would you run this as a daily monitor over hundreds of millions of rows without rebuilding every balance from the beginning of time?
Discrete hazard of churn indexed by matches played
Given matches (player_id, started_at) for one install cohort, sessions (player_id, session_start_ts), and a data cutoff timestamp, define churn at match k as no session starting in (t_k, t_k + 14 days], where t_k is the start of that player's k-th match. Build the discrete hazard h(k) and the survival curve S(k) for k = 1 to 50. A player-index enters the risk set at k only if the player has not already churned before k and t_k is at or before cutoff minus 14 days. Return k, risk_set, churned, h and S, and name the two largest hazard spikes.
Approach
- Build the match index yourself: sort matches by (player_id, started_at) and set k = groupby('player_id').cumcount() + 1. Never take a stored index without verifying it is dense per player, because one gap shifts every downstream k for that player.
- Decide churn per (player, k) without a cross join. Sort each player's session timestamps once and use np.searchsorted to ask whether any session falls in the half-open window (t_k, t_k + 14d]. A merge of matches to sessions is quadratic in the busiest players and is where this exercise usually dies.
- Keep observability separate from the event. A player-index is usable at k only when t_k is at or before cutoff minus 14 days; a player whose 30th match was yesterday contributes to k = 1 through 29 and then leaves. This is right-censoring on the match axis, and dropping those players outright instead of truncating them biases the entire curve toward whoever plays fastest.
- Compute h(k) = churned_at_k / risk_set_k and S(k) as the cumulative product of (1 - h(j)) for j up to k. The product form is what makes the censoring handling count; a naive share of the original cohort still alive divides by a denominator containing players who could never have been observed at k.
- Read the spikes against the loop rather than the calendar: a bump at a given k usually maps to a difficulty wall, the end of a tutorial reward track, or the point where a faucet stops paying. Name the k values, then name the query that would confirm each one, rather than asserting a cause.
Follow-up
- Someone reports that players who reach match 50 retain four times better. Rewrite that as a claim you would be willing to defend, and say what it costs you to do so.
- Your definition retires a player who keeps logging in but stops playing matches. Is that churn? What does including or excluding them do to the curve?
- Add a time-varying covariate for whether the player was in a party at match k. What changes about the estimator, and what can you now claim that you could not before?
Audit sink-to-faucet balance per currency over seven days
fct_currency_ledger holds one signed row per currency movement: player_id, occurred_at, currency_code, delta_amount, flow_type, source_system, is_reversal. Join dim_player for is_test_account. For the trailing seven days, return one row per currency_code with faucet volume, sink volume and the sink-to-faucet ratio. Faucet volume is the sum of delta_amount where flow_type = 'faucet'; sink volume is the sum of abs(delta_amount) where flow_type = 'sink'. Exclude test accounts, exclude flow_type in ('transfer','correction'), and exclude rows where is_reversal is true. Say what a ratio below 1.0 implies.
Approach
- Filter before aggregating: restrict occurred_at to the trailing seven days, inner join dim_player and drop is_test_account rows, then drop flow_type in ('transfer','correction') and is_reversal rows. A transfer moves currency between players without creating or destroying any, so counting it inflates both sides of the ratio.
- Use conditional aggregation in one pass, SUM(delta_amount) FILTER (WHERE flow_type = 'faucet') and SUM(abs(delta_amount)) FILTER (WHERE flow_type = 'sink'), rather than two subqueries joined on currency_code. The join form silently drops a currency that has faucets but no sinks.
- Cast to numeric before dividing and wrap the denominator in NULLIF(faucet_volume, 0). delta_amount is bigint, so bigint division truncates toward zero and a ratio of 0.8 renders as 0.
- Group by currency_code only. A pooled ratio across currencies is meaningless because one soft-currency unit and one premium-currency unit are not the same quantity.
- Read the output: a sustained ratio below 1.0 means outstanding balances in that currency are growing, which erodes the value of every premium shortcut priced in it.
Worked solution 20 min
- Write the base CTE: ledger rows with occurred_at >= now() - interval '7 days', inner joined to dim_player on player_id with is_test_account = false.
- Add the exclusions: flow_type IN ('faucet','sink') and is_reversal = false.
- Aggregate with two FILTER clauses, grouped by currency_code.
- Compute sink_volume::numeric / NULLIF(faucet_volume, 0) and round to three decimals.
- Re-run once with the is_reversal exclusion removed and note which currency moves most; that tells you whether reversals are material.
Follow-up
- Excluding is_reversal rows leaves the original entry they undo still counted on its own side. How would you exclude the reversed original as well, using reversed_ledger_id, and does it change the reading?
- A single customer-service grant of ten million soft currency lands in the window. Which source_system values would you exclude from an economy-health read, and what do you give up by excluding them?
- The ratio is 0.8 for premium currency but 1.1 for soft currency in the same week. What is the first query you write next?
Reconstruct running balances and find the first ledger divergence
fct_currency_ledger has ledger_id, player_id, occurred_at, currency_code, delta_amount (signed), balance_after and is_reversal. balance_after is the balance the game server recorded at write time. Recompute the running balance per player per currency from delta_amount alone, compare it to balance_after row by row, and return the first row where the two disagree for each affected (player_id, currency_code), with both values and their signed difference. Include reversal rows: a reversal is a real movement of currency. Assume occurred_at can tie within a single player.
Approach
- Compute the running total with SUM(delta_amount) OVER (PARTITION BY player_id, currency_code ORDER BY occurred_at, ledger_id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW). Partitioning by player alone is wrong because balance_after is tracked per player per currency.
- Be clear about what the ROWS keyword is doing here, because it is less than it looks. Under the default RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, the frame ends at the last peer of the current row, where peers are rows equal on every ORDER BY key. ledger_id is the table's primary key, so with (occurred_at, ledger_id) in the ORDER BY every row is its own peer group and RANGE returns exactly the same numbers as ROWS. Write ROWS anyway: it states the intent and skips peer detection. Do not present it as the thing that makes the query correct.
- The frame becomes load-bearing only when you drop the tiebreak and order by occurred_at alone, which is the mistake this data is arranged to punish. Two entries written in the same second are then peers, and the default RANGE hands both of them the cumulative total as of the end of the tie group. Only the last row of a tie group is entitled to that total, so every earlier row of the tie runs ahead of its own balance_after and is reported as a divergence on a ledger that is intact. Switching to ROWS while still ordering by occurred_at alone does not fix it either: the sum advances one row at a time, but the order within the tie is unspecified, so which row carries which running total can change between runs on identical data. The unique tiebreak is the fix; the frame keyword is documentation.
- Do not exclude is_reversal rows here. A reversal moves currency, so dropping it makes the recomputed balance diverge by construction. This is the opposite of the exclusion you apply when measuring faucet and sink volume, and knowing why the two differ is the point.
- Flag rows where running_balance <> balance_after, then take the earliest per partition with ROW_NUMBER() OVER (PARTITION BY player_id, currency_code ORDER BY occurred_at, ledger_id) over the flagged set and keep rn = 1. Use the same ordering as the running sum, or the row you call first is not the row the sum diverged on.
- Report the signed difference rather than a boolean. A constant offset from the first divergence onward points at one missing or duplicated entry; a difference that grows points at a systematic sign or unit error.
Follow-up
- Every divergence starts at the same delta value across thousands of players. What does that pattern point at, and which column do you group by to confirm it?
- How would you rewrite this to run incrementally each night against yesterday's rows instead of rescanning every player's full history?
- A player's earliest ledger row has balance_after = 500 and delta_amount = 500. What assumption about starting balances does your query make, and where does that assumption break?
How would you measure the success of a new in-game marketing campaign?
How would you measure the success of a new in-game marketing campaign?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Restate the decision this analysis has to support, and who acts on the answer.
- State what result would change your recommendation, so the answer is falsifiable.
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?
Design a metric to quantify "Player Engagement" for an open-world titl…
Design a metric to quantify "Player Engagement" for an open-world title.
Approach
- 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.
- Name one primary metric, then the guardrail that stops it being gamed.
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 player retention drops suddenly after a patch, what is your step-by…
If player retention drops suddenly after a patch, what is your step-by-step diagnostic process?
Approach
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
- Decompose the metric into the rates that drive it, and say which one you would check first.
Follow-up
- Which segment would you cut first, and what would that rule out?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How do you determine if a change in player behavior is statistically s…
How do you determine if a change in player behavior is statistically significant or just noise?
Approach
- 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.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- Which segment would you cut first, and what would that rule out?
- What would you do if the primary metric and the guardrail moved in opposite directions?
Explain the difference between A/B testing and multivariate testing in…
Explain the difference between A/B testing and multivariate testing in the context of a game feature release.
Approach
- Name the guardrails that would stop a launch even on a positive primary result.
- Say whether units interfere with each other, and switch design if they do.
- 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?
- How would you handle interference between treated and control units?
What Python libraries do you prefer for data manipulation, and why?
What Python libraries do you prefer for data manipulation, and why?
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?
Power a net-revenue test on a heavy-tailed spend distribution
Size a test on net revenue per active player-day: the sum of price_usd_net over fct_iap_transaction rows with status = 'completed', less the net value of anything since refunded or charged back, divided by player-days. Over the last 28 days that per-player-day figure has mean $0.118 and standard deviation $2.45, with 1.9% of player-days non-zero. You have 900,000 daily active players and a 50/50 split. Size a test to detect a 3% relative lift at alpha 0.05 two-sided with 80% power, then state precisely what winsorising at the 99.9th percentile (standard deviation $1.05) buys and what it costs.
Approach
- Put the effect in absolute units: delta = 0.03 * 0.118 = $0.00354 per player-day. Relative effects are convenient to state and useless to compute with.
- Apply n per arm = 2 * (z_{1-alpha/2} + z_{1-beta})^2 * sigma^2 / delta^2 = 15.698 * 6.0025 / 1.2532e-5 = 7.52 million player-days. At 450,000 player-days per arm per day that is 16.7 days, so about 17. Note the coefficient of variation of 20.8 is what makes this number large, not the size of the effect.
- Do not assume the central limit theorem holds just because n is large. Compute the sample skewness of the per-player-day metric and apply the working rule that a t-based interval needs roughly n > 355 * skewness^2 per arm to hold its nominal coverage. With under 2% non-zero days and a long conditional tail the skewness runs into the tens, so the floor is in the hundreds of thousands per arm: satisfied at 7.5 million, not satisfied in a two-day read or a single-country segment.
- Price the winsorisation: sample size scales linearly in sigma^2, so cutting sigma from $2.45 to $1.05 multiplies n by (1.05/2.45)^2 = 0.184, giving 1.38 million player-days per arm, about 3.1 days. That is the buy.
- State the cost precisely. The capped metric estimates the winsorised mean, not the mean. If the treatment works by moving the top 0.1% of player-days, the capped test has almost no power against it and the point estimate is biased toward zero. The cap percentile and the rule for applying it must be written down before anyone sees which arm the large purchases landed in.
- Offer the decomposition as the better default: test paying conversion (a cheap binary metric) and net spend per paying player-day separately, report both with their own intervals, and bootstrap over players for the combined effect, since the ratio of means needs the covariance the delta method would otherwise ignore.
Worked solution 30 min
- Convert the relative target to absolute: delta = 0.03 * 0.118 = $0.00354, delta^2 = 1.2532e-5.
- Compute n per arm = 2 * 7.849 * 2.45^2 / 1.2532e-5 = 15.698 * 6.0025 / 1.2532e-5 = 7.52e6 player-days.
- Divide by 450,000 player-days per arm per day to get 16.7 days.
- Recompute with sigma = 1.05: n per arm = 15.698 * 1.1025 / 1.2532e-5 = 1.38e6 player-days, about 3.1 days.
- Compute the skewness floor 355 * skewness^2 for the observed skewness and compare it with both sample sizes.
- Write the pre-registration sentence: metric, cap percentile, refund treatment and horizon, fixed before the first look.
Follow-up
- The capped metric reads +2.1% with a 95% interval of [-0.9%, +5.1%]. What do you say about the uncapped effect, and what can you legitimately claim about revenue?
- One account spends $4,900 in treatment on day three. Walk through what you do, and what you must have written down beforehand for that answer to be credible.
- Finance wants this run on gross bookings instead. What changes in the sizing and in the interpretation?
Daily players down twelve percent eleven days after a release
Daily core-loop players, meaning distinct players per UTC day with at least one fct_match_participant row whose result is not 'abandon', stood at 1.41M last Monday and 1.24M this Friday, a 12% fall. A content release shipped eleven days ago. Leadership is drafting a note saying the release is losing players. Using fct_match_participant (player_id, started_at, result) and the release calendar, say whether this is an anomaly and what you would report instead.
Approach
- First check the two endpoints are comparable at all: Monday and Friday are different days of the week, and daily actives in a session-based product have a stable weekly shape. Compute the mean ratio of Friday to the preceding Monday over the last twelve weeks before saying anything about the release.
- Re-index the series to days since release rather than calendar date. Take the last four release cycles, index each day to that cycle's day-1 value, and overlay them. This is the only comparison that holds both the content calendar and the position in the decay curve constant.
- Read the current cycle's day-11 index against the distribution of prior cycles' day-11 indices. If it sits inside that spread, there is no anomaly to explain and the note should not be sent.
- Only if the current index sits outside the historical spread, decompose the residual: cut by install cohort age (new versus returning), platform and server_region, and check whether the shortfall is concentrated or broad.
- Replace the two-point comparison with two reportable series: a trailing 7-day average, which removes the weekly shape by construction, and a release-cycle-aligned index, which removes the content calendar. State that the raw day-over-day number is not interpretable without both.
Follow-up
- A stakeholder insists on a single daily number on a dashboard. What do you put there, and what do you accept losing?
- Suppose the current cycle's day-11 index is genuinely below every prior cycle. What are the first three cuts you run, and in what order?
- How do you handle the cycle where the release slipped by four days, so that cycle's calendar and release alignments disagree?
For someone who can already write the query and train the model but stalls when asked what to measure or whether a change is worth making. Metric definition and case structure come first; the technical work is kept as maintenance rather than the centre of the week.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Metric anatomy
- For three products you use daily, write one primary metric, two input metrics that plausibly move it, and one guardrail that would catch a cheap way of moving the primary at the cost of the product.
- For one of them, specify the metric precisely enough that two analysts would return the same number: numerator, denominator, unit of observation, time window, and how returning and deleted accounts are treated.
- Pick a ratio metric and write what happens to it when the denominator shrinks for reasons unrelated to the numerator, with a concrete example of that happening.
Deliverable: A one-page metric tree for one product, with the primary metric written as an unambiguous spec.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Diagnosing a drop without guessing
- Take the prompt "weekly active users fell 8 percent week over week" and write the segmentation plan before proposing any cause: platform, region, tenure cohort, acquisition channel, and whether the movement sits in the numerator or in a changed denominator.
- List the instrumentation failures that manufacture fake drops (a client release that stopped firing an event, a bot filter change, a shifted date boundary or timezone) and write the query that rules out each one.
- Rehearse stating the boring explanations first, seasonality and day-of-week composition, before reaching for a product cause.
Deliverable: A drop-diagnosis checklist short enough to recite from memory in under a minute.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Should we build it
- Take a feature idea and write it as a bet: what you believe is true, what would have to be true for it to pay off, the metric that would confirm it, and the effect size that would justify the engineering cost.
- Size the opportunity top-down and bottom-up, then reconcile the two numbers in writing instead of quoting whichever is friendlier.
- Write the counter-metric that would make you kill the feature even if it wins on the primary metric.
Deliverable: A one-page product memo ending in a decision rather than a list of considerations.
Practice prompt ↗Practice prompt ↗04The places aggregate numbers lie
- Construct a Simpson's paradox numerically: two segments where the treatment wins within each segment yet loses overall, and identify the shift in segment weights that causes it.
- Take a heavy right-tailed quantity such as revenue per user and write why the mean is the wrong summary, which percentile you would report instead, and what a moving mean with a stable median tells you.
- Write your definition of a session for the product from day one, then name two real behaviours it misclassifies.
Deliverable: One page holding a worked Simpson's paradox table and a session definition with its two known failure cases.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Technical maintenance, aimed at metrics
- Solve four timed SQL prompts that all end in a ratio metric, so the question of grain stays live in every answer.
- Compute a 95 percent confidence interval for a proportion on a small sample, and state why the normal approximation is unreliable when either np or n(1 minus p) falls below roughly 10, along with which interval you would use instead.
- Take one metric from your day-one tree, write the query that computes it correctly, then write the query that computes it wrong in the most plausible way and explain how you would notice.
Deliverable: Four solved prompts plus a matched correct and plausible-wrong query for one metric.
Practice prompt ↗Practice prompt ↗06Turning engineering work into data science stories
- Write three project stories as situation, decision, trade-off, outcome, each carrying one number and one thing you got wrong.
- For the story you will lead with, prepare an answer to "what would you do differently" that names a decision you made, not a constraint you were handed.
- Practise the sentence that reframes a systems project as a question project: the question the work answered, ahead of the pipeline it shipped.
Deliverable: Three written stories with the lead story delivered aloud and timed under four minutes.
Practice prompt ↗Practice prompt ↗07Mock case and gap list
- Run a 40-minute mock case with someone playing a product manager who pushes back on your metric choice, and record it.
- Listen back and mark every moment you proposed a solution before the success metric existed.
- Rewrite those moments as the question you should have asked, and rehearse the first 90 seconds of the case until scoping comes before solving.
Deliverable: A recorded case plus a rewritten opening 90 seconds.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Nearly every data role forces a trade between the analysis you want and the one that fits the decision window. Prepare a case where you deliberately shipped something less rigorous, named the weakness to the person relying on it, and said what would change your answer. The naming is the part interviewers listen for.
Describe a time you had to explain a complex statistical model to a no…
Describe a time you had to explain a complex statistical model to a non-technical stakeholder.
Approach
- Pick a story where you drove the decision, not one where you observed it.
- Name the disagreement or constraint, and how you resolved it with evidence.
- Close with what you would do differently, concretely.
Follow-up
- What did you decide not to do, and why?
- How did you know the outcome was caused by your change?
Tell me about a time you had to pivot your analytical approach due to …
Tell me about a time you had to pivot your analytical approach due to new information.
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Close with what you would do differently, concretely.
- Name the disagreement or constraint, and how you resolved it with evidence.
Follow-up
- How did you know the outcome was caused by your change?
- What would you do differently if you ran that project again?
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 time you had to explain a complex statistical model to a non-technical stakeholder.
- 02
Tell me about a time you had to pivot your analytical approach due to new information.
- 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 Rockstar interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Rockstar. Rounds and questions reflect what candidates have reported, not a process Rockstar has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗Is gaming industry experience mandatory?
While it is not strictly mandatory, a deep, demonstrable interest in gaming is essential. You must be able to speak the language of our players and understand the unique challenges of the gaming market.
PracHub interview research ↗What is the typical difficulty level of the interviews?
Candidates generally report the difficulty as average, but the rigor is high regarding practical application. Expect to be challenged on your "real-world" problem-solving rather than just textbook definitions.
PracHub interview research ↗How long does the entire process take?
The process typically spans a few weeks. It involves an HR screen, several technical rounds, and a take-home assessment. We aim to keep the process efficient, but thoroughness is a priority.
PracHub interview research ↗Are there remote or hybrid options?
Our roles are typically tied to specific locations, such as New York, London, or Irvine. Hybrid work arrangements are common, but you should clarify the specific expectations for your role with your recruiter.
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Zynga Data Scientist Interview Questions & Guide 2026
Prepare for the data scientist interview at Zynga with original practice on experiment design, SQL, and metric reasoning, each exercise paired with a worked solution and the reasoning behind it.
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.
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.
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.