The reported questions mix four kinds of material. The statistics and probability questions include the assumptions behind linear regression, which statistical methods you use and why, and a function that returns the mean and standard deviation of a list. The machine learning questions include supervised versus unsupervised learning and a case on predicting churn for a subscription service. Coding questions cover sorting large datasets, code performance and a word-anagram check. Case questions ask how you would find trends over time in a dataset and how you cleaned and prepared data on a past project.
The requirements candidates cite are statistical analysis, machine learning, Python or R, and a visualization tool such as Tableau or Matplotlib. Familiarity with Hadoop or Spark, a cloud platform such as AWS or Azure, and A/B testing and experimental design are listed as extras. Deep learning frameworks, natural language processing and big data tools such as Hadoop or Spark are also mentioned as topics that may come up, so know each at overview level. For preparation this means breadth with a defensible depth: state the assumptions behind each method you name, write short functions without autocomplete, and describe a model from problem definition to evaluation.
Candidates mention questions on a challenging project, on making an analysis understandable to non-technical stakeholders, and on resolving a conflict within a team, and they describe a round with several team members. The role is described as collaborative with engineering and product development, so every story you prepare should show the data work itself (what you checked, what you decided) and the people you had to bring along.
Use your own projects as the raw material. Several reported questions ask about your past work: a dataset you analysed, a project where you cleaned data, the statistical methods you reach for most. Build a short inventory of projects with the data, method, tool and a result number for each, and let the question decide which one you tell.
Phone Screening
reportedCandidates report a first call about your background and how it fits the role. The requirements candidates cite for the role are statistical analysis, machine learning, Python or R, and visualization tools such as Tableau or Matplotlib, so organise your summary around where you have used those. Lead with one or two projects rather than a list of employers, and be ready to talk about a dataset you have worked with, including what was awkward about it.
What to demonstrate
- How your experience maps to the skills candidates cite for the role: statistics, machine learning, Python or R, visualization
- Whether you can discuss a dataset you have worked with in concrete terms
- Fit with the role as it is described to you on the call
How to prepare
- Write a short pitch that names your strongest project, the data it used, the method you chose and the result
- List where Python or R, a visualization tool and a modelling method each appear in your work, with one example per item
- Prepare questions about the data the team works with and how the role collaborates with engineering and product development
Technical Interview
reportedCandidates report technical questions on data science skills. The reported questions across the loop fall into statistics and probability, general machine learning, coding fundamentals, and case-style problems such as predicting churn or finding trends in a dataset, and none of them is tied to a particular round. Use this stage to practise those types: write small functions by hand, state the assumptions behind every statistical method you name, and walk through a case from problem definition to metric to model.
What to demonstrate
- Statistical foundations: the assumptions behind a method and what you do when they fail
- Working code for a small data task in Python or R
- Machine learning basics and the choice of approach for a case
How to prepare
- Practice for the reported statistics questions: write the linear regression assumptions from memory, each with the diagnostic that checks it and the remedy when it fails
- Practice for the reported coding questions: code the mean and standard deviation function, covering empty input, a single value and the sample versus population divisor
- Practice for the reported case questions: outline the churn case end to end, with label definition, features as of a snapshot date, a time-based split, a baseline and the metric
- Practice for the sorting and anagram questions: explain how you would sort a dataset larger than memory, and how you would test a word-anagram check
Behavioral Interview
reportedCandidates report a conversation about your earlier work and how it connects to company values. Reports do not say what those values are, so do not guess; prepare stories that show your own decisions, the data work and the people involved. Behavioral questions candidates report include a challenging project, making analysis understandable to non-technical stakeholders, and a conflict within a team, so have a story ready for each. Keep the same facts and numbers every time you tell a story, because later rounds involve more people.
What to demonstrate
- Your account of past projects, in your own role and decisions
- How you communicate analysis to people outside data science
- How you describe working through disagreement with colleagues
How to prepare
- Write the challenging-project story as situation, your decisions, trade-offs, result with a number, and what you would change
- Prepare one conflict story in which you resolved the disagreement with evidence rather than escalation
- Practise explaining one model or test result in two sentences for a stakeholder who has never seen a confidence interval
Team Interactions
reportedCandidates report meeting several members of the team, with collaboration and fit as the reported aim. Reports do not give the format, so ask the recruiter who you will meet and whether to expect a discussion, a technical exercise or a presentation. Because the role is described as working with engineering and product development, prepare examples of working with people outside your own function.
What to demonstrate
- How you work with several team members at once
- Examples of working with colleagues outside your own function
- Fit with the team, which candidates report as the aim of this round
How to prepare
- Re-read the numbers and scope in each project story so a second telling matches the first
- Prepare a cross-functional example: what an engineer or product partner needed, and how you adjusted your analysis
- Bring questions for the team about the data they work with and how analysis gets used after you deliver it
PracHub editorial advice for the preparation topics above.
Listing the linear regression assumptions as four words with no consequence attached.
For each assumption (linearity in the parameters, independent errors, constant error variance, no perfect multicollinearity, errors unrelated to the predictors, and normal errors for small-sample inference) state what breaks, how you check it (residuals against fitted values, a Q-Q plot, Breusch-Pagan, Durbin-Watson, variance inflation factors) and the remedy (transform, robust standard errors, drop or regularise).
Describing a churn model without a precise label, a snapshot date or a time-based split.
Define churn first (cancellation or non-renewal, and any grace period), choose the prediction date and the horizon, build features only from data available at that date, and split by time. Say which metric fits the retention action: precision and recall at the number of customers the team can contact, or PR-AUC, because accuracy is useless when churners are rare.
Answering the mean and standard deviation function with a one-liner that ignores edge cases.
Decide whether the standard deviation is the sample (n minus 1) or population (n) version and say so. Handle an empty list and a single value, and mention a one-pass update such as Welford's algorithm, since the sum-of-squares shortcut loses precision when values are large and close together.
Answering the sorting question with "use quicksort" and nothing about data that does not fit in memory.
Name the in-memory choice and its properties (O(n log n), stable sorts such as Timsort, behaviour on nearly sorted input), then the external version: sort chunks that fit in memory, write the runs to disk and merge them with a k-way heap merge. For a cluster, describe sampling to choose range partitions, shuffling, and sorting each partition locally.
Telling project stories that end at "I built a model", or where the data cleaning had no checks.
End every story with a result, a number and what changed afterwards. For the data preparation story, list the checks you ran (duplicates, missing values, ranges, join row counts), the rule you chose for each problem and what it did to the final numbers.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Write a function to compute the mean and standard deviation of a list …
Write a function to compute the mean and standard deviation of a list of numbers.
Approach
- Clarify the contract out loud: population standard deviation divides by n, sample standard deviation by n-1 (Bessel's correction); an empty list should raise an error, and a sample standard deviation of a single value is undefined.
- Write a single-pass version with Welford's algorithm: for each x, n += 1; delta = x - mean; mean += delta / n; M2 += delta * (x - mean). Then variance = M2 / (n - 1) or M2 / n, and std = sqrt(variance). O(n) time, O(1) extra space.
- Explain why not the shortcut sum(x^2)/n - mean^2: subtracting two large, nearly equal numbers causes catastrophic cancellation and can even return a small negative variance in floating point.
- Test with a known case: [2, 4, 4, 4, 5, 5, 7, 9] has mean 5 and population standard deviation 2; also test a constant list (std 0), one element, and handling of NaN or non-numeric input.
- Know the library defaults so results line up: Python's statistics.stdev is the sample version and pstdev the population one; numpy.std defaults to ddof=0, while pandas Series.std defaults to ddof=1.
Follow-up
- How would you combine the mean and variance computed on two separate partitions without rereading the data?
- How would you change the function to support weights?
- The data is heavily right-skewed. What would you report alongside or instead of the mean and standard deviation?
Describe an efficient algorithm for sorting large datasets.
Describe an efficient algorithm for sorting large datasets.
Approach
- Start from whether the data fits in memory. In memory, use a comparison sort: Timsort (Python's sorted, stable, close to O(n) on already sorted runs) or merge sort (stable, O(n log n) worst case, O(n) extra space). Plain quicksort averages O(n log n) but its worst case is O(n^2); randomized pivots give an expected O(n log n) on any input, and only an introsort fallback (or median-of-medians pivots) guarantees the worst case.
- For integer or fixed-width keys, a non-comparison sort such as radix sort runs in O(n*k) for k-digit keys and can beat O(n log n) on very large inputs.
- For data larger than memory, describe external merge sort: read chunks that fit in memory, sort each and write it as a sorted run, then k-way merge the runs with a min-heap, O(N log k) for the merge, streaming output to disk.
- In a distributed engine such as Spark, a global orderBy samples keys to build range partitions, shuffles rows to them and sorts within each partition; skewed keys create oversized partitions, which is the usual bottleneck.
- Question whether a full sort is needed at all: top-k needs only a size-k heap, O(n log k); grouping needs hashing, not ordering; repeated range queries are better served by an index or a pre-sorted columnar file.
Follow-up
- Which of these algorithms are stable, and when does stability matter for a data task?
- How would you find the 100 largest values in a billion-row file with limited memory?
- One sort key value accounts for 30 percent of the rows. What happens to a distributed sort, and how would you handle it?
What are the assumptions of a linear regression model?
What are the assumptions of a linear regression model?
Approach
- List the assumptions precisely: linearity in the parameters, errors with zero mean given the features (exogeneity), independent errors, constant error variance (homoscedasticity), no perfect multicollinearity, and normally distributed errors.
- Say what each one buys: under the Gauss-Markov conditions (linearity, full rank, exogeneity, homoscedastic and uncorrelated errors) OLS is the best linear unbiased estimator; normality is not needed for that and matters mainly for exact small-sample t and F inference.
- Separate bias from bad standard errors: omitted variables or other endogeneity bias the coefficients, while heteroscedasticity and autocorrelation leave coefficients unbiased but make the usual standard errors wrong.
- Give the diagnostics: residuals versus fitted values for nonlinearity and fanning, a Q-Q plot of residuals, Breusch-Pagan for heteroscedasticity, Durbin-Watson for autocorrelation in ordered data, and variance inflation factors for multicollinearity.
- Name the remedies: transform variables or add polynomial and interaction terms, use robust (HC) or clustered standard errors, drop or combine collinear features or use ridge regression, and address endogeneity with better controls or an instrument.
Follow-up
- Does the target variable itself need to be normally distributed?
- Two features are highly correlated. What happens to the coefficients and to the predictions?
- Your residuals fan out as fitted values grow. What do you change, and does it alter the coefficient estimates?
Sessionise playback heartbeats into streams under an idle-gap rule
heartbeats has profile_id, device_id, content_version_id, heartbeat_ts, playhead_seconds, is_paused and reported_at; clients emit one every 30 seconds while in the foreground. Collapse it into stream rows keyed on (profile_id, device_id, content_version_id) under a 300-second idle gap. Emit started_at, ended_at, max_position_seconds and played_seconds, where played_seconds counts advancing playback only and so excludes pause, seek and rebuffer time. Flag streams whose reported_at trails heartbeat_ts by more than an hour. Then re-run at a 60-second gap and report what moved.
Approach
- Sort by the key and heartbeat_ts, take the per-row time delta inside the key with groupby().diff(), mark a new stream where that delta is null or above 300 seconds, and cumulative-sum the flag into a stream ordinal. This is gaps-and-islands, and it is O(n log n) after the sort with no per-group Python loop.
- Compute played_seconds from consecutive heartbeats as min(max(playhead_delta, 0), wall_delta), summed inside the stream. The lower clamp discards a backward seek; the upper clamp is what stops a forward seek to the end of a forty-minute episode from crediting forty minutes of playback to one thirty-second interval. Note what this makes the column mean: a rewind and replay inside one stream counts the replayed interval twice, because played_seconds measures time spent advancing the playhead, not distinct coverage of the item.
- Accept that the first heartbeat of each stream has no predecessor and contributes nothing, which undercounts by up to one heartbeat interval per stream. Quantify that bias as stream count times 30 seconds against the total instead of leaving it unsaid.
- Take ended_at as the last heartbeat_ts, but keep it null when that heartbeat sits within one idle gap of the data cutoff: such a stream may still be running, and giving it an ended_at manufactures a completed stream.
- For the offline flag, work on reported_at minus heartbeat_ts rather than on event_date, and report the distinct dates the flagged streams belong to, because that list is the recompute list.
- Re-run at 60 seconds and report both the stream count and the change in total played_seconds: the count can only rise, and the total falls by exactly the contributions that now straddle a split.
Worked solution 40 min
- Sort by (profile_id, device_id, content_version_id, heartbeat_ts); compute wall_delta as the grouped heartbeat_ts diff in seconds and pos_delta as the grouped playhead_seconds diff.
- new_stream = wall_delta.isna() OR wall_delta above 300; stream_ordinal = new_stream grouped-cumsum; group on the key plus stream_ordinal from here on.
- contrib = np.minimum(np.maximum(pos_delta, 0), wall_delta), forced to 0 on the first row of each stream; played_seconds is contrib summed per stream.
- Aggregate started_at as min(heartbeat_ts), ended_at as max(heartbeat_ts), max_position_seconds as max(playhead_seconds), and late_offline as max(reported_at minus heartbeat_ts) above 3600 seconds.
- Null ended_at where it falls within 300 seconds of the data cutoff.
- Re-run with the gap as a parameter at 60 seconds, and diff the two summaries on stream count and total played_seconds.
Follow-up
- A client dies mid-playback and stops reporting. What does its stream look like under this rule, and what does that do to mean stream duration?
- Which of these numbers determines a per-stream payout, and what does moving the idle gap do to somebody's money?
- The same profile plays the same track on a phone and a TV at once. Your key separates them. When would you want it not to?
Net revenue per active account-month without fanning out periods
fct_subscription_period has account_id, period_start_ts, period_end_ts, net_amount_usd and payment_status. fct_stream has account_id, started_at, played_seconds and is_qualified. Compute net revenue per active account-month for March 2026: the numerator is subscription revenue over periods with payment_status in ('paid','retried_paid'), recognised pro rata by the days of each period falling inside March; the denominator is distinct accounts with at least one qualified stream in March. A colleague's draft joins the two tables on account_id, filters streams to qualified March rows, and sums net_amount_usd; its numerator is roughly forty times too large. Explain the factor and write the correct query.
Approach
- Name the mechanism and decompose the number. The join is one period to many streams, so each period row is duplicated once per matching stream and its net_amount_usd is added that many times: the naive sum equals the un-prorated period sum weighted by each account's March qualified-stream count, which is the net_amount_usd-weighted mean stream count over the accounts the inner join keeps. The distance from there to the correct numerator has two further parts, in opposite directions — pro-rating shrinks the correct figure, while the inner join has dropped every period belonging to an account that streamed nothing in March. A weighted mean near thirty streams against a pro-rata factor near 0.75 is what puts the draft around forty times high; the number is not arbitrary, which is why it looks plausible enough to ship.
- Adopt the rule that produces the fix: two fact tables never meet at row grain. Aggregate each to account grain first and join the aggregates, or — better here — do not join at all, because the numerator and the denominator are independent scalars that share no key.
- State the interval convention before writing the arithmetic. Treating periods as half-open [period_start_ts, period_end_ts) makes consecutive periods tile without overlap; overlap_days = GREATEST(0, LEAST(period_end_ts, DATE '2026-04-01') - GREATEST(period_start_ts, DATE '2026-03-01')) in days, and the contribution is net_amount_usd * overlap_days / total_days_of_period. An annual period contributes roughly 31/365 of its amount.
- Build the denominator on its own: COUNT(DISTINCT account_id) FROM fct_stream WHERE is_qualified AND started_at >= '2026-03-01' AND started_at < '2026-04-01'. Do not restrict it to paying accounts — the metric deliberately holds subscription and advertising revenue to one engaged-account denominator, and filtering to payers is what makes a tier migration look like two unrelated numbers moving.
- State the closing rule with the result: the month must be at least 45 days closed, because refunds and chargebacks are recorded against periods late and an open month always reads high.
Follow-up
- One account holds two overlapping periods after a plan migration. Whose revenue counts for March, and does your pro-rata still sum to each period's own total?
- Advertising revenue belongs in this numerator. What grain does it arrive at, and what breaks in your query when you add it?
- How would you turn this into a monthly time series without rewriting the date literals, and what would you do about periods that span three months?
Sessionise playback into listening sessions with an idle gap
fct_stream has profile_id, stream_id, content_version_id, started_at, ended_at (nullable when the client stopped reporting) and played_seconds. Collapse consecutive streams by the same profile into listening sessions: a new session begins when a stream starts more than 30 minutes after the latest end reached by any of that profile's earlier streams. One profile can play on two devices at once, so streams overlap and 'the previous stream' is not well defined — the idle gap is measured against the running maximum end, not against the row immediately before. Treat a NULL ended_at as started_at plus played_seconds. Return one row per session with profile_id, session_start, session_end, stream_count, distinct content_version_id count and total played_seconds. Use window functions; a self-join on fct_stream is not an acceptable answer.
Approach
- In a first CTE compute effective_end = COALESCE(ended_at, started_at + played_seconds * INTERVAL '1 second'). This both fills the abandoned-client case and bounds it, since played_seconds is advancing playback only and cannot run past the true end.
- Take prev_max_end = MAX(effective_end) OVER (PARTITION BY profile_id ORDER BY started_at, stream_id ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING), and flag is_new_session = (prev_max_end IS NULL OR started_at > prev_max_end + INTERVAL '30 minutes'). LAG(effective_end) is the reflex here and it is wrong under concurrent devices: with A 10:00-12:00, B 10:05-10:10 and C starting 10:45, LAG hands C the end of B at 10:10, so C opens a new session 35 minutes into a session still running until 12:00. The NULL branch is not defensive noise either: the first row of every profile has no preceding frame and would otherwise fall outside any session.
- Number the sessions with SUM(is_new_session::int) OVER (PARTITION BY profile_id ORDER BY started_at, stream_id ROWS UNBOUNDED PRECEDING). A running count of boundaries is the gaps-and-islands device. Specify ROWS rather than letting the default RANGE frame apply, because RANGE lumps peer rows that share a started_at into one frame position — the same reason the ORDER BY carries stream_id as a tie-break.
- Group by (profile_id, session_number) and aggregate: MIN(started_at), MAX(effective_end), COUNT(*), COUNT(DISTINCT content_version_id), SUM(played_seconds).
- The running maximum makes the sessions disjoint in wall-clock time, but it does not make SUM(played_seconds) an elapsed-time figure: two devices playing at once contribute overlapping seconds, so the total can exceed session_end minus session_start. Report it as consumption and say which of the two the requester asked for.
Worked solution 30 min
- Materialise the effective_end CTE and check for rows where effective_end < started_at, which means negative played_seconds or a clock-skewed ended_at and must be quarantined before anything else.
- Add the running MAX and the boundary flag; verify that exactly one row per profile has prev_max_end IS NULL and that it is flagged as a session start.
- Add the running SUM to number sessions; confirm the numbers are dense and begin at 1 within each profile.
- Aggregate and reconcile: SUM(stream_count) across all sessions must equal the input row count.
- Run the overlap fixture — one profile with A 10:00-12:00, B 10:05-10:10 and C at 10:45 — and confirm it collapses to one session. With LAG(effective_end) in place of the running MAX it splits into two, and the second session's start, 10:45, sits inside the first session's span.
Follow-up
- Two devices on one profile play simultaneously. Is that one session or two, and what changes in the query for each answer?
- Re-run at a 10-minute and a 60-minute idle gap. How far does session count move, and which number do you publish and defend?
- Can SUM(played_seconds) for a session ever exceed session_end minus session_start, and what does it mean when it does?
Given a dataset, how would you identify trends over time?
Given a dataset, how would you identify trends over time?
Approach
- Pin the grain and the clock first: one row per entity per period, a fixed timezone, and a complete calendar (fill missing periods with explicit zeros or NaN) so gaps do not read as drops.
- Separate trend from seasonality before calling anything a trend: compare year over year or week over week at the same weekday, or decompose with STL (seasonal-trend decomposition using Loess) into trend, seasonal and residual parts.
- Smooth with a rolling mean or median and state whether the window is trailing or centred; a trailing window lags turning points by about half its length, while a centred one cannot be computed for the most recent periods.
- Test the trend rather than eyeballing it: a Mann-Kendall test for a monotonic trend, or a regression on time with Newey-West (HAC) standard errors, because autocorrelated residuals make plain OLS standard errors too small.
- Check that the trend is not composition or definition change: split by segment to rule out a mix shift (Simpson's paradox), and line up breaks against logging releases or metric-definition changes with a changepoint method.
Follow-up
- How would you tell a genuine level shift from an instrumentation change that happened on the same date?
- The aggregate is flat but every segment is rising. What explains that, and which number do you report?
- How would you extend this into a forecast, and how would you validate it without leaking future data?
How would you approach predicting customer churn for a subscription se…
How would you approach predicting customer churn for a subscription service?
Approach
- Define the label before any model: for a subscription, churn is usually cancellation or non-renewal within a fixed horizon after a prediction date, and voluntary churn should be separated from involuntary churn caused by failed payments.
- Build features as of the prediction date only: tenure, plan, usage level and its recent trend, billing failures, support contacts. Exclude anything recorded after that date, such as visits to the cancellation flow, to avoid leakage.
- Split by time (train on earlier snapshots, test on later ones), start with a logistic regression baseline, then try gradient-boosted trees and keep the gain only if it holds on the later period.
- Choose metrics for an imbalanced, action-driven target: PR-AUC, recall or lift in the top decile that the retention team can actually contact, and calibration if scores feed an expected-value calculation.
- Say what the score is for: a high churn risk does not mean an offer will change the outcome, so targeting is better served by an uplift model or a randomized retention test; survival analysis (Cox model) handles time-to-churn with censored active users.
Follow-up
- How would you decide which customers receive a retention offer, and how would you measure whether the offer worked?
- How do you handle customers who joined recently and have not yet reached the end of the horizon?
- After a price change, model precision drops. What do you check first?
Describe a project where you had to clean and prep data for analysis.
Describe a project where you had to clean and prep data for analysis.
Approach
- Open with the decision the analysis supported and the raw state of the data: sources, row counts and the intended grain (one row per what), so the cleaning steps have a reason.
- Walk through profiling before fixing: null rates per column, duplicate keys at the intended grain, value ranges, inconsistent units or currencies, timezone mismatches, and join keys that failed to match.
- For each issue, give the rule and its justification: deduplicate on a stated key with a stated tie-break, decide drop versus impute based on whether missingness looks random or tied to the outcome, and separate data-entry errors from genuine extremes before treating outliers.
- Make it reproducible and checkable: scripted steps instead of manual edits, assertions on row counts and key uniqueness after every join, and a log of how many rows each rule changed.
- Close with impact in numbers: how much the headline result moved between the raw and cleaned data, and the one check you would run earlier next time.
Follow-up
- How did you confirm that dropping or imputing rows did not bias the result?
- Which of these checks did you automate for the next data refresh, and where do they run?
- What would you have done if the source owner disagreed with your fix?
How do you optimize your code for performance?
How do you optimize your code for performance?
Approach
- Measure before changing anything: time the full job, then profile with cProfile or line_profiler (or Rprof / profvis in R) to find the few lines that dominate runtime.
- Fix the algorithm first: replace a nested-loop match, O(n*m), with a dict or set lookup or a join, O(n+m) expected; replace repeated list membership tests with a set; sort once instead of inside a loop.
- Vectorize data work: NumPy or pandas column operations instead of iterrows or apply with axis=1, which call Python code once per row; in R, vectorized functions or data.table instead of growing objects in a loop.
- Cut memory and I/O: read only needed columns, set compact dtypes (category for low-cardinality strings, downcast numerics), use a columnar format such as Parquet, and push filters and aggregations into SQL so less data reaches Python.
- Scale out only when one machine is not enough: multiprocessing for CPU-bound Python (threads in standard CPython are limited by the GIL), or Spark for data larger than memory. After every change, compare with the original output: exact equality for integer and key columns, a stated tolerance (np.allclose, or pandas.testing.assert_frame_equal with rtol) for floats, since vectorized sums reorder additions.
Follow-up
- When would you decide a slow piece of code is not worth optimizing?
- How would you process a file that does not fit in memory on your laptop?
- Your vectorized version is faster but returns slightly different numbers. How do you investigate?
What statistical methods do you frequently use, and why?
What statistical methods do you frequently use, and why?
Approach
- Pick three or four methods you actually use and give each a trigger, not a list: Welch's t-test for comparing means with unequal variances, a two-proportion z-test or chi-square test for rates, and Mann-Whitney when you care whether one group tends to produce larger values (it tests stochastic ordering, not a difference in means or medians).
- For a mean comparison on heavily skewed data, use a bootstrap interval or Welch's test with a large n instead of Mann-Whitney. Include estimation, not only testing: confidence intervals around every reported difference, and the bootstrap for statistics without a simple formula such as medians, ratios or percentiles.
- Cover regression as the workhorse: linear or logistic regression to control for covariates and read effect sizes, with the assumption you check each time (residual plots, multicollinearity).
- For experiments, mention a power analysis before launch to set sample size, and a multiple-comparison correction (Bonferroni, or Benjamini-Hochberg for false discovery rate) when many metrics or segments are tested.
- Anchor each method in one project: the question, why that method fit the data, the assumption you verified, and the decision the result changed.
Follow-up
- When would you choose the bootstrap over a closed-form confidence interval?
- How would you explain a p-value of 0.03 to a non-technical stakeholder without misstating it?
- What inputs do you need to compute the sample size for an A/B test?
Define success before a startup-latency infrastructure change
An infrastructure change is expected to cut startup_latency_ms on tv_app playback. You must define success before the rollout. Available: fct_stream (startup_latency_ms, rebuffer_seconds, played_seconds, peak_bitrate_kbps, end_reason, start_source, device_type, cdn_pop, network_type). Propose one primary outcome metric, the latency statistic you will report and at which quantile, and two guardrails. State how you will stop a mix shift across device_type and cdn_pop from reading as an improvement, and name one way a latency win could be bought rather than earned.
Approach
- Separate the input from the outcome out loud: startup_latency_ms is the thing the change moves, but success is whether consumption improved, so the primary metric is qualified hours per active account-week on tv_app and latency is the mechanism metric that explains it.
- Choose the latency statistic for the shape of the distribution: startup latency is right-skewed with a long tail from cold caches and poor networks, so report p95 and p99 rather than a mean, because the mean moves with tail mass that a handful of streams contribute and the tail is where abandonment lives.
- Kill the mix effect by construction: compute the latency quantiles inside (device_type, cdn_pop, network_type) cells and aggregate with cell weights fixed from a pre-period, so that a rollout reaching wifi and well-provisioned points of presence first cannot show a win that is entirely composition.
- Guardrail one on how a latency win is bought: peak_bitrate_kbps and the rebuffer ratio, sum(rebuffer_seconds)/sum(played_seconds) with played_seconds = 0 rows excluded from both sides, because starting playback at a lower ladder rung lowers time to first frame and costs picture quality instead.
- Guardrail two on what the ratio hides: start-failure rate over streams with end_reason = 'playback_error' and played_seconds = 0, counted separately, since a point of presence that fails before first frame contributes to neither side of the rebuffer ratio and would otherwise report perfectly.
- State the exclusion: cut or exclude start_source = 'resume', because resumed playback starts from a warm buffer and a rollout that shifts the resume share moves pooled latency without any engineering change.
Worked solution 20 min
- Write the primary metric with numerator, denominator and window, restricted to device_type = 'smart_tv' and its streaming-stick equivalents, and state that it is the outcome the change is judged on.
- Specify the latency readout: p95 and p99 of startup_latency_ms computed within (device_type, cdn_pop, network_type) cells, aggregated with pre-period cell weights, reported daily against the same cells pre-rollout.
- Construct one numerical counterexample showing the mix trap: two points of presence with unchanged within-cell latency but a shift in traffic share between them, and compute that the pooled mean moves while every cell is flat.
- Write the two guardrails: peak_bitrate_kbps distribution plus rebuffer ratio with the played_seconds = 0 exclusion stated, and start-failure rate over end_reason = 'playback_error'.
- State the exclusion rule for start_source = 'resume' and the reason, and write the one-line ship rule combining primary and guardrails.
Follow-up
- p99 falls but the mean rises. What do you conclude, and which cut would you look at first?
- The change only reaches accounts on app versions above a floor. How does that change what your comparison can claim?
- How large a latency improvement would you need before you expect qualified hours to move at all, and how would you size that before running it?
Completion rate fell while every duration decile improved
Duration-normalised completion rate — qualified streams with completion_ratio >= 0.9 over qualified streams with non-null duration_seconds — fell from 0.41 to 0.36 across six weeks. Computed inside each (content_type, duration decile) cell, every cell is flat or up. Using fct_stream (completion_ratio, is_qualified, content_version_id, started_at, start_source) joined to dim_content_version (content_type, duration_seconds, catalogue_added_ts, parent_id), reconcile the two numbers and say which the content team should act on. Deliverable: a decomposition separating mix shift from within-cell change, with the size of each in completion-rate points.
Approach
- Name the mechanism before computing anything. completion_ratio is mechanically decreasing in duration_seconds, so the global rate is a duration-mix-weighted average of cell rates and moves whenever the weights move with every cell rate held fixed. That is not a paradox, it is the aggregation doing what it was always going to do.
- Run the two-term decomposition: total change equals sum over cells of (w_new - w_old) * r_old for mix, plus sum over cells of w_new * (r_new - r_old) for within. Those two terms are exhaustive — the sum telescopes back to the observed change exactly — because this arrangement already carries the whole weight-by-rate interaction inside the within term. There is no third quantity to add. State the convention anyway: the mirror arrangement, mix at r_new plus within at w_old, is equally exact and parks the interaction in mix instead, and the two attributions differ by exactly sum (w_new - w_old) * (r_new - r_old) whenever weights and rates moved together. Report in completion-rate points so the argument is about magnitudes rather than adjectives.
- Find which weights moved and why. Cell share of qualified streams by week, joined to catalogue_added_ts and parent_id, will usually name a season of long episodes, a podcast push, or a shift in content_type as the cause within one query.
- Distinguish a mix shift the product caused from one the calendar caused, by cutting the weight change by start_source. A ranker that began surfacing long-form is a product decision with a durable consequence; a release landing in the window reverses by itself, and the two warrant opposite responses.
- Answer what was actually asked. The within-cell term is the quality signal and it is flat to up, so the content team should not chase it. The headline needs the fixed reference-month weights the metric definition already specifies, and the unweighted version should come off the dashboard rather than be explained every six weeks.
Follow-up
- Fixed reference weights stop the mix moving the number, but a genuine, permanent shift toward long-form then never appears. How do you cover that gap?
- The deciles are cut from some population. What happens to the decomposition if the decile boundaries themselves move between the two periods?
The plan follows the reported question mix: statistics first, then modelling cases, trend analysis with charts, coding, data preparation, and finally the project and team stories. Reported questions and PracHub practice drills are attached to the days that exercise them.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Project inventory and the opening pitch
- List four projects with the dataset, the method, the tool (Python or R, plus any visualization tool) and one result number each
- Write a short opening pitch around your strongest project and rehearse it aloud
- Write the full challenging-project story: situation, your decisions, trade-offs, result and what you would change
Deliverable: A four-row project inventory, a written opening pitch, and the challenging-project story in full.
Practice prompt ↗Worked solution ↗02Statistics foundations
- Write the linear regression assumptions with the diagnostic and remedy for each
- Code the mean and standard deviation function twice, with the naive formula and with a one-pass update, and test both against NumPy with the divisor stated
- Write a one-page sheet on the statistical methods you actually use: when each applies, its assumption and the alternative when the assumption fails
Deliverable: An assumptions table, a tested function with edge cases, and a method sheet with five entries.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Churn case and machine learning basics
- Write the churn plan: churn definition, snapshot date, prediction horizon, features, time-based split, baseline and metric
- Build a logistic regression baseline and a gradient-boosted model on a public or synthetic dataset and compare PR-AUC and recall at a fixed contact budget
- Write a short explanation of supervised versus unsupervised learning, with one example of each from your own work
Deliverable: A one-page churn plan, a notebook comparing the two models, and the supervised versus unsupervised explanation.
Practice prompt ↗04Trends over time, charts and aggregates that mislead
- Take a time series, aggregate it weekly, decompose it into trend, seasonal and residual parts, and decide whether the trend is real
- Plot the decomposition in Matplotlib (or build the chart in Tableau), then write a two-sentence explanation of it for a non-technical stakeholder
- Write a short experiment design for an A/B test: metric, unit, sample size and what would make you stop
- Work the PracHub drills on a completion rate that fell while every duration decile improved, and on defining success before an infrastructure change
Deliverable: A decomposition notebook with its chart and stakeholder explanation, a one-page A/B test design and written solutions to the two drills.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗05Coding and performance
- Write an external merge sort sketch: sorted chunks to disk, then a k-way heap merge, and note how a Spark sort partitions data
- Implement the anagram check two ways (sorted comparison and a character count) and state the complexity of each
- Profile a slow pandas function, replace the loop with a vectorised version and record the speedup
- Solve the PracHub drill on grouping playback heartbeats into streams under an idle-gap rule
Deliverable: Working sort and anagram code, a before-and-after profile of the pandas function and the solved drill.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Data preparation and PracHub SQL drills
- Write up a data cleaning project as profiling checks, the rule chosen for each problem and the effect on final numbers
- Build a reusable cleaning function with assertions on row counts, duplicates and value ranges
- Solve the two PracHub SQL drills on account-month revenue and on grouping playback into sessions
Deliverable: A cleaning write-up with its checks, a tested cleaning function and two solved SQL drills.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Behavioral and team mock
- Prepare a team conflict story and an answer on making an analysis understandable to non-technical stakeholders
- Work the PracHub behavioral drills on announcing a definition change and on arbitrating competing requests
- Run a full mock, delivering your project story to a friend who interrupts, then compare numbers with your inventory for consistency
Deliverable: Two written stories, drill responses and a note listing any number or scope that changed between tellings.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Reported behavioral questions ask for a challenging project, a team conflict and how you make analysis understandable to non-technical stakeholders. The Data Scientist role is described as collaborative with engineering and product development, so each story should contain the analysis itself (what you checked, what you chose) and the people you worked with, and end with a result.
Describe a challenging project you worked on and how you managed it.
Describe a challenging project you worked on and how you managed it.
Approach
- Choose a project whose difficulty you can name in one sentence: an ambiguous question, data that did not match what stakeholders assumed, a scale limit, or two stakeholders wanting different things. "It was large" is not a difficulty. Open with the situation, your role and the decision that had to be made, in two or three sentences.
- Spend most of the answer on how you managed it: how you scoped, what you cut, the order of work (baseline first, refinements after), how you kept stakeholders informed, and one decision where you weighed two real options and picked one for a stated reason. Use "I" for your decisions and "the team" only for what was shared.
- Put the data science in the story: which data, which method and why that method over the alternative, how you validated it (holdout, sensitivity check, comparison with a simple baseline), and where it nearly went wrong. A story with no analysis in it reads as project coordination.
- Close with the result as a number or a changed decision, say which part you can attribute to your work, and give one thing you would do differently that is a choice you made, not a constraint you were handed. The answers that sink are the ones that stop at "I built a model", blame the data, or retell the whole timeline with no decision in it.
- Keep two versions of the story, a short one for a screening call and a longer one for rounds with several people, with identical facts and numbers in both.
Follow-up
- What was the hardest trade-off in that project, and what did you give up?
- How do you know the improvement came from your work and not from something else changing?
- If you started again with what you know now, what would you do first?
Announce a stream-definition change that shifts payouts
You find that the 60-second idle gap used to sessionise heartbeats into fct_stream rows splits one continuous listen into two streams whenever a phone backgrounds briefly on cellular. Correcting the gap lowers qualified stream counts on phones by an estimated four percent; total played_seconds is unchanged. Per-stream counts drive rights-holder payout shares. Deliverable: what you verify before telling anyone, the order in which you take it to the engineering owner, finance and content partnerships, and your recommendation on restating history.
Approach
- The probe is whether you can tell a technical correction from a commercial decision and keep them apart in the room. Verify the split streams are genuinely one listen before anything else: same profile_id, same content_version_id, contiguous max_position_seconds across the boundary, and a gap distribution with a spike at the background-timeout duration rather than a smooth tail.
- Compute the distributional effect, not the average. The four percent aggregate is not what anyone will argue about; recompute under the corrected gap and report which rights_holder_id groups gain and lose share, because short-form catalogue on mobile is where the splits concentrate and that is not spread evenly across counterparties.
- Defend the new rule on its own terms rather than on the direction of the number. The idle gap is a choice, so the argument is evidence that the two rows describe one continuous listen — never that the corrected count is lower and therefore more conservative, which invites the symmetric accusation next time the fix goes the other way.
- Name the ownership boundary out loud: engineering owns the sessionisation rule, finance and partnerships own whether payouts are restated. Conflating them is how a correct fix gets blocked by a commercial objection it should never have been exposed to.
- Sequence the conversations so the number stops moving before it leaves the building: engineering owner first to confirm the rule and land the fix, finance second to size the restatement, partnerships last. Recommend restating history for internal metrics so trends stay comparable, and recommend against retroactive payout adjustment unless the contracts require it — naming who must answer that contractual question rather than answering it yourself.
Follow-up
- Partnerships asks you to hold the fix until after the quarter closes. What do you do, and who else needs to know you were asked?
- How do you present a change that raises some counterparties' shares and lowers others', in the same meeting, to people who will compare notes afterwards?
- The four percent estimate itself has an interval spanning roughly two to seven percent. Does that change the recommendation or only the sequencing?
Arbitrate three requests for the same analyst week
Three requests land on the same Monday for the same week of your time. Growth wants trial-to-paid conversion recut by signup_channel before a budget meeting on Thursday. The playback team wants rebuffer ratio cut by cdn_pop, device_type and network_type after a bitrate ladder change went out Friday. Catalogue wants a displacement estimate for a title that arrived on a rights window last month. You have roughly four working days. Deliverable: your ordering with the criterion behind it, what you tell the two people who do not get the week, and one thing you ship to all three by Tuesday.
Approach
- The probe is your criterion, not your ordering. Rank by how reversible the pending decision is and how fast the evidence decays, and say so; ranking by requester seniority is the default answer and reads as one.
- Put the playback request first on those grounds: a bitrate ladder change is live and degrading real playback now, and rebuffer ratio is defined on a trailing 24 hours, so the evidence is perishable and the query is small. Cheap and perishable beats expensive and durable.
- Ask each requester what they do differently at each plausible answer. The trial-to-paid recut is a defined tree metric — trailing 28 days, read at trial length plus 21 days so dunning retries have resolved — so it is largely a filter plus an hour confirming that unattributed stays its own line rather than being reallocated pro rata.
- Treat the displacement estimate as the only genuinely new analysis and scope it rather than squeezing it: it needs a matched comparison group and a pre-registered window, because consumption of the rest of the catalogue moves on the release calendar regardless. Defer it with a date and a stated shape, never silently.
- Reply to all three in one thread with the ordering and the criterion visible, so a stakeholder who disagrees argues with the criterion instead of escalating about their position in the queue.
Follow-up
- The catalogue lead escalates to your manager on Tuesday. Walk me through that conversation.
- How does the ordering change if the bitrate ladder change was already rolled back on Saturday?
- All three deadlines are genuine and none can move. What do you actually cut?
- 01
Describe a challenging project you worked on and how you managed it.
- 02
How do you ensure that your analysis is understandable to non-technical stakeholders?
- 03
Can you provide an example of how you handled a conflict within a team?
- 04
Describe a time when you analyzed a dataset and what insights you derived from it.
- 05
Tell me about an analysis of yours that turned out to be wrong or incomplete, how you found out, and what check you added afterwards.
Is this an official 1010data interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at 1010data. The rounds and questions reflect what candidates have reported, not a process the company has published, and they change over time. Confirm the current format with your recruiter.
PracHub interview research ↗How many rounds are there, and how long does the process take?
Candidates report four rounds: Phone Screening, Technical Interview, Behavioral Interview and Team Interactions, over roughly 3-5 weeks. Reports do not give the length or exact format of each round, so ask your recruiter who you will meet and what to expect.
PracHub Data Scientist practice ↗Which languages and tools should I know?
The requirements candidates cite are Python or R, statistical analysis, machine learning and a visualization tool such as Tableau or Matplotlib. Hadoop or Spark, a cloud platform such as AWS or Azure, and A/B testing experience are listed as extras. Pick one language and write the reported coding questions in it by hand.
PracHub Data Scientist practice ↗What topics should I prioritise?
Reported questions centre on statistics and probability (regression assumptions, the methods you use), general machine learning (supervised versus unsupervised learning, a churn case), coding fundamentals (a mean and standard deviation function, sorting, performance, an anagram check) and case questions on trends and data preparation. Start with statistics and coding, then the churn case.
PracHub Data Scientist practice ↗Is there a take-home assignment?
None of the reported rounds mentions a take-home. Ask your recruiter whether any stage includes an exercise, a presentation or a live coding surface, and prepare for each by writing short functions without autocomplete and practising a verbal walkthrough of one past analysis.
PracHub Data Scientist practice ↗Do deep learning, NLP or big data come up?
Candidates mention deep learning frameworks, natural language processing and big data tools such as Hadoop or Spark as topics that may come up. Know one framework or tool in each area well enough to say when you would use it, what it costs, and a simpler alternative, and tie it to something you have actually used.
PracHub Data Scientist practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Yahoo Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at Yahoo candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.
Warner Bros. Data Scientist Interview Questions & Guide 2026
Take-home style practice for data scientists preparing for Warner Bros.: 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.
Tubi Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Tubi, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Spotify Data Scientist Interview Questions & Guide 2026
Case practice for the Spotify data scientist interview, where the prompt is deliberately underspecified and your first move is scoping it into something measurable.