As a Data Scientist at Scopely, you play a pivotal role in transforming data into actionable insights that drive strategic decision-making and enhance user experiences. Your work goes beyond mere data analysis; it involves leveraging advanced statistical methods, machine learning models, and analytics to influence game development and marketing strategies. By interpreting vast datasets generated by millions of players, you will help shape the future of Scopely's gaming products and ensure they resonate with audiences.
The impact of your role is profound. You will collaborate with cross-functional teams, including product managers, engineers, and designers, to inform game design choices and optimize monetization strategies. The complexity and scale of the data you handle will challenge you to innovate continuously, making your contributions critical to the company’s success. You will work on projects that not only require technical expertise but also a creative mindset to solve unique problems and enhance player engagement, ensuring that Scopely's games remain at the forefront of the industry.
Phone Interview
reportedAn added round often puts you in front of someone outside the core hiring team: a partner engineer, a product owner, a domain expert, sometimes a more senior manager. The question they are really asking is not whether you can do the work but whether they would trust a number that came from you. That changes what a good answer looks like. Lead with what the decision cost and what it changed, keep the method available but not central, and be plain about the limits of your evidence. Overstating a result is the fastest way to lose this round.
What to demonstrate
- Whether you can explain a technical choice to someone who will never read your code, without either flattening it into nothing or hiding inside jargon
- Honesty about evidence strength: what the analysis establishes, what it only suggests, and what it cannot say at all
- How you take disagreement, specifically whether you update on a good objection, hold your position with reasons, or fold on contact
How to prepare
- Write the two-sentence version of your most technical project for a non-specialist, then check that neither sentence needs a method name to make sense.
- For one result you are proud of, write the strongest objection someone could raise and a response that concedes the part of it that is correct.
- Prepare one decision that turned out to be wrong: how you found out, what it cost, and what you changed afterwards. A senior cross-functional interviewer asks for this more often than a technical one does.
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
Virtual Onsite Meeting
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.
Treating a non-significant result as proof of no effect
Say whether the confidence interval excludes the effect sizes you would have cared about. If it does not, the honest reading is that the test was underpowered, so report the minimum detectable effect the design could have found and what sample size would resolve it.
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.
How would you optimize a machine learning model's performance?
How would you optimize a machine learning model's performance?
Approach
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Say how the offline result would be validated online before it is trusted.
- Check what information would not exist at prediction time, and exclude it.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- What would you monitor after launch to know the model is still valid?
What metrics would you use to evaluate a classification model?
What metrics would you use to evaluate a classification model?
Approach
- Check what information would not exist at prediction time, and exclude it.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- What would you monitor after launch to know the model is still valid?
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?
Provide an example of how you would implement a recommendation system.
Provide an example of how you would implement a recommendation system.
Approach
- State the window function and its partition and ordering out loud before writing it.
- 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 would you verify this result without re-running the same query?
- How does the query change if the join becomes one-to-many?
Write a SQL query to retrieve specific data from a database.
Write a SQL query to retrieve specific data from a database.
Approach
- State the window function and its partition and ordering out loud before writing it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- What breaks if events arrive late or out of order?
- How does the query change if the join becomes one-to-many?
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?
You have a dataset with millions of observations. How would you approa…
You have a dataset with millions of observations. How would you approach analyzing it to derive insights?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- 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.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- Which segment would you cut first, and what would that rule out?
Explain how A/B testing works and what considerations you must take in…
Explain how A/B testing works and what considerations you must take into account.
Approach
- Name the guardrails that would stop a launch even on a positive primary result.
- State the primary metric and the minimum effect worth shipping, then size the test.
- Decide the analysis before seeing data, including how long it runs and when you look.
Follow-up
- What would you conclude if the result is positive but the test is underpowered?
- What would you do if you could not randomise at all?
How would you design an experiment to test a new feature in one of Sco…
How would you design an experiment to test a new feature in one of Scopely's games?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Say whether units interfere with each other, and switch design if they do.
- Name the guardrails that would stop a launch even on a positive primary result.
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
- Clarify what is being asked and what a complete answer would contain.
- State your assumptions explicitly before working the problem.
- Work from the decision backwards to the evidence you would need.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
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?
Sessions per player dropped the week a client version shipped
Sessions per active player fell 31% the week a client version rolled out, while matches per active player and total play seconds are flat. fct_session has session_id, player_id, session_start_ts, session_end_ts, duration_seconds, app_version, matches_started, ended_reason. A growth lead has filed this as an engagement regression. Determine whether player behaviour changed or the session boundary did, using only these columns, and state the evidence that would settle it either way.
Approach
- Start from the conservation check that is already in the prompt: if matches per active player and total play seconds are both flat while session count fell, the same activity is being partitioned into fewer containers. Genuine disengagement would move at least one of those two.
- Verify the implied arithmetic. If sessions per player fell 31%, matches per session must have risen by 1/0.69 minus 1, about 44.9%, for matches per player to stay flat. Compute it. A match that lands close to that figure is strong evidence of re-partitioning rather than behaviour.
- Split the same calendar day by app_version. Holding the date fixed removes weekday, release-calendar and server-side effects, so a step difference between versions on one day localises the change to the client. Note the caveat aloud: version adoption is not random, since fast updaters differ from slow ones, so this is corroboration, not proof.
- Get mechanism evidence from the gap distribution. For each player, compute session_start_ts minus the lagged session_end_ts, and histogram those gaps by app_version. If the client's idle timeout lengthened, the old version has mass in the band between the old and new timeouts and the new version has none, because those gaps now sit inside a single session. The cut point names the new timeout.
- Handle the null trap explicitly: duration_seconds is null whenever session_end_ts is null, which is what a crashed client leaves behind. An average over duration_seconds silently drops those rows, so report the null rate by app_version and by ended_reason alongside any duration statistic.
- Deliver the verdict with a restatement plan: which historical series must be recomputed on a consistent boundary, and which metrics, such as matches per active player, were never affected and can be compared across the change.
Follow-up
- Which downstream metrics in this product are defined on sessions rather than on players or matches, and what does each of them now mis-state?
- How would you backfill a comparable series across the boundary change, and what would you refuse to backfill?
- If ended_reason='unknown' also rose on the new version, does that strengthen or weaken your conclusion?
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 ↗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.
Most data work is done by groups, so an interviewer has to work out which piece was yours. An answer that runs on 'we' for several minutes gets interrupted with a question about what you personally did, and by then the answer sounds defensive even when it is true. Mark your own contribution as you go, and name the parts that belonged to someone else instead of leaving them ambiguous. Keep a few specifics back as well, like the name of the metric or who actually objected, so a probe can be answered with something you had not already said.
Describe a situation where you had to persuade a team to adopt your an…
Describe a situation where you had to persuade a team to adopt your analysis or recommendation.
Approach
- Name the disagreement or constraint, and how you resolved it with evidence.
- Quantify the outcome, including what you would not claim credit for.
- State the situation in two sentences and spend the rest on your reasoning.
Follow-up
- How did you know the outcome was caused by your change?
- What did you decide not to do, and why?
Defend an unpopular readout on a live-ops event
A two-week live-ops event closed with gross bookings up 18% against the prior week. Your readout says it added no net revenue: summed price_usd_net in fct_iap_transaction over the 28 days spanning the event is flat against a matched window one release cycle earlier, and fct_currency_ledger shows premium-currency sinks falling while faucets from source_system = 'pass_tier' rose. The event owner disputes the readout in a review with their director present. Give the argument you would make in that room, and name the one piece of evidence you would concede.
Approach
- Separate the disputed claim from yours. Gross bookings up 18% is true and you are not contesting it. Restate your finding precisely: net of platform fee and of refunds recognised to date, over a window long enough to contain the pull-forward, the number does not move.
- Present the decomposition rather than the aggregate, because the aggregate is what the room is already arguing about. Split the delta into active player-days, paying conversion, and net spend per converting player-day. If conversion is flat and spend per payer spiked inside the event window then fell below baseline after, that is re-timing, not new demand.
- Evidence the re-timing at player grain: take the player_ids who purchased during the event and chart their purchase timing in the four weeks before and after. A pulled-forward purchase shows as a deficit on the same accounts, not as a smaller cohort.
- Bring the ledger in as the second, independent signal. Premium sinks fell while pass_tier faucets rose, so granted currency was banked rather than spent. Report the sink-to-faucet ratio per currency and the balance percentile curve, and exclude is_reversal rows and cs_grant so a correction cannot masquerade as a faucet.
- State the limit of the design out loud before the owner does. There was no holdout, and a matched window still aliases the release calendar. Say which part of your conclusion is robust to that and which is not.
- Close on a decision and a fix: run the next instance with a region-clustered holdout or a staggered start, so the argument is settled by design rather than by seniority.
Follow-up
- The event owner says the banked currency will be spent next month, so the sink drop is timing too. How would you test that claim rather than argue about it?
- If you could add exactly one instrumentation change before the next event, what would it be and what question does it close?
- What would you have said if the net number had been up 3% with an interval spanning zero?
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?
- 01
Describe a situation where you had to persuade a team to adopt your analysis or recommendation.
- 02
A two-week live-ops event closed with gross bookings up 18% against the prior week. Your readout says it added no net revenue: summed price_usd_net in fct_iap_transaction over the 28 days spanning the event is flat against a matched window one release cycle earlier, and fct_currency_ledger shows premium-currency sinks falling while faucets from source_system = 'pass_tier' rose. The event owner disputes the readout in a review with their director present. Give the argument you would make in that room, and name the one piece of evidence you would concede.
- 03
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.
Is this an official Scopely interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Scopely. Rounds and questions reflect what candidates have reported, not a process Scopely has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What is the typical interview difficulty for this role?
The interview process for the Data Scientist role at Scopely is considered rigorous but fair. Candidates should prepare thoroughly, as both technical proficiency and cultural fit are evaluated.
PracHub interview research ↗How long does the interview process usually take?
The timeline from application to offer can vary, but candidates often complete the entire process within a few weeks. Communication is typically prompt, so stay proactive in following up.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates often demonstrate not only strong technical skills but also the ability to communicate insights effectively and collaborate across teams. Cultural fit with Scopely's values is equally important.
PracHub interview research ↗Is remote work an option for this position?
Scopely offers flexible working arrangements, including remote and hybrid options, depending on team needs and candidates' preferences.
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.
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.
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.
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.