This guide covers what a Data Scientist at Playstation is expected to do and how to prepare for the interview.
Recruiter 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
Hiring Manager Interview
reportedExpect a live problem with pieces of it missing, closer to a conversation than an exam. A metric moved, or somebody wants to know whether a change worked, and you are asked how you would find out. The manager is watching the first ninety seconds, specifically whether you establish what decision hangs on the answer before you start proposing methods. Candidates who open with a technique get steered back. Once the decision is clear, describe what the data would look like if the story were true, and say what you would accept as evidence that it is not.
What to demonstrate
- Whether you fix the decision the analysis serves before choosing an approach
- How you continue when you are told the data you just asked for does not exist
- Whether you state what would change your mind, not only what would confirm the hypothesis you started with
- How you size an effect before you have measured it
How to prepare
- Take a metric you know well and practise explaining in under two minutes the four things that could have moved it and how you would separate them
- Pick a recent launch or experiment and write the single number you would ask for first, plus what you would conclude if it came back flat
- Practise being interrupted: have someone remove a data source halfway through your answer and carry on without restarting
Technical Deep Dive
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
Final Interviews
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.
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.
Reading economy health from average balances.
A faucet change can leave the mean balance flat while the top decile accumulates a stock it has no reason to spend and the median player stays starved, which is the state in which a premium shortcut stops selling. The diagnostic pair is the sink-to-faucet ratio per currency and the full balance percentile curve over time, not the mean. Ledger reversals and customer-service grants must be excluded from both sides or a single large correction will look like a genuine faucet.
Reaching for a model before the target metric exists
Before naming an algorithm, write down the label, the prediction time, and the action that changes when the score crosses a threshold. If you cannot say what decision the output drives, any modelling choice is guesswork dressed up as method.
Sizing estimates built on unnamed, unrevisable assumptions
Write each assumption as a named number you can change, then show the arithmetic so the interviewer can challenge one input instead of the whole answer. Finish by saying which assumption the result is most sensitive to, which matters more than the point estimate.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain how you would calculate confidence intervals for retention rat…
Explain how you would calculate confidence intervals for retention rates that naturally cluster by player cohorts.
Approach
- Write down the assumption the method needs before you use the method.
- Say what the estimate is of, and over what population it generalises.
- Sanity-check the answer against a simple bound or a simulated case.
Follow-up
- What sample size would you need to detect an effect half this size?
- Which assumption here is most likely to be violated in practice?
These questions examine your capability to build, evaluate, and interp…
These questions examine your capability to build, evaluate, and interpret predictive models within the gaming ecosystem.
Approach
- Say how the offline result would be validated online before it is trusted.
- Set a baseline first, so any model has something honest to beat.
- 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?
- Where could label leakage enter this setup?
Bootstrap an interval for net revenue per active player-day
You have player_window: one row per player active in a trailing 28-day window, with player_id, active_days (int, 1 to 28) and net_revenue_usd (float, refund-adjusted, zero for most rows). Net ARPDAU is sum(net_revenue_usd) divided by sum(active_days). Write a percentile bootstrap for a 95 percent interval with 10,000 replicates using numpy only, no library resampler. Choose the resampling unit and justify it. Also report the share of total net revenue held by the top 1 percent of players, and state what that share implies about the interval you just produced.
Approach
- The estimator is a ratio of two sums taken over players, so the resampling unit is the player. Resample player row indices with replacement and recompute sum(revenue) / sum(days) on the resampled set. Resampling transactions destroys the denominator outright; resampling player-days splits one player's spend across units and understates variance, because a player's active days and their spend are strongly correlated.
- Vectorise the replicates: draw idx = rng.integers(0, n, size=(B, n)) and compute rev[idx].sum(1) / days[idx].sum(1). At n in the hundreds of thousands that matrix will not fit, so chunk the replicates into blocks and accumulate; check the memory arithmetic before you run it rather than after.
- Take the interval as np.percentile(boot, [2.5, 97.5]) and report it beside the point estimate computed on the original sample, not the mean of the bootstrap draws. The bootstrap mean carries the resampling bias and is not your estimate.
- Compute the concentration diagnostic: sort net_revenue descending, sum the top ceil(0.01 * n) rows, divide by the total. A share above roughly half means a handful of accounts set the interval width on their own.
- State the consequence plainly. In that regime the percentile bootstrap undercovers, because no resample can contain a payer larger than the largest one you observed, so the right reading of your interval is as a lower bound on uncertainty. Pre-registered winsorisation, or splitting the metric into conversion and conditional spend, is how you get something you can actually power a test on.
Worked solution 30 min
- Extract revenue and days as contiguous numpy arrays and compute the point estimate as a plain ratio of sums.
- Draw bootstrap indices in chunks, computing the ratio per replicate and appending to a preallocated array of length 10,000.
- Take the 2.5th and 97.5th percentiles of the replicate array for the interval.
- Compute the top 1 percent revenue share by sorting descending and taking a cumulative sum, then write one sentence linking that share to the interval's trustworthiness.
Follow-up
- Your interval excludes zero, but one account contributed 8 percent of the window's revenue. What do you tell the person who wants to ship on that basis?
- How does the interval change if you winsorise at the 99th percentile first, and in which direction is the resulting bias?
- The last four days of the window held a limited-time event. Does the bootstrap do anything about that?
How would you write a query to identify churned users who haven't laun…
How would you write a query to identify churned users who haven't launched a game in 30 days, joining multiple player activity logs?
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Say which table is the grain you start from, and join outward from it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Follow-up
- How would you verify this result without re-running the same query?
- What breaks if events arrive late or out of order?
Write a SQL query using window functions to calculate the 7-day rollin…
Write a SQL query using window functions to calculate the 7-day rolling average of daily active users (DAU) for PlayStation®Plus subscribers.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Say which table is the grain you start from, and join outward from it.
- State the window function and its partition and ordering out loud before writing 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?
Report per-SKU net revenue alongside granted premium currency
fct_iap_transaction has transaction_id, player_id, sku_id, purchase_ts, price_usd_net, status. fct_currency_ledger has transaction_id (nullable), currency_code, delta_amount, source_system. A single completed purchase can produce several ledger rows with source_system = 'iap_grant': the base pack, a first-purchase bonus and an event bonus are separate entries. For last month's completed transactions, return per sku_id the transaction count, net USD revenue and total premium currency granted. Write it so the revenue figure is not inflated by the grant rows.
Approach
- State the grain of each side before writing any join. fct_iap_transaction is one row per transaction; the iap_grant rows are one-to-many against it. Joining them directly produces a result at grant grain, where any SUM of price_usd_net counts each purchase once per grant row.
- Pre-aggregate the ledger to transaction grain in a CTE: SUM(delta_amount) FILTER (WHERE currency_code = 'premium') grouped by transaction_id, restricted to source_system = 'iap_grant'. The CTE is now one row per transaction and the join becomes many-to-one.
- Left join that CTE onto the filtered transactions so a completed purchase that produced no grant row still appears with a NULL grant total. That combination is a fulfilment bug worth surfacing, not hiding behind an inner join.
- Filter transactions on status = 'completed' and purchase_ts inside last month. Because this table mutates in place, a transaction later refunded now carries status = 'refunded' and is already excluded; say that out loud rather than adding a redundant refund subtraction that would double-count the adjustment.
- Aggregate to sku_id and add a count of transactions with no matching grant, so the fulfilment gap is legible in the same output instead of needing a second query.
Worked solution 25 min
- Count transactions in the window, then count the iap_grant ledger rows referencing them. That ratio is how badly a naive join would inflate revenue.
- Write the grant CTE grouped by transaction_id and verify its row count is at most the transaction count.
- Join, filter on status and purchase_ts, and aggregate by sku_id.
- Cross-check total net revenue against a standalone SUM over fct_iap_transaction with the same filters and no join at all. The two must be identical.
Follow-up
- How would you prove the fan-out was really happening, using only row counts and no prior knowledge of the data?
- Last month's transactions have not finished refunding. At what cohort age would you publish this table, and what do you show a stakeholder in the meantime?
- A currency_pack SKU shows net revenue but zero granted premium currency. Walk me through the next three queries you run.
How do you handle missing values or duplicate session entries when agg…
How do you handle missing values or duplicate session entries when aggregating concurrent player engagement metrics in SQL?
Approach
- Fix the population and the time window before naming any metric.
- Name one primary metric, then the guardrail that stops it being gamed.
- 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?
How would you design a product metric framework to evaluate the overal…
How would you design a product metric framework to evaluate the overall health and engagement of the PlayStation®Plus subscription tiers?
Approach
- Fix the population and the time window before naming any metric.
- 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?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How do you prevent data leakage when cross-validating time-series mode…
How do you prevent data leakage when cross-validating time-series models used for user engagement forecasting?
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
- 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?
Imagine daily active users (DAU) dropped by 10% over the weekend; walk…
Imagine daily active users (DAU) dropped by 10% over the weekend; walk me through your step-by-step framework to diagnose this drop.
Approach
- 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.
- 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?
- Which segment would you cut first, and what would that rule out?
How does Bayesian A/B testing differ from frequentist approaches, and …
How does Bayesian A/B testing differ from frequentist approaches, and what are the trade-offs in a fast-paced product environment?
Approach
- State the primary metric and the minimum effect worth shipping, then size the test.
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Name the guardrails that would stop a launch even on a positive primary result.
Follow-up
- How would you handle interference between treated and control units?
- What would you conclude if the result is positive but the test is underpowered?
These questions evaluate your ability to design robust experiments and…
These questions evaluate your ability to design robust experiments and navigate real-world statistical limitations.
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
- How would you handle interference between treated and control units?
- What would you conclude if the result is positive but the test is underpowered?
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?
Recent install cohorts look richer than mature ones
Net revenue per install at cohort day 30 reads about 6% higher for install cohorts aged 30 to 45 days than for cohorts aged 120 days or more. Revenue is refund-adjusted using refunds recognised to date. Tables: dim_player (player_id, install_ts, acquisition_channel) and fct_iap_transaction (player_id, purchase_ts, price_usd_net, status, status_changed_at, refund_ts). Marketing wants to credit a creative refresh. Decompose the 6% and say what you would change about the chart.
Approach
- Separate the two clocks the chart conflates. Purchase accrual is capped at cohort day 30 by the metric definition, so it is the same for every cohort. Refund recognition is not capped: a refund lands weeks after its purchase, so a young cohort has observed only part of the refunds its day-30 purchases will eventually attract. The metric is therefore not comparable across cohort ages even though the accrual window is fixed.
- Measure the recognition curve from cohorts old enough to be complete. Using purchases at least 60 days old, compute the share of eventual 60-day refund and chargeback value that had been recognised by each day since purchase. That curve is the instrument for everything that follows.
- Apply the curve to size the bias. If r is the eventual share of net value refunded within 60 days and f is the share of that already recognised for a given cohort, measured net over matured net is (1 minus r times f) divided by (1 minus r). Compute f as a weighted average over the cohort's purchase-age distribution, not at the cohort's own age, because a cohort aged 40 days contains purchases from day 0 to day 30.
- Subtract the maturity term and decompose what is left by acquisition_channel using the standard mix and within-segment split, since a creative refresh usually moves channel mix as well as channel performance.
- Confirm nothing else changed in the pipeline over the comparison span: check store_channel availability, whether any price book or FX conversion changed, and whether platform_fee_usd rates moved, since all three alter price_usd_net without any player behaving differently.
- Fix the chart rather than the number: restrict it to cohorts that have passed a fixed maturity, or hold refunds at a fixed observation lag so every cohort is measured with the same refund window.
Follow-up
- How long must a cohort be to appear on this chart, and how do you answer the executive who wants a read on last week's cohort?
- Would you rather fix the maturity by dropping young cohorts or by using the recognition curve to project them, and what does each choice cost you?
- If the creative refresh genuinely raised revenue per install, how would that look different from what you found here?
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.
Tell me about a complex data science project where you had to balance …
Tell me about a complex data science project where you had to balance analytical rigor with tight product launch deadlines.
Approach
- Quantify the outcome, including what you would not claim credit for.
- Close with what you would do differently, concretely.
- 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 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?
Turn 'engagement is down' into a scoped answerable brief
A studio lead messages: engagement is down, can you look into it. You have dim_player, fct_session, fct_match_participant and the release calendar. Daily core-loop players, defined as distinct players per UTC day with at least one match reaching a terminal result other than abandon, is down 6% week over week, and a content release landed nine days ago. You have 30 minutes before a standup. Produce the scoping questions you would ask, the first three cuts you would run, and the one-paragraph brief you send back before doing deeper work.
Approach
- Pin the metric and the comparison before touching data. Ask which number the lead actually saw and over what window, because a week-over-week read nine days after a release is measuring post-release decay by construction, and that alone may be the whole answer.
- Ask the decision question, not more metric questions: what would the lead do differently if this turns out to be new players versus returning, one platform versus all, one region versus global. Scope follows the decision, and an investigation with no decision attached should be declined or deferred.
- Run three cheap cuts that split the space rather than confirm a hunch. First, new versus existing by install cohort age, which separates an activation problem from a retention problem. Second, platform crossed with app_version, where a bad build shows as a concentration of fct_session.ended_reason = 'crash' and truncated duration_seconds. Third, server_region, where an infrastructure incident shows as elevated match abandon rate and p95 matchmaking wait rather than as fewer app opens.
- Re-baseline against the matched day in the previous release cycle instead of against last week, so the comparison is not dominated by the release calendar.
- Send a brief that states what you confirmed, what you ruled out, the current best explanation with its confidence, and the size of the next block of work with the question it would close.
Follow-up
- The crash concentration is on one device_model at one app_version. What do you send, to whom, and how urgently?
- How would you tell a genuine drop apart from an instrumentation change that altered which sessions get logged?
- If all three cuts come back flat, what is your fourth cut and why that one?
- 01
Tell me about a complex data science project where you had to balance analytical rigor with tight product launch deadlines.
- 02
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.
- 03
A studio lead messages: engagement is down, can you look into it. You have dim_player, fct_session, fct_match_participant and the release calendar. Daily core-loop players, defined as distinct players per UTC day with at least one match reaching a terminal result other than abandon, is down 6% week over week, and a content release landed nine days ago. You have 30 minutes before a standup. Produce the scoping questions you would ask, the first three cuts you would run, and the one-paragraph brief you send back before doing deeper work.
Is this an official Playstation interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Playstation. Rounds and questions reflect what candidates have reported, not a process Playstation has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How technical are the data science interviews at PlayStation?
Interviews are rigorous and test both conceptual depth and practical execution. You should expect live coding in SQL and Python, deep dives into statistical theory, and rigorous case studies covering experimentation and causal inference.
PracHub interview research ↗How much weight is placed on domain knowledge in gaming?
While a passion for gaming and familiarity with digital entertainment ecosystems is a strong plus and helps contextualize product sense questions, core statistical rigor and problem-solving ability remain the primary evaluation drivers.
PracHub interview research ↗What is the typical interview timeline from initial screen to final decision?
The process typically spans several weeks, involving a recruiter screen, technical screening rounds, a deep-dive technical or case study panel, and final stakeholder interviews. Communication cadence can vary, so proactive follow-up with your recruiter is encouraged.
PracHub interview research ↗Are remote work options available for Data Scientist roles?
Many roles operate under a hybrid office and remote working model that blends flexibility with in-person collaboration for key team milestones, though specific arrangements depend on the hiring hub and team requirements.
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.
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.