At Unity, a Data Scientist occupies a highly strategic and impactful position. Unity is not just a game engine; it is a massive ecosystem powering real-time 3D experiences, global monetization networks, and complex user acquisition pipelines. Data Scientists here do not work in isolation. Instead, they are embedded directly into product, engineering, and business teams to solve high-stakes problems involving massive datasets generated by billions of active devices worldwide.
The work you do as a Data Scientist at Unity directly influences the company's core business model. For instance, the monetization and advertising teams rely heavily on machine learning models to predict user conversion, optimize ad delivery, and maximize player lifetime value (LTV). Because of this scale, even a fraction of a percent improvement in model accuracy or conversion rate translates into significant business growth and improved user experiences globally.
To succeed in this role, you must possess a unique blend of deep technical expertise, product intuition, and outstanding communication skills. You will be expected to translate highly ambiguous business problems into structured machine learning pipelines, write production-grade code, and clearly explain your modeling choices to both technical peers and cross-functional stakeholders.
Initial Recruiter Screen
reportedWhoever runs this call is usually not a practitioner. They take notes, and a hiring manager skims those notes later, so the real question is whether your work survives being written down by someone outside the field. Test every project sentence against that: could a non-specialist repeat it correctly without knowing what a propensity score is? Carry a plain-language version of each project and one reason you want this particular role that you could not copy onto another application. Vagueness at this stage reads as inexperience, even when the underlying work was genuinely deep.
What to demonstrate
- Whether a non-specialist can restate your projects accurately, since their paraphrase is what reaches the hiring manager
- Whether your reason for wanting the role points at the work itself rather than the company's reputation
- Whether your language signals the level being screened for: what you decided yourself versus what you were handed
How to prepare
- Write a two-sentence, jargon-free version of each major project: the question nobody could answer, and the decision your work changed. Read it to someone outside data and have them repeat it back
- Point your 'why this role' answer at something concrete in the job description or the product surface you would be working on, and keep it to two sentences
- Have two questions ready about measurement: which metric the team is held to, and who acts on an analysis once it lands
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
Online Coding Assessment
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
Take-Home Technical Task
reportedA take-home is graded as an argument, not as a notebook. Somebody reads the submission without you in the room, so every choice has to survive on the page: why the question was framed this way, and what was deliberately left out. The gap between a strong and a weak submission is almost never model quality. It is whether the writeup names the specific question it answers and commits to a recommendation, including what evidence would overturn it. A high-accuracy model attached to no conclusion reads as effort that stopped before the decision.
What to demonstrate
- Whether the question you answered is stated outright, and whether it is the question the prompt posed rather than an easier neighbour of it
- Whether the recommendation is specific enough to act on, with the uncertainty attached to it instead of parked in a caveats section at the end
- Whether analytical choices such as the metric definition, the population filter and the time window are justified in the prose, not merely visible in code
How to prepare
- Take a dataset you have already worked with, write the one-paragraph conclusion first, then check whether the analysis you were planning actually supports it and cut whatever does not
- Practise stating a metric in one sentence that fixes the population, the time window and the denominator, then confirm your query computes exactly that sentence and nothing adjacent to it
- Hand a draft to someone outside the problem and ask them to tell you back what you recommended and why; anything they cannot recover is not on the page yet
Onsite / Final Interview Loop
reportedWhere a loop ends with a senior leader, that conversation is rarely another skills test. The technical signal already exists by then, so the questions tend to open up: what you would look at first, where a metric you have heard about could mislead, what you would push back on. The decision being made is scope, which in practice means level and how much you would be trusted to own unsupervised. Treating it as a formality is the usual mistake. An open question late in the day is still being scored, and a vague answer reads as someone who has not run anything themselves.
What to demonstrate
- Whether your view of the business has anything specific behind it, given that you are working only from what is public and are expected to say so
- Whether the scope of work you describe owning matches the scope of the role, instead of sitting a level below it
- Whether you can disagree with something concrete and stay useful about it, rather than agreeing with everything said in the room
- Whether your questions are ones only this person could answer, as opposed to ones the recruiter already covered
How to prepare
- Build one view you could defend for two minutes using only public information: what the funnel probably looks like, which metric likely drives decisions, and where that metric could mislead. Being wrong for a stated reason survives this round; having no view does not
- Write down the largest piece of work you have owned from question to decision, who else touched it, and what you decided alone, then check that it reads at the level you are interviewing for
- Prepare one thing you would want changed if you joined and phrase it as a question rather than a verdict, so it opens a conversation instead of closing one
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.
Reading experiment results before checking the arm split
Compare observed arm counts against the intended allocation ratio, not an assumed even split, and set the alarm far below the conventional 0.05: at 0.05 roughly one healthy experiment in twenty trips it, which is why sample-ratio checks usually run at p < 0.001 or stricter. The test's power scales with sample size, so it misses a real diversion on a small experiment and fires on an imbalance too small to move the estimate on a very large one. A flag means go find the assignment or logging fault before reading any outcome, not report a mismatch.
Accepting a metric definition without asking about the denominator
Pin down the denominator, the eligibility filter and the time window before computing anything: conversion rate per session, per user, per eligible user and per new user are four different numbers with different behaviour. Restate the definition in one sentence and get agreement before you analyse.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the difference between bagging and boosting, and when you woul…
Explain the difference between bagging and boosting, and when you would choose one over the other.
Approach
- Sanity-check the answer against a simple bound or a simulated case.
- Translate the result into the decision it informs, in one plain sentence.
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
Follow-up
- Which assumption here is most likely to be violated in practice?
- What sample size would you need to detect an effect half this size?
Describe a project where your initial model did not perform as expecte…
Describe a project where your initial model did not perform as expected. How did you diagnose the issue and pivot?
Approach
- 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.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
Follow-up
- Where could label leakage enter this setup?
- How would you choose the decision threshold, and who owns that choice?
How do you handle feature engineering for high-cardinality categorical…
How do you handle feature engineering for high-cardinality categorical variables in a conversion prediction model?
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.
- Check what information would not exist at prediction time, and exclude it.
Follow-up
- What would you monitor after launch to know the model is still valid?
- How would you choose the decision threshold, and who owns that choice?
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?
Why do you want to join Unity, and how does your background align with…
Why do you want to join Unity, and how does your background align with our monetization or engine platforms?
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 to find the daily active users (DAU) who completed a…
Write a SQL query to find the daily active users (DAU) who completed a specific sequence of actions within a mobile game.
Approach
- State the window function and its partition and ordering out loud before writing it.
- Say which table is the grain you start from, and join outward from it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
Given a large dataset of user sessions, how would you write a numpy sc…
Given a large dataset of user sessions, how would you write a numpy script to calculate the rolling average of conversion rates?
Approach
- 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.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
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?
What is your biggest weakness as a Data Scientist, and how are you act…
What is your biggest weakness as a Data Scientist, and how are you actively working to improve it?
Approach
- 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.
- 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?
- How would you detect that the metric is being gamed rather than genuinely improving?
How do you optimize a pandas pipeline that is running out of memory wh…
How do you optimize a pandas pipeline that is running out of memory when processing large-scale event logs?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- 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?
- What would you do if the primary metric and the guardrail moved in opposite directions?
Size an activation test on install-to-first-match conversion
Install-to-first-match conversion at 24 hours currently runs at 62.0%: players in the daily install cohort with a fct_match_participant row where started_at < install_ts + 24h and result <> 'abandon', over all non-test installs in that cohort. A tutorial change is expected to add roughly 1.5 percentage points. You receive 9,000 non-test installs a day, bucketed 50/50 at install time, with no interaction between players. At alpha 0.05 two-sided and 80% power, give the per-arm sample size and the calendar time needed, and say what you would do if that runtime is refused.
Approach
- Confirm the unit first. One install is one independent observation here because nothing about a tutorial change reaches another player, so a two-proportion calculation is valid. That check is what separates this from a matchmaking or economy change, where it would not be.
- Apply the two-proportion formula with n per arm = (z_{1-alpha/2} + z_{1-beta})^2 * [p1(1-p1) + p2(1-p2)] / delta^2. With z_{0.975} + z_{0.80} = 1.960 + 0.842 = 2.802, the squared term is 7.849; p1(1-p1) = 0.2356, p2(1-p2) = 0.2318, delta^2 = 0.000225.
- Convert to calendar time: 4,500 installs per arm per day gives 3.6 days of intake, and because the metric is only evaluated once the cohort is 24 hours old, the last cohort needs another day. Five days is the floor.
- Round up to seven days for a reason you can state: a five-day window weights the estimate toward weekday install mix, so the effect you measure is conditional on that mix. Both arms are contemporaneous, so this is an estimand question, not an imbalance question.
- If five to seven days is refused, name the honest levers rather than fudging: raise the target effect, reduce variance by post-stratifying on install_platform and acquisition_channel, accept lower power and write the resulting MDE down in advance, or pick a lower-variance proxy. Reading the test daily at nominal 0.05 is not on the list.
Worked solution 15 min
- Set p1 = 0.620, p2 = 0.635, delta = 0.015, alpha = 0.05 two-sided, power = 0.80.
- Compute (1.960 + 0.842)^2 = 7.849 and p1(1-p1) + p2(1-p2) = 0.2356 + 0.2318 = 0.4674.
- Compute n per arm = 7.849 * 0.4674 / 0.000225 = 16,305, so 32,610 installs in total.
- Divide by 4,500 installs per arm per day to get 3.6 days of intake, add one day of cohort maturity, and recommend a seven-day run.
- State the MDE you would actually get from a three-day run, so the trade-off is explicit if runtime is cut.
Follow-up
- The team wants D7 retention from the same test. What happens to the runtime, and why is it not simply seven more days?
- Installs are 70% mobile. Would you power the mobile-only subgroup, and what would that cost in runtime?
- The observed effect lands at +1.4 points with p = 0.08. What do you report, and what would you have needed to decide beforehand to make that report credible?
Activation conversion fell overall but rose within every platform
Install-to-first-match conversion at 24 hours fell from 68.8% to 62.9% month over month, yet it rose about one point inside mobile and inside pc measured separately. Mobile share of installs went from 40% to 70%. Using dim_player (player_id, install_ts, install_platform, acquisition_channel, is_test_account) and fct_match_participant (player_id, started_at, result), quantify how much of the 5.9-point fall is mix and how much is within-segment, and state what you would tell the acquisition team.
Approach
- Recompute the metric exactly as defined before decomposing anything: numerator is players in the daily install cohort with a fct_match_participant row where started_at < install_ts + 24h and result <> 'abandon', denominator is all non-test installs in that cohort. Use a left join so non-activating installs stay in the denominator.
- Build the segment table: for each platform and each month, the install share and the conversion rate. Confirm the shares sum to one and that the share-weighted conversion reproduces the reported overall figure in both months, or the decomposition will attribute a data error to mix.
- Apply the standard two-term split. Mix effect is the sum over segments of (share_after minus share_before) times conversion_before. Within-segment effect is the sum over segments of share_after times (conversion_after minus conversion_before). The two terms add exactly to the overall change; say which ordering you used, because the alternative pairing splits the interaction term the other way.
- Find the driver of the share move by cutting installs by acquisition_channel within platform. A mix shift is a consequence, not a cause; the cause is usually one campaign or channel scaling.
- Check whether the within-mobile rise is itself a mix artefact one level down, by repeating the split on device_model tiers or install_country inside mobile. Mix effects nest.
- Deliver both numbers plus the counterfactual: what overall conversion would have been at last month's platform mix and this month's rates.
Follow-up
- The acquisition team argues the mobile installs are cheaper, so lower conversion is acceptable. What single number settles that argument, and what does it require you to wait for?
- Would you set the activation target per platform or blended, and what does each choice incentivise?
- How does your decomposition change if the campaign also shifted install_country, so platform and country moved together?
Four days spend equal time on query work, statistics, modelling and product judgement at deliberately shallow depth, which produces a scored map of where you actually stand. The last three days spend everything on the two areas the role weights most, and close by re-running day one to measure movement.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Breadth pass: query fluency
- Solve six prompts spanning aggregation, joins, window functions and date arithmetic in 60 minutes total, stopping at 10 minutes each whether or not it works, and mark every prompt as solved, solved slowly, or stuck.
- For each unsolved prompt write the single blocking sentence (I lost the grain, I did not know the frame clause, I could not express the date boundary) instead of reading the solution.
- Translate one pandas transformation you know well into SQL and one SQL query into pandas, checking that both return the same row count and the same totals.
Deliverable: A scored six-row table, one line per prompt, saved for the day-seven re-run.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Breadth pass: statistics and inference
- Answer ten short questions in writing with nothing open: what a p-value is conditional on, what a 95 percent interval covers across repeated samples, when a paired test is the right one, what the bootstrap estimates, why multiple comparisons inflate false positives, how controlling the family-wise error rate differs from controlling the false discovery rate, what power depends on, what a missed real effect costs a product, the three situations where the central limit theorem does not rescue you (small n, very heavy tails, dependent observations), and what a standard error is the standard deviation of.
- Grade yourself against a reference and count only the answers that were exactly right, not the ones that were nearly right.
- Rewrite the two weakest answers the following morning from memory in full sentences.
Deliverable: Ten graded answers with an honest count of exact hits.
Practice prompt ↗Practice prompt ↗03Breadth pass: modelling
- Take one tabular dataset end to end in 90 minutes: a leakage-safe split, a baseline that is not a model (majority class or historical mean), one regularized linear model, one gradient-boosted tree, and a single evaluation metric chosen before you look at any result.
- Write why that metric fits the cost structure: precision at a fixed recall for alerting, calibration for anything feeding a price or a threshold, ranking metrics for retrieval, and note that area under the ROC curve is insensitive to class balance in a way that can flatter a rare-positive problem.
- Name the leak you were most likely to introduce (an encoding fit on all rows before splitting, or a feature computed after the label's timestamp) and write the check that would have caught it.
Deliverable: A notebook whose first cell states the metric and the baseline, plus two lines on what beat what and by how much.
Practice prompt ↗Practice prompt ↗04Breadth pass: product judgement
- Answer three case prompts aloud at 15 minutes each, timing how long passes before you state a success metric.
- For one case write the first segmentation you would run and the row counts you expect per segment, so that a tiny segment cannot quietly drive the conclusion.
- Take a metric definition you did not write, from a public dashboard, a textbook, or documentation you already have open, and list every place two analysts implementing it would diverge: which rows the denominator admits, whether the unit is an account or a person, what the time window is anchored to, and what happens to data that arrives late. Then write the one question that would close the largest of those gaps.
Deliverable: Three recorded case answers plus an ambiguity list for a metric someone else defined, ending in the single question you would ask about it.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Depth, first area
- Rank the four areas by how many bullet points in the role description each one covers, pick the top one, and spend the entire day inside it.
- Work the six hardest problems you can find in that area and for each write the generalizable move you should have reached for first, rather than the answer.
- Re-solve the two you failed the same evening with notes closed.
Deliverable: Six generalizable moves written as instructions to yourself, not as solutions.
Practice prompt ↗Practice prompt ↗06Depth, second area, and the seam between them
- Repeat the depth protocol on the second-ranked area with the same six-problem structure.
- Construct one problem that requires both areas at once, for example a metric redefinition whose effect you must validate with a test whose readout you then have to query.
- Solve your own combined problem end to end and note where the handoff between the two areas cost you time.
Deliverable: One combined problem, solved end to end, with the handoff failure written down.
Practice prompt ↗Practice prompt ↗07Integration and re-measurement
- Re-run the six prompts from day one under the same clock and compare both correctness and time.
- Run a 60-minute mixed mock that moves between areas without warning, since switching cost is what breadth passes do not train.
- Write the two areas you would still fail on, and the sentence you will use in the interview when you hit one of them.
Deliverable: A before-and-after score table plus a written plan for the two remaining gaps.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Interviewers here are not checking whether you can describe a project. They want the decision you made, why you made it under the information you had, and what changed afterwards that someone else could measure. A story that ends at 'I built a model' has no ending. Say what the model caused, or what you stopped doing because of it.
Retract a shipped retention claim built on survivorship
Three months ago you published a memo showing that players who join a guild in their first week have 2.1x the D28 retention of those who do not. A feature team has since built a guild-invite prompt on the strength of it, shipping in nine days. You now see that guild status was measured at any point during the first week, among players who were still active at day 7, so the comparison conditions on the outcome it claims to explain. Write the retraction and describe the conversation you have with the feature lead first.
Approach
- Get the corrected number before you send anything. Re-anchor: restrict to players with at least one session in the day-7 elapsed-hour bracket, fix guild status as of that anchor timestamp, and measure D28 forward from it. The corrected effect is usually positive and much smaller, and 'smaller' is a very different memo from 'wrong'.
- Talk to the feature lead privately, first, with the corrected estimate in hand. A retraction that reaches them as a surprise in a group channel costs you the relationship you need for the next correction.
- Structure the memo in decision order: what the claim was, what was mechanically wrong in one plain sentence, what the corrected estimate and interval are, and what decision changes as a result.
- Keep 'the number was wrong' separate from 'the feature is wrong'. Selection bias means the estimate is uninterpretable, not that guilds do nothing. Propose the design that would actually answer it: randomise the invite prompt and measure from assignment, which also gives the team a readout they can defend.
- Offer the hazard framing as the durable fix. Model churn with guild membership as a time-varying covariate so joining is not allowed to predict the survival it required.
- Add one process change, such as an anchor-point check on any adoption-versus-retention claim, so the retraction buys something beyond an apology.
Follow-up
- The corrected lift is 1.3x with an interval of 1.05x to 1.6x. Does the feature still ship in nine days?
- How would you design the randomised version so the prompt itself, rather than guild membership, is what gets randomised?
- What would you have to see in the hazard curve for you to believe the mechanism is real rather than another selection artefact?
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?
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
Three months ago you published a memo showing that players who join a guild in their first week have 2.1x the D28 retention of those who do not. A feature team has since built a guild-invite prompt on the strength of it, shipping in nine days. You now see that guild status was measured at any point during the first week, among players who were still active at day 7, so the comparison conditions on the outcome it claims to explain. Write the retraction and describe the conversation you have with the feature lead first.
- 02
Three requests land in the same week and you have five working days. The economy team wants a sink-to-faucet audit per currency after a faucet change shipped ten days ago. Live-ops wants a readout on an event that ends Friday, because the next event is configured from it. Acquisition wants 90-day net revenue per install by channel for a budget meeting in three weeks, and two of the channels launched six weeks ago. All three owners have escalated. Give your allocation, the reasoning you give each owner, and what you refuse or defer.
- 03
A 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 Unity interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Unity. Rounds and questions reflect what candidates have reported, not a process Unity has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the Unity Data Scientist interview process?
A: Candidates generally rate the difficulty as average to difficult. The process is highly comprehensive, testing coding, machine learning theory, practical modeling (via the take-home), and product sense. Success requires balanced preparation across all these areas.
PracHub interview research ↗What is the most critical stage of the interview loop?
A: The take-home technical task and the subsequent presentation round are the most critical. This is where the team evaluates your actual coding standards, your modeling methodology, and your ability to communicate and defend your technical decisions under questioning.
PracHub interview research ↗How long does the entire hiring process take?
A: The process typically takes about four weeks from the initial recruiter screen to the final decision. Recruiters at Unity are known for being highly responsive and proactive, keeping you updated at every stage.
PracHub interview research ↗What is the working culture like for Data Scientists at Unity?
A: The culture is highly collaborative, transparent, and data-driven. Data Scientists work closely with engineering and product teams, meaning your work has high visibility and direct impact on the company's products and revenue.
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.
Ubisoft Data Scientist Interview Questions & Guide 2026
Take-home style practice for data scientists preparing for Ubisoft: a messy dataset, a fixed time budget, and a written analysis, reviewed for whether it states its assumptions and whether a reader could reproduce your numbers.
Scopely Data Scientist Interview Questions & Guide 2026
Timed practice for Scopely data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.
Skillz Data Scientist Interview Questions & Guide 2026
Experiment-design practice for Skillz data scientist candidates, covering randomisation units, power, minimum detectable effect and the traps that invalidate a result.