The reported work splits into two halves that you should prepare separately. One half is product analytics: defining a success metric for a new feature, deciding how to protect long-term product health while engagement rises, and finding the cause when a key metric suddenly falls. The other half is evidence work: SQL on large tables, clean experiment design and a modelling toolkit that includes clustering, regression and classification. The reported questions cover both halves: three are about product metrics and the larger share are about SQL and experimentation, while the modelling topics candidates list (clustering, model selection, evaluation metrics and drift) add to the second half.
The SQL questions are concrete and checkable. A moving average of product sales over time is a window-frame question, the left join versus inner join question is set on user behavior logs, and the missing-data question is set on a large manufacturing dataset. Each has a short textbook answer and a longer answer that shows you have been bitten by the failure cases: missing dates inside a window, filters in a WHERE clause that quietly turn an outer join into an inner join, and sensor gaps that are not random. Practise on real tables so you can state the failure case from experience.
The experimentation questions ask for pitfalls that cause false positives and for how to size a test. Candidates list selection bias, novelty effects, network effects, primary, secondary and guardrail metrics, and power as the areas to be ready for. Expect to explain your choices in plain terms too, because the role involves explaining findings to people outside data science, and candidates also report that past projects on the resume are used as the starting point for deeper technical questions.
Candidates describe the loop as one where reasoning is as important as the final answer, so practise saying your assumptions out loud: the objective, the data you would need, the method and its limits. Where a question has no single correct answer, a clear structure and stated assumptions are what you can control.
Recruiter Screen
reportedCandidates describe this as an initial call with a recruiter to check fit for the role. Nothing more specific is reported, so treat it as the place to state clearly what you have done: which of SQL, A/B testing and machine learning you have used in work, and whether you have touched manufacturing or industrial data. Have a short account of your most relevant project ready, since candidates also report that the resume is used as the basis for later questions.
What to demonstrate
- Fit between your background and the role as described to you
- Whether you can summarise your experience with SQL, experimentation and modelling in a few sentences
- Whether you can explain a project's goal and result in plain language
How to prepare
- Write a short summary of each resume project: the problem, your part, the method, and the outcome, so the same facts come out each time
- Map your experience against the reported must-haves (SQL with window functions, A/B testing and significance, machine learning frameworks) and note which you have used for real
- Prepare a clear reason for wanting a Data Scientist role in a company with consumer, healthcare and industrial product lines
Technical Rounds
reportedCandidates describe a series of technical interviews that test machine learning and coding skills; nothing more specific about their format is reported. Across the loop as a whole, candidates report questions on metric design, SQL and A/B testing, and they list modelling topics such as clustering, model selection, evaluation metrics and drift, without saying which stage each comes from. For this stage, prepare machine learning and coding as methods rather than recited answers: define the objective, list the data you need, pick the technique and say what it cannot tell you. Candidates also report that resume projects are used as the starting point for deeper technical questions, so be ready to go deeper on any model you list.
What to demonstrate
- Machine learning knowledge, including choosing a model that fits the problem
- Coding ability, shown by code that runs and returns the right result
- Whether you can explain the reasoning behind a technical choice, such as why a simpler model was enough
How to prepare
- Review k-means and other clustering methods, and when a simple regression beats a deep learning model, with precision, recall and AUC-ROC examples
- Prepare an explanation of how you would monitor a deployed model for data drift and decide when to retrain it
- For the coding side, practise writing SQL and Python that runs on small tables you build yourself, checking row counts and outputs by hand
- For each model on your resume, write why you chose it, which alternative you rejected and how you validated it
Behavioral Rounds
reportedCandidates describe behavioral rounds focused on alignment with a collaborative culture; the format is not reported beyond that. For the loop as a whole, candidates report four behavioral questions: a difficult project and how obstacles were overcome, handling constructive feedback from a manager or peer, the first month in a new role, and explaining a complex technical concept to a non-technical stakeholder. Prepare these in STAR order, keeping in mind that the role involves working with product managers, engineers and operational leads.
What to demonstrate
- Alignment with a collaborative way of working, as candidates describe the stage
- Whether your examples show your own contribution and a concrete result
- How you describe working with colleagues and stakeholders in your examples
How to prepare
- Write four STAR stories, one for each reported behavioral question, each with a real result and your own contribution stated plainly
- Prepare the feedback story to show what you changed afterwards, not only that you listened
- Outline a first-month plan for a data scientist: who you meet, which data and dashboards you inspect, and the first question you try to answer
- Practise explaining one statistical idea, such as statistical significance, to someone outside data science
Rapid Recruiting (if applicable)
reportedCandidates report Rapid Recruiting as a stage that applies only in some cases and is aimed at academic candidates, made up of on-site presentations and back-to-back technical sessions. What the presentation is expected to cover and what the technical sessions ask are not reported. If this stage applies to you, prepare a talk on your own research or projects as a precaution, and be ready to answer detailed questions about it.
What to demonstrate
- How clearly you present your own work in an on-site presentation
- How you handle several technical sessions held back to back
How to prepare
- Build a presentation of your strongest project that states the question, data, method, result and limits, with a version for non-specialists
- List the technical choices in that project (model, features, metric, validation) and write a one-line reason for each
- Practise explaining how you managed data, tested hypotheses and revised them in your research
- Do one practice block of several mock interviews in a row to see how your answers hold up late in the sequence
Final Round Decisions
reportedCandidates describe this last stage as potential final round interviews leading to hiring decisions. Its format is not reported, so there is nothing specific to rehearse for it; keep your material consistent instead. Since candidates report that resume projects are used as a starting point for detailed technical questions, make sure your account of each project is the same in every conversation, with the same numbers and definitions.
What to demonstrate
- Consistency of your account of past work across conversations
- Whether your technical and behavioral strengths are clear enough to support a hiring decision
- Readiness to discuss your resume projects in granular detail
How to prepare
- Write a one-page fact sheet for each major project with the numbers, metric definitions and dates you will quote, and use it every time
- Re-read your behavioral stories and make sure each one shows a different strength
- Prepare questions about how data scientists work with product, engineering and operations teams in the business unit you are joining
PracHub editorial advice for the preparation topics above.
Giving a success metric for a new feature as a single name, such as engagement, with no denominator, population or guardrail
Say the metric as a sentence: numerator, denominator, time window and who is included. Add one guardrail that would show harm, such as a long-term health measure, and say which decision the metric supports.
Answering the sudden metric drop question by listing possible causes instead of a sequence for finding the real one
Start with data validity (logging changes, pipeline delays, definition changes), then decompose the metric into its components, split by segment, platform and time, then check external causes. Say what result at each step would change your next step.
Writing the moving-average query with the wrong frame, missing dates in the series, or no partition by product
State the partition, ordering and frame before writing, for example ROWS BETWEEN 6 PRECEDING AND CURRENT ROW per product. Explain what happens on days with no sales and in the first rows where the window is short, and say how you would add a calendar table to fix gaps.
Treating a significant A/B test result as proof, without checking power, sample ratio, peeking or multiple comparisons
State the sample size and the analysis rule before the test, check the arm sizes match the intended split, and report guardrail metrics beside the primary. Use selection bias, novelty effects and network effects as a checklist. Candidates also report a question on verifying that a significant result is not due to external factors, so prepare the concrete checks: an A/A test or a pre-period comparison of the two arms, a holdout, whether the effect holds week over week, and whether the test window overlaps a seasonal peak, campaign or outage that hit the two arms unevenly.
Telling resume projects with vague or shifting numbers, or with no clear explanation of why a method was chosen
Keep a fact sheet for each project with the data size, the metric as one sentence and the result, and prepare an answer to why you did not use a simpler model. Candidates report resume projects are used as a starting point for technical questions.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Estimate a delinquency roll-rate matrix and project twelve months
fct_loan_performance_monthly gives loan_id, as_of_month_end, months_on_book, delinquency_bucket, charge_off_flag, prepaid_in_full_flag and restructured_flag. Build a month-to-month transition matrix over the five delinquency buckets plus absorbing charged_off and prepaid states. Loans that stop appearing must be routed to an absorbing state rather than dropped. Project the current book forward 12 months by repeated matrix multiplication and report the projected share reaching charge-off. Handle restructured_flag explicitly, and name one place the Markov assumption fails on this data.
Approach
- Build consecutive month pairs per loan by shifting as_of_month_end within loan_id, then verify the shifted value is exactly one month later. A gap is not a transition, it is an exit you have not resolved yet.
- Resolve exits before counting anything. A loan whose last row carries charge_off_flag moves to charged_off, one carrying prepaid_in_full_flag moves to prepaid, and one that disappears with neither is a data question to raise rather than silently discard, because discarding it is survivorship that inflates every cure rate.
- Count pairs into a 7 by 7 matrix and row-normalise. Assert every row sums to one and the two absorbing rows are the identity; a row that does not sum to one means exits were dropped.
- Decide and state the restructure rule. Restructuring resets days_past_due, so a dpd_60_89 to current move on a restructured loan is not a cure. Either give restructured loans their own state or carry the pre-restructure bucket, but do not let that move land in the cure cell.
- Project by taking the current bucket distribution as a row vector and multiplying by the matrix twelve times. Report the charged_off entry, and report it again from an all-current starting vector so the reader can see how much of the projection comes from loans that are already delinquent today.
- State the homogeneity failure plainly: transition rates depend strongly on months_on_book, so one pooled matrix applied to a book with a young mix understates early-life delinquency. If the mix is moving, estimate separate matrices by seasoning band.
Worked solution 45 min
- Sort by loan_id and as_of_month_end, shift to form (from_state, to_state) pairs, and flag pairs whose month gap is not exactly one.
- For each loan's final row, assign the absorbing destination from charge_off_flag or prepaid_in_full_flag, and list loans that vanish with neither as an exception count to report.
- Apply the restructure rule, then build the 7 by 7 count matrix with a cross-tabulation over ordered state categories and row-normalise it.
- Assert row sums equal one and absorbing rows are the identity, then take the current month's bucket distribution as a row vector.
- Multiply twelve times, report the charged_off component, and repeat from an all-current vector for comparison.
Follow-up
- How would you validate the projection against what actually happened, and over what window?
- The cure rate out of dpd_30_59 rose five points last quarter. What are the candidate explanations and how would you separate them?
- When would you prefer a vintage curve to a roll-rate projection, and why?
Bootstrap a fraud loss rate that clusters within merchant
You have a per-transaction frame with auth_id, merchant_id, settled_amount_reporting and net_loss_reporting, both already in one reporting currency. Most rows carry zero loss, a few carry large ones, and losses cluster within merchant. Using only numpy's random generator and no resampling helper from any library, write a bootstrap that returns a 95 percent interval for net fraud loss in basis points of settled volume, resampling merchants with replacement and taking all rows belonging to each drawn merchant. Also produce the naive row-level interval and state which you would report.
Approach
- State the estimator before writing it: total net loss divided by total settled volume, times 10,000. It is a ratio of sums, so each replicate recomputes both sums. Averaging per-transaction loss rates instead would weight a five-unit transaction like a five-thousand-unit one.
- Pre-aggregate loss and volume to merchant level once. For a ratio of sums, drawing merchants and taking all their rows is arithmetically identical to drawing merchant-level (loss_sum, volume_sum) pairs, so a replicate becomes one integer draw plus two vectorised sums rather than a groupby inside the loop.
- Draw B replicates of M merchant indices with replacement, where M is the observed merchant count, compute the ratio per replicate, and take the 2.5th and 97.5th percentiles. Say explicitly that this is a percentile interval and that BCa would correct the skew-induced bias if the decision is close.
- Repeat with independent row draws for the naive interval and compare widths on the same replicate count.
- Report the clustered interval. Rows within a merchant share an acceptance profile, a category code and a fraud exposure, so they are not independent, and the row-level interval understates variance by roughly the design effect.
Follow-up
- Your clustered interval is three times wider. How do you explain that to someone who wanted a tighter number?
- One merchant accounts for 40 percent of losses. What does that do to the interval, and what would you do about it?
- How does this change if the question is whether two months differ rather than what this month's rate is?
Collapse retry chains and compute a dollar-weighted approval rate
fct_payment_authorization gives auth_id, card_token_id, merchant_id, amount_minor, transaction_currency, requested_at, auth_result, is_reversal, channel and issuer_country. Two reference frames give the minor-unit exponent per currency and a daily rate to one reporting currency. Collapse retry chains first: attempts sharing card_token_id, merchant_id and amount_minor whose consecutive gaps are under 15 minutes form a single attempt, whose outcome is its last row. Exclude reversals and zero-amount verifications. Return a 7-day rolling dollar-weighted approval rate by channel and issuer_country.
Approach
- Filter before grouping: drop is_reversal rows and zero-amount verifications, since neither is a purchase attempt and both would otherwise sit in the denominator.
- Sort by card_token_id, merchant_id, amount_minor and requested_at, take the gap to the previous row within that key, mark a chain start where the gap exceeds 15 minutes or the key changes, and label chains with a cumulative sum of that flag. This is a gap rule between consecutive attempts, not a fixed clock bucket, so a chain may span more than 15 minutes in total.
- Keep each chain's terminal row by requested_at. If a retry was approved, the purchase was approved; keeping the first row reports the decline that caused the retry as the outcome.
- Convert amounts exactly once: amount_minor divided by 10 to the power of the currency exponent, multiplied by the reference rate for the authorization date. Do not reach for settlement_fx_rate, which is null on precisely the declined rows the denominator needs.
- Build the rolling window as a ratio of two rolling sums, approved value over total value, per channel and issuer_country. A rolling mean of daily ratios weights a quiet Sunday the same as a busy Friday.
Follow-up
- The count-weighted rate is flat while the dollar-weighted rate falls 80 basis points. What do you look at first?
- How would you choose the 15-minute window rather than inheriting it?
- A merchant moves from two retries to five. Which of your two rates moves, and is that a real change in approval quality?
Can you explain the difference between a left join and an inner join i…
Can you explain the difference between a left join and an inner join in the context of merging user behavior logs?
Approach
- State the semantics: INNER JOIN keeps only rows with a match on both sides; LEFT JOIN keeps every row of the left table and fills the right table's columns with NULL where there is no match. Rows with a NULL join key never match in either.
- Tie it to logs: users LEFT JOIN events keeps users with zero events, which a denominator such as share of users active needs; an INNER JOIN silently drops them and inflates the rate. Count with COUNT(e.event_id), not COUNT(*), so unmatched users count as 0.
- Watch filter placement: a WHERE condition on the right table (WHERE e.event_type = 'click') removes the NULL rows and turns the LEFT JOIN into an inner join; put that condition in the ON clause instead.
- Check cardinality before aggregating: user-to-event is one-to-many, so joining a second fact table (orders, sessions) at event grain fans out rows and inflates sums; aggregate each side to user grain first, then join.
- Use LEFT JOIN ... WHERE right.key IS NULL as an anti-join to find users with no events, or events whose user_id is missing from the users table, which usually signals a logging or identity-mapping problem.
Follow-up
- After the join, your row count is larger than the number of distinct users. Why, and how do you fix it?
- How would you find events whose user_id does not exist in the users table?
- When would a FULL OUTER JOIN be the right choice for merging two log sources?
Describe how you would handle missing data in a large-scale manufactur…
Describe how you would handle missing data in a large-scale manufacturing dataset.
Approach
- Profile before fixing: missing rate per column and by machine, line, sensor and day (SUM(CASE WHEN col IS NULL THEN 1 ELSE 0 END) grouped, or COUNT(*) - COUNT(col)), and look for sentinel values such as 0, -999 or empty strings that hide missingness. Note that AVG and other aggregates skip NULLs silently.
- Classify the mechanism: missing completely at random, at random given observed columns, or not at random (a sensor that drops out when a machine runs hot). The mechanism decides whether dropping or imputing biases the result.
- Pick the fix per column: drop rows only when missingness is rare and unrelated to the outcome; for time series, forward-fill within the same sensor partition, bounded to a maximum gap and never across a restart or maintenance stop; otherwise interpolate, use a group median, or impute with a model.
- In SQL, forward fill uses LAST_VALUE(col IGNORE NULLS) OVER (PARTITION BY sensor_id ORDER BY ts) where the engine supports it; elsewhere, build groups with COUNT(col) OVER (PARTITION BY sensor_id ORDER BY ts) and take MAX(col) within each group.
- Add a was-missing indicator feature, fit any imputation on training data only to avoid leakage, and rerun the analysis with and without imputation to show the conclusion does not hinge on it.
Follow-up
- A sensor drops out exactly when temperature is highest. How does that change your approach?
- How would you write a forward fill in an engine with no IGNORE NULLS option?
- How would you show a stakeholder that the imputation did not drive the model's result?
How would you use a window function to calculate a moving average of p…
How would you use a window function to calculate a moving average of product sales over time?
Approach
- Aggregate to the grain first: sum transactions to one row per product per day, then apply the window, e.g. AVG(daily_sales) OVER (PARTITION BY product_id ORDER BY sale_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) for a 7-day average.
- Always write the frame: with ORDER BY and no frame clause, the default is RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, which gives a cumulative average and pulls in tied dates as peers.
- Handle gaps: ROWS counts rows, not days, so missing days stretch the window past 7 calendar days. Fix with a date spine (generate_series in PostgreSQL) cross-joined with products, LEFT JOIN the daily sales, COALESCE to 0, then apply the ROWS frame. A RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW frame (PostgreSQL 11+) spans the right days, but AVG over it divides by days with sales, not 7; use SUM(daily_sales) over that frame / 7.0 instead.
- In the date-spine version, the first six days of each product average fewer than seven values, so either label them or return NULL where COUNT(*) over the same frame is below 7.
- Cost is one sort per partition, roughly O(n log n), plus a linear pass; for a rate such as average price, compute SUM(revenue) / SUM(units) over the frame rather than averaging daily ratios.
Follow-up
- How would you compare each week with the same week last year, or compute a centred moving average?
- How would you flag days where sales fall well below the trailing average?
- What changes if late-arriving sales restate past days after the average is published?
Count-weighted and dollar-weighted approval rates on one currency
Using fct_payment_authorization, report the trailing 7-day authorization approval rate two ways for transaction_currency = 'EUR': count-weighted, and dollar-weighted on amount_minor. Exclude is_reversal = true, exclude incremental authorizations (parent_auth_id not null), and exclude zero-amount account verifications. auth_result = 'approved' is the numerator; the four declined_* values make up the rest of the denominator. Return channel, attempts, approved_attempts, approval_rate_count and approval_rate_value. State every exclusion and its reason before you write the SELECT.
Approach
- Say the denominator out loud first: attempts on a single transaction currency, excluding reversals, incremental authorizations and zero-amount verifications, because none of those is a purchase attempt a merchant is trying to get approved.
- Filter requested_at against a half-open interval (>= start AND < end) so the boundary day is neither dropped nor double counted.
- Compute both rates in one pass with FILTER clauses: COUNT() FILTER (WHERE auth_result = 'approved') over COUNT(), and SUM(amount_minor) FILTER (WHERE auth_result = 'approved') over SUM(amount_minor).
- Cast one side of each ratio to numeric before dividing, since amount_minor and the counts are integers and integer division silently truncates to zero.
- Group by channel and sort by the value-weighted rate, then read the gap between the two rates as a statement about where the declines sit rather than as noise.
Worked solution 20 min
- Write the exclusion list as comments above the query: is_reversal = false, parent_auth_id is null, amount_minor > 0, transaction_currency = 'EUR'.
- Build a single aggregate query over fct_payment_authorization with a half-open requested_at predicate and those four filters.
- Emit attempts, approved_attempts, approval_rate_count and approval_rate_value with FILTER clauses and a numeric cast on the numerator.
- Group by channel, order by approval_rate_value ascending so the worst channel is on top.
Follow-up
- The two rates diverge by four points on the ecommerce channel but agree on card_present. What does that tell you, and what would you cut next?
- How would you extend this to all currencies without summing amount_minor across them?
- Which of the four decline reasons belong in the denominator of a rate you would put in front of a risk team, and which are really the network's problem?
A key performance metric drops suddenly; how do you go about diagnosin…
A key performance metric drops suddenly; how do you go about diagnosing the root cause?
Approach
- Confirm the drop is real before explaining it: check for a logging or tracking release, a delayed or partial pipeline load, or a change to the metric definition, and compare against a second source such as raw events or the billing table.
- Pin down shape and timing: the exact hour or day it started, a step change versus a slide, and whether it falls outside normal weekly and seasonal variation (compare with the same weekday in prior weeks and the same period last year).
- Decompose the metric into its drivers (for example revenue = visitors x conversion rate x average order value; for a production metric such as yield, cut by line, shift, machine and raw-material lot) and segment by platform, app version, region, channel and customer type to find where the loss concentrates.
- Separate mix shift from rate change: if every segment's rate is flat but the share of a low-rate segment grew, the aggregate falls with nothing broken (the Simpson's paradox pattern).
- Line the start time up against internal changes (releases, experiment ramps, pricing, campaigns) and external ones (holidays, outages, competitor moves), confirm the top hypothesis with data, size its contribution, and close with a fix plus an alert so it is caught earlier next time.
Follow-up
- The drop concentrates in one app version, but that version's share of traffic also changed. How do you tell mix from rate?
- Every segment fell by roughly the same proportion. What does that point to, and what do you check next?
- How would you set an alert threshold that catches this earlier without firing on normal day-to-day noise?
How do you approach the trade-off between user engagement and long-ter…
How do you approach the trade-off between user engagement and long-term product health?
Approach
- Define both sides concretely: engagement as short-run activity (sessions, clicks, time spent, notification opens) and long-term health as retention at a longer horizon, repeat purchase, churn, satisfaction, complaints, unsubscribes and uninstalls.
- Explain how they diverge: notifications, clickbait or dark patterns can lift engagement this week while pushing users toward opting out or churning later, so engagement alone is not a success criterion.
- Choose a primary metric that tracks lasting value, keep engagement as a driver metric, and set guardrails (unsubscribe rate, complaint rate, retention) with a non-inferiority margin committed before launch.
- Measure the long-run effect directly: keep a long-running holdout group, watch the treatment effect over days since exposure to separate novelty from durable lift, and validate any short-term surrogate against the long-term outcome on past launches.
- Turn the trade into one decision: express both effects in a common unit such as expected lifetime value per user where possible, and ship only if the long-run estimate is positive, not merely the engagement lift.
Follow-up
- A notification change raises daily sessions but unsubscribes also rise. Do you ship, and what would change your answer?
- How would you check that a short-term metric is a valid surrogate for retention months later?
- What does a long-running holdout cost the business, and how would you size it?
How would you design a metric to measure the success of a new product …
How would you design a metric to measure the success of a new product feature?
Approach
- Start from the feature's purpose: who it is for, which user behaviour or business outcome it should change, and what decision the metric will drive (ship, iterate or kill).
- Lay out the funnel: eligible and exposed users, adoption (first use), repeat use, and the downstream outcome the feature exists to improve; note that adoption alone measures curiosity, not value.
- Write the primary metric exactly: numerator, denominator (eligible exposed users, not all users), unit, and a fixed window after first exposure, and check it is sensitive enough to move within a realistic test.
- Add guardrails and diagnostics: cannibalisation of existing features, latency or error rates, support contacts, cost, and segment cuts such as new versus existing users.
- Measure it causally with an A/B test or staged rollout; comparing adopters with non-adopters is biased by self-selection, because users who choose a feature differ from those who do not.
Follow-up
- Adoption is high but the downstream outcome does not move. What do you conclude?
- How would you measure success if randomising users is not possible?
- How would you stop the metric from being inflated by accidental or forced exposure?
What are the common pitfalls in A/B testing that lead to false positiv…
What are the common pitfalls in A/B testing that lead to false positives?
Approach
- Peeking: checking the p-value repeatedly and stopping at the first p < 0.05 inflates the false positive rate well above 5%. Fix the horizon in advance, or use a sequential method with an alpha-spending boundary (such as O'Brien-Fleming) or always-valid inference.
- Multiple comparisons: many metrics, segments or variants each tested at 0.05; with 20 independent tests the chance of at least one false positive is 1 - 0.95^20, about 64%. Commit to one primary metric, use Holm or Bonferroni for family-wise error or Benjamini-Hochberg for false discovery rate, and label segment cuts exploratory.
- Wrong unit of analysis: randomising by user but computing the standard error per session or page view treats correlated rows as independent and understates variance; use the delta method or a user-level bootstrap or cluster-robust errors.
- Broken assignment: test for sample ratio mismatch with a chi-square test against the intended split. Common causes are a trigger or exposure-logging condition that fires at different rates in the two arms, so treatment and control are filtered differently, bot filtering that removes more of one arm, or a variant that fails to load before the user is logged.
- Low power: a significant result from an underpowered test is more likely to be false and overstates the effect size (winner's curse); size the test in advance and treat a surprising win as a reason to replicate.
Follow-up
- An A/A test you run flags significance far more often than 5%. What do you investigate?
- The business needs to monitor the test daily for harm. How do you allow that without inflating false positives?
- A secondary metric is significant but the primary is flat. What do you report?
How do you determine the required sample size for an experiment to ach…
How do you determine the required sample size for an experiment to achieve statistical significance?
Approach
- List the inputs: baseline rate or variance of the metric, the minimum detectable effect (the smallest change worth acting on, set by the business decision, not by what the traffic allows), significance level (often 0.05 two-sided), power (often 0.8) and the allocation ratio.
- For two arms with equal allocation, n per arm is about 2(z_(1-alpha/2) + z_(1-beta))^2 sigma^2 / delta^2, with sigma^2 = p(1-p) for a conversion rate. At alpha 0.05 and 80% power the constant is 2 x (1.96 + 0.84)^2, about 15.7, so roughly 16 sigma^2 / delta^2.
- Worked check: baseline 10%, absolute MDE 1 point gives sigma^2 = 0.09 and n of about 15.7 x 0.09 / 0.0001, roughly 14,100 per arm. Since n scales with 1/delta^2, halving the MDE quadruples the sample.
- Convert to duration with eligible traffic per day, rounded up to whole weeks to cover weekly cycles; decide the duration before launch and do not stop early at the first significant reading.
- Adjust when the setup differs: randomising clusters (accounts, sites, production lines) multiplies n by the design effect 1 + (m - 1) x ICC; CUPED-style variance reduction scales required n by about (1 - rho^2); several variants or metrics need a corrected alpha; heavy-tailed metrics need capping or many more units.
Follow-up
- Available traffic supports only half the required sample. What are your honest options?
- How does the calculation change for revenue per user, which is heavy-tailed?
- The test ends significant but was underpowered for the effect you observed. What do you conclude?
Evaluate a staggered country rollout without a randomised control
A step-up authentication rule was enabled for ecommerce traffic in three issuer_country markets on three different dates across five months; twelve comparable markets never received it. You have fct_payment_authorization and fct_card_dispute at daily grain and cannot randomise. Estimate the effect on the dollar-weighted authorization approval rate and on matured fraud basis points, name the estimator and why the obvious one is wrong here, and justify your inference given that there are only three treated clusters.
Approach
- Rule out the default first. A two-way fixed effects regression with a single post-times-treated indicator is not valid under staggered adoption with effects that vary over time, because it constructs comparisons that use already-treated markets as controls for later-treated ones and can assign negative weights to some of those comparisons, so the coefficient need not lie inside the range of the true effects.
- Use an estimator built for staggered timing: Callaway and Sant'Anna group-time average treatment effects, or the Sun and Abraham interaction-weighted estimator, restricting the comparison group to the twelve never-treated markets and aggregating into an event study indexed on time since adoption.
- Defend parallel trends with evidence, not a single test. Show the pre-period leads with their intervals and state their magnitude relative to the post-period effect, because pre-trend tests are underpowered and failing to reject is not evidence of parallelism. Pre-register the maximum pre-period lead you would tolerate before abandoning the design.
- Fix the inference problem directly. With three treated clusters, cluster-robust standard errors are severely anti-conservative. Fit a separate synthetic control for each treated market against the twelve donors, with non-negative weights summing to one fitted on pre-period outcomes and predictors, then use in-space placebo permutation and the ratio of post-period to pre-period root mean squared prediction error as the test statistic. With twelve donors the smallest attainable one-sided permutation p-value is 1 / 13, about 0.077, so say that before anyone asks for p below 0.05.
- Split the two outcomes by maturity. The dollar-weighted approval rate is observable immediately and can be read on the full post window. Matured fraud basis points require at least 120 days of dispute maturity from the transaction month, so the fraud event study must terminate at the last matured month and the immature months must be marked incomplete rather than plotted as low.
- Enumerate and test the confounds specific to this setting: network mandates or regulatory deadlines that landed on the same dates, merchant-side changes in the treated markets, currency mix and settlement FX, and seasonality. Exclude donors subject to a concurrent mandate, and confirm that donors and treated markets do not share an acquirer whose outage would move both.
Worked solution 45 min
- Build a market-by-day panel of the dollar-weighted approval rate from fct_payment_authorization, applying the retry-collapsing and reversal exclusions and converting to one reporting currency at a pinned rate table so FX movement is not mistaken for effect.
- Fit Callaway and Sant'Anna group-time ATTs with the twelve never-treated markets as the comparison group, and aggregate into an event study with at least six pre-period leads and the full post window.
- Fit a separate synthetic control per treated market on the pre-period outcome plus predictors, verify weights are non-negative and sum to one, and record the pre-period root mean squared prediction error.
- Run in-space placebos by applying the same procedure to each of the twelve donors and rank the treated markets' post-over-pre RMSPE ratios among them to obtain permutation p-values.
- Repeat the whole pipeline for matured fraud basis points from fct_card_dispute attributed to the authorization's requested_at month, truncating the series at the last month with 120 days of maturity.
- Report both event studies side by side, state the permutation p-value floor of about 0.077, and present the approval-rate gain against the matured fraud change in the north-star units.
Follow-up
- Your synthetic control for one market puts 80 percent of the weight on a single donor. What do you do, and what does the leave-one-out check tell you?
- The approval rate rises and matured fraud basis points also rise. How do you express the trade-off in a single decision-grade number, and what does that require you to assume about the value of a declined good transaction?
- Suppose a fourth market adopts mid-analysis. How does that change the estimator, the donor pool and the permutation inference?
Settled volume jumps after a new acceptance corridor launches
Settled payment volume per active customer rose 12 percent in the month a new acceptance corridor went live. The pipeline sums settlement_amount_minor from fct_payment_authorization and divides by 100 to get major units. Columns available: amount_minor, transaction_currency, captured_amount_minor, settlement_amount_minor, settlement_currency, settlement_fx_rate, settled_at, is_reversal, issuer_country, acquirer_country. Confirm or refute the 12 percent, and specify exactly the conversion the metric should be using.
Approach
- Split the month-over-month increase by settlement_currency. If one currency carries nearly all of it while its transaction count barely moved, the problem is arithmetic rather than demand, and that is a two-minute check.
- Look up each currency's ISO 4217 exponent. Dividing a three-decimal currency by 100 instead of 1000 overstates it tenfold; dividing a zero-decimal currency by 100 understates it hundredfold. Neither is a rounding issue.
- Rewrite the conversion to scale settlement_amount_minor by ten to the power of that currency's exponent, then convert to the reporting currency. Do not reuse settlement_fx_rate for this; it is the rate applied between transaction and settlement currency at settlement time, not a reporting-currency rate.
- Check the other half of the series too. settlement_amount_minor is denominated in settlement_currency while amount_minor is in transaction_currency, so any series that mixes the two is uninterpretable regardless of the exponent fix.
- Exclude reversals and refunds, recompute, then reconcile the corrected total to the settlement ledger for the same period and show the tie-out in the write-up.
- Recompute the per-customer denominator on the corrected month, since a new corridor adds customers as well as volume and the ratio can move either way once the numerator is right.
Follow-up
- Where else in the warehouse does a hardcoded divide-by-100 appear, and how would you find every instance?
- What test would fail the build the next time a currency with a different exponent is onboarded?
- The reporting-currency rate is itself a choice. Which rate, on which date, and why does finance care about the answer?
The week follows the reported question groups: metric design and diagnosis first, then SQL, then experimentation and modelling, and finally behavioral, resume and presentation preparation. Each day produces something you can check.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Metric design and drop diagnosis
- Pick a feature you know and write the success metric in one sentence (numerator, denominator, window, population), then add a secondary metric and a guardrail.
- Write a diagnosis checklist for a sudden drop in a key metric: data validity, definition changes, decomposition into components, segment splits, seasonality and mix shift, external events.
- Apply the checklist twice: once to a user-facing metric and once to a manufacturing measure such as line yield, and note where the steps differ.
Deliverable: A one-page metric specification and a metric-drop checklist applied to two examples.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Engagement versus long-term health
- Write an answer to the engagement versus long-term product health question that names one primary metric, a long-term measure (retention or repeat use), and guardrails, and says what you would do if they conflict.
- Work through the practice drill on a sudden volume jump after a launch, narrating each decomposition step aloud.
- Write what evidence would make you recommend stopping a change that raises engagement.
Deliverable: A written answer to the trade-off question, a worked diagnosis for the practice drill and a short stop-criteria note.
Practice prompt ↗Practice prompt ↗03Window functions and moving averages
- Write a moving average of product sales per product with a window frame, then show how the result changes if some dates have no rows.
- Fix the gaps with a calendar table and a left join, and compare ROWS and RANGE frames on the same data.
- Reproduce the numbers in pandas with a rolling mean and confirm they match, then use the practice drill on weighted approval rates to rehearse computing a ratio as a sum over a sum.
Deliverable: A tested SQL query for the moving average, a gap-handling version, a pandas check and the worked practice drill.
Practice prompt ↗Practice prompt ↗04Joins and missing data
- Create a small users table and an events table, run an inner join and a left join, and record the row counts and which users disappear; then move a filter from ON to WHERE and show the effect.
- Show how a one-to-many join inflates a sum, and fix it by aggregating before joining.
- Write a decision table for missing values in manufacturing data: classify the missingness, then choose deletion, group-wise imputation, forward fill with a limit or a missing-value indicator.
Deliverable: A script showing the join differences and the fan-out fix with row counts, plus a missing-data decision table.
Practice prompt ↗Practice prompt ↗Worked solution ↗05A/B testing pitfalls and sample size
- Compute the sample size per arm for a binary metric from baseline, minimum detectable effect, alpha and power, and check it against a calculator.
- Simulate A/A tests with a daily peek over several weeks and record how the false positive rate rises, then apply a fixed horizon.
- Write a list of false-positive causes (peeking, multiple metrics or segments, selection bias, novelty effects, network effects, unequal arm sizes) with how you would detect each, plus the checks for an external cause behind a significant result (A/A or pre-period comparison, week-over-week stability, overlap with campaigns or outages).
Deliverable: A sample-size sheet, a peeking simulation result and a pitfall checklist with detection steps.
Practice prompt ↗Practice prompt ↗06Modelling topics and causal limits
- Run k-means on a small dataset with scaled features, choose k with the elbow and silhouette scores, and write what could mislead you (scaling, outliers, initialisation).
- Write a short note on when a simple regression is preferable to a deep learning model, and which metric (precision, recall, AUC-ROC) suits an imbalanced problem.
- Outline a drift monitoring plan for a deployed model, then work through the practice drill on evaluating a staggered rollout without a randomised control.
Deliverable: A clustering notebook, a model-choice note with metrics, a drift monitoring outline and the worked rollout drill.
Practice prompt ↗07Behavioral stories, resume fact sheets and a project talk
- Write STAR stories for the four reported behavioral prompts, and say each aloud once.
- Practise explaining statistical significance to a non-technical listener, then work through the practice drill on explaining an incomplete chart to an executive.
- Write a fact sheet for each resume project with the data size, metric definition and result, and use it to answer a question about why you chose your method.
- In case the Rapid Recruiting stage applies to you, build a 10-slide talk on your strongest project (question, data, method, result, limits) and rehearse it once for a non-specialist listener.
Deliverable: Four STAR outlines, a plain-language explanation, fact sheets for each resume project and a 10-slide project talk.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates describe behavioral rounds as checking alignment with a collaborative culture, and the role involves working with product managers, engineers and operational leads while explaining findings to non-technical people. Prepare stories with a concrete result and your own contribution, and rehearse them in STAR order.
Tell me about a time you had to explain a complex technical concept to…
Tell me about a time you had to explain a complex technical concept to a non-technical stakeholder.
Approach
- Choose a concept the audience genuinely needed for a decision, such as why a result was not statistically significant, what a model's precision and recall mean for their process, or why a metric changed. Name the audience and the decision at the start, so the story is about what they had to decide and not about the concept itself.
- State the situation in two sentences, then spend most of your time on your actions: how you found out what they already knew, which analogy or example you used, what you left out on purpose, and what you showed (one chart or one number in their own units rather than a table of statistics).
- Show how you checked understanding. Strong examples include asking them to restate the conclusion in their own words, or noticing that a question they asked revealed a gap and adjusting. This moves the story from presenting to communicating.
- Close with the result: the decision they made, the change that followed, and what you would do differently next time. The common mistake is a story that ends with I presented it and they said thanks, or one that lists jargon you simplified with no outcome.
Follow-up
- How did you know they had understood, and what did you do when they had not?
- What did you leave out of the explanation, and what was the risk of leaving it out?
- What would you do if the stakeholder disagreed with the conclusion after you explained it?
Turn a one-line fraud-number request into a scoped brief
A stakeholder messages: what is our fraud rate, and is it going up? You have fct_payment_authorization, fct_card_dispute and dim_customer. At least four defensible answers exist: count-weighted or value-weighted, attributed to the transaction month or to the dispute filing month, and gross or net of recoveries and successful representments. You get one reply before someone else produces an uncaveated number. Write that reply: the clarifying questions you ask, the single default you will produce if nobody answers, and what the default excludes.
Approach
- Establish the decision behind the question first, because a risk-rule change, a board number and a merchant contract negotiation need different denominators, and asking which one is not stalling.
- Offer a short menu rather than an open question: a stakeholder can choose between two named options but cannot specify a denominator from scratch.
- Commit to a default so the reply is useful even if nobody answers, for example net fraud loss in basis points of settled volume, attributed to the requested_at month, matured months only.
- State the exclusions in the same breath as the default: non-fraud dispute categories, transaction months with less than 120 days of maturity, and first-party abuse that arrives coded as consumer_dispute.
- Give a delivery time for the default and a longer one for the fuller cut, so the choice between them carries a visible cost.
Follow-up
- They come back wanting it by merchant for a contract negotiation. What changes in the definition and in the maturity rule?
- How would you separate first-party abuse from third-party fraud in this data, and what would you refuse to conclude from the split?
Explain an incomplete dispute chart to a non-technical executive
A finance lead is looking at first-chargeback rate by transaction month, built from fct_card_dispute joined to fct_payment_authorization on auth_id and attributed to requested_at. The last three months slope sharply down and the lead wants to announce a fraud improvement at tomorrow's review. Consumer dispute rights commonly run around 120 days from the transaction or expected delivery date, so those months are not complete. In five minutes, with no statistics vocabulary, explain why the decline is not yet evidence and say exactly what you would put on the slide instead.
Approach
- Lead with the mechanism in the listener's own terms, not with the statistical name for it: a dispute is attributed to the month the transaction happened, but it can be filed up to roughly 120 days later, so recent months contain only the disputes filed so far.
- Show completeness rather than arguing about the rate: for each transaction month, plot the share of its eventual disputes already filed, estimated from months that are fully matured. The last three months will sit visibly below 100 percent.
- Replace the chart with two artefacts: a matured series that stops 120 days back and is labelled final, and a development-factor estimate for the immature months drawn as a dashed range and labelled an estimate.
- Hand over one sentence the executive can repeat without you in the room: the recent months look better because the disputes have not arrived yet, not because fewer will arrive.
- Offer a weekly signal they can watch instead, such as the risk-score mix of approved volume or the decline-rule hit rate, and state up front what it does and does not predict.
Follow-up
- The deck ships tomorrow regardless. What exactly goes on the slide, and what wording do you insist on?
- How would you estimate the development factors, and how would you notice if they had shifted?
- 01
Tell me about a time you had to explain a complex technical concept to a non-technical stakeholder.
- 02
Tell me about a time you had to deal with a difficult project and how you overcame the obstacles.
- 03
How do you handle constructive feedback from a manager or peer?
- 04
Describe your approach to your first month in a new role.
- 05
Describe a time a metric you owned changed unexpectedly and how you told the people relying on it.
- 06
Walk through the resume project you know best, including the choice of method and what you would change.
Is this an official 3M interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at 3M. Rounds and questions reflect what candidates have reported, not a process 3M has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How long does the interview process typically take?
Candidates report five stages over roughly 4-6 weeks, and the pace is described as varying by business unit. Gaps between stages are possible, so use the waiting time to keep practising SQL, experimentation and your project stories.
PracHub interview research ↗Is the technical interview focused on theory or application?
Candidates describe an emphasis on application. Know the theory behind each model or test you mention, but practise saying why you chose it for a specific problem, such as a manufacturing dataset or a product feature, and what its limits are.
PracHub interview research ↗What is the best way to stand out during the behavioral interview?
Use STAR and make your own contribution and the measurable result clear. Prepare for the reported prompts: a difficult project, constructive feedback, the first month in a new role, and explaining a complex concept to a non-technical stakeholder.
PracHub interview research ↗Is there a different path for academic candidates?
Candidates report a Rapid Recruiting stage, applicable in some cases, that is aimed at academic candidates and includes on-site presentations and back-to-back technical sessions. Its content is not reported, so if you have a research background, prepare a talk on your work and be ready to explain how you managed data and revised hypotheses.
PracHub interview research ↗How much SQL should I practise?
Candidates list SQL with window functions as a must-have skill. Practise moving averages with explicit frames, left versus inner joins on log-style tables, aggregations after joins, and NULL handling, and check your row counts after every join.
PracHub Data Scientist practice ↗What should I do if I get stuck on a technical question?
Say your thought process out loud instead of staying silent. State what you know, the assumption you are making, and the next step you would try, so that the reasoning is visible even when the final answer is not.
PracHub Data Scientist practice ↗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.
1st Central Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for 1st Central data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.
Virtu Financial Data Scientist Interview Questions & Guide 2026
Take-home style practice for data scientists preparing for Virtu Financial: 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.
USAA Data Scientist Interview Questions & Guide 2026
Data-quality drills for USAA data scientist prep: survivorship and selection bias, leakage through time-ordered features, and extreme values where provenance decides the call. A logging fault or unit slip gets corrected or dropped; a genuin
ValueLabs Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for ValueLabs data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.