The role of a Data Scientist at Redhorse is pivotal in transforming raw data into actionable insights that drive decision-making and strategic initiatives. As a Data Scientist, you will harness advanced analytical techniques, machine learning algorithms, and statistical models to solve complex problems and optimize processes within various teams. This position is not only critical for enhancing product offerings but also for improving user experiences and operational efficiencies across the organization.
You will contribute significantly to projects in areas such as acquisition and sustainment, where your analyses will inform product development, marketing strategies, and customer engagement efforts. The complexity of data sources and the scale at which Redhorse operates make this role both challenging and rewarding. You will work collaboratively with cross-functional teams, providing insights that shape the future of the company’s offerings and ensuring that data-driven decisions are at the forefront of its growth.
Initial Screening
reportedData Scientist covers at least four different jobs: experimentation, product analytics, causal work on observational data, and applied modelling that ships into a system. A screening call is the cheapest place to find out which of them is being hired for, and doing that diagnosis openly reads as senior rather than fussy. Ask what the last few pieces of work on the team actually were, and roughly how a week splits between querying, modelling and stakeholder time. Then say which parts of that you have done and which you have not. Claiming the whole range is the fastest way to be caught one round later.
What to demonstrate
- Whether you can distinguish the flavours of the role and locate your own experience inside one of them honestly
- Whether you name what you have not done instead of stretching to cover every line of the posting
- Whether your hard constraints (notice period, location, work authorisation, level) surface now rather than at offer stage
How to prepare
- Map the last two years of your time into rough percentages across query writing, experiment design, modelling and stakeholder work, so a question about scope has a real answer
- Mark every responsibility in the posting as done, adjacent or new, and prepare one sentence for each adjacent item naming the closest thing you have actually built
- Decide which logistics are non-negotiable before the call so you can state them in one sentence rather than negotiating live
Technical Assessments
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
Behavioral Interviews
reportedRounds of this kind usually include one question about work that did not go well, and it is the part that carries the most information. Anyone can narrate a shipped win. What the interviewer learns from a project that stalled is how you behave without a result to hide behind: whether you noticed the problem yourself, how long it took, and who you told. Answers that route the failure onto a data pipeline or a reorganisation close the topic without answering it, and the follow-up comes back to your own part.
What to demonstrate
- Whether you found the error yourself or someone else found it, and how long it sat before anyone knew
- What you changed afterwards, stated as a check you now run rather than a lesson you now believe
- Whether the mistake you choose has real cost attached, such as a quarter of misdirected roadmap or a metric that was reported upward, instead of one that flatters you
How to prepare
- Choose a failure you caught yourself and be ready to say what tipped you off. A story where someone else caught it is still usable, but you will be asked why you missed it.
- Write down the check you added afterwards and where it lives now, so the correction is a concrete artefact rather than a resolution.
- Rehearse saying the cost out loud. Candidates shrink the number by instinct once the interviewer is in the room.
Engagement with HR and Team
reportedAn added round often puts you in front of someone outside the core hiring team: a partner engineer, a product owner, a domain expert, sometimes a more senior manager. The question they are really asking is not whether you can do the work but whether they would trust a number that came from you. That changes what a good answer looks like. Lead with what the decision cost and what it changed, keep the method available but not central, and be plain about the limits of your evidence. Overstating a result is the fastest way to lose this round.
What to demonstrate
- Whether you can explain a technical choice to someone who will never read your code, without either flattening it into nothing or hiding inside jargon
- Honesty about evidence strength: what the analysis establishes, what it only suggests, and what it cannot say at all
- How you take disagreement, specifically whether you update on a good objection, hold your position with reasons, or fold on contact
How to prepare
- Write the two-sentence version of your most technical project for a non-specialist, then check that neither sentence needs a method name to make sense.
- For one result you are proud of, write the strongest objection someone could raise and a response that concedes the part of it that is correct.
- Prepare one decision that turned out to be wrong: how you found out, what it cost, and what you changed afterwards. A senior cross-functional interviewer asks for this more often than a technical one does.
PracHub editorial advice for the preparation topics above.
Reading recommendation quality from click-through or play-through on logged slates.
Slate position drives interaction independently of relevance, and the ranker that produced the log also decided what got exposure, so logged data is confounded by the policy you are trying to evaluate. Inverse-propensity estimators fix this only when the logging propensities are known and every item had a non-zero chance of being shown; without exploration slots that positivity condition fails silently and the estimate is confidently wrong. The visible symptom is a feedback loop: offline metrics improve, consumption concentrates further into the head of the catalogue, and the online test does not reproduce the offline gain.
Collapsing cancellation and payment failure into one churn number.
Involuntary churn from expired or declined payment instruments is a large and volatile share of gross churn, and it responds to retry schedules, card-updater coverage and billing provider, not to anything in the product. It also resolves late, so a period that looks involuntary today can be a successful retry next week, and reading the split before the dunning horizon closes overstates it. Compounding this, cancel-at-period-end means the cancellation request and the entitlement end are different timestamps on different rows, so a churn curve keyed on cancel_requested_ts and one keyed on churn_ts disagree by a full billing period.
Reporting a mean for a heavy-tailed metric without saying what it hides
For spend, session length or items per order, a small fraction of units carries most of the total, so the mean has a wide standard error and one account can move it. Fix the handling before you see the result: cap or winsorise at a pre-declared percentile, and report the median or the share above a threshold next to the mean. Capping changes the estimand, so say which question the capped number answers, and check how much of any difference comes from the top 0.1 percent of units.
Comparing periods without accounting for seasonality or day-of-week
Compare whole weeks against whole weeks and check whether the same swing appeared in prior cycles or prior years before attributing it to anything you changed. Weekday and weekend populations often differ enough that a Tuesday-to-Saturday comparison is meaningless.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the concept of overfitting in machine learning models.
Explain the concept of overfitting in machine learning models.
Approach
- Say how the offline result would be validated online before it is trusted.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
Follow-up
- Where could label leakage enter this setup?
- How would you choose the decision threshold, and who owns that choice?
How do you approach feature selection for a predictive model?
How do you approach feature selection for a predictive model?
Approach
- Say how the offline result would be validated online before it is trusted.
- Set a baseline first, so any model has something honest to beat.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
Follow-up
- What would you monitor after launch to know the model is still valid?
- How would you choose the decision threshold, and who owns that choice?
Simulate concurrent-stream refusals on a shared family account
A family account has four profiles and max_concurrent_streams = 2. Across an evening window of six hours, each profile independently attempts playback as a Poisson process at 0.75 attempts per hour. Durations are lognormal with a median of 24 minutes and sigma 0.6 on the log scale. An attempt arriving while two streams are already active is refused and abandoned, not retried or queued. Estimate the share of attempts refused and the mean refusals per account-evening, each with a 95 percent interval, then repeat with the cap at three.
Approach
- Simulate event-driven rather than on a time grid: draw exponential inter-arrivals per profile at rate 0.75 per hour, pool and sort the arrival times, and carry a short list of active end times.
- At each arrival, discard end times at or before that instant, then refuse if two remain. Only a served attempt draws a duration and pushes arrival plus duration; drawing a duration for a refused attempt and letting it hold a slot models a queue instead of a refusal.
- Start the window empty and do not warm it up, because the question is about an evening that begins with nobody streaming. Say explicitly that this makes the simulated share read below the steady-state value.
- Size the replications from a pilot: run 2,000 evenings, read the observed share, then solve 1.96 times the standard error to at most 0.002 using the between-evening standard deviation of the per-evening refusal share.
- Re-run with the cap at three by changing one constant and report the pair, because the decision this feeds is whether the cap is what the refusals are about.
Worked solution 30 min
- Write one evening as a function: per profile, cumulative exponential draws with scale 1/0.75 hours truncated at 6 hours, then concatenate and sort the arrival times.
- Sweep arrivals in order against a list of active end times: pop the expired, refuse if the list is already at the cap, otherwise draw a lognormal duration with mean parameter log(24/60) and sigma 0.6 in hours and append arrival plus duration.
- Return (attempts, refusals) per evening; run a 2,000-evening pilot, take the per-evening refusal share, and size the full run from its standard deviation.
- Run the sized number of evenings at cap 2 and again at cap 3, with a fixed seed per configuration.
- Report the pooled share (total refusals over total attempts) with a clustered interval built from the per-evening shares, plus the mean and 90th percentile of refusals per evening.
Follow-up
- What changes if a refused attempt retries after two minutes instead of being abandoned?
- Erlang-B gives a closed form for this. Where does it agree with your simulation and where does it not?
- How would you find these refusals in fct_stream, given that a refused attempt produces no stream row at all?
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?
You have a dataset with various features. How would you approach analy…
You have a dataset with various features. How would you approach analyzing this data to identify key trends?
Approach
- Fix the population and the time window before naming any metric.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Name one primary metric, then the guardrail that stops it being gamed.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How would you communicate complex data findings to a non-technical aud…
How would you communicate complex data findings to a non-technical audience?
Approach
- Restate the decision this analysis has to support, and who acts on the answer.
- Name one primary metric, then the guardrail that stops it being gamed.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
Given a business problem, how would you determine the most appropriate…
Given a business problem, how would you determine the most appropriate data to collect?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Fix the population and the time window before naming any metric.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
How do you prioritize tasks when working on multiple projects?
How do you prioritize tasks when working on multiple projects?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Fix the population and the time window before naming any metric.
- Name one primary metric, then the guardrail that stops it being gamed.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
Design an experiment to test a hypothesis about user behavior.
Design an experiment to test a hypothesis about user behavior.
Approach
- Name the guardrails that would stop a launch even on a positive primary result.
- Name the randomisation unit first; it decides the variance and what the test can detect.
- State the primary metric and the minimum effect worth shipping, then size the test.
Follow-up
- What would you do if you could not randomise at all?
- How would you handle interference between treated and control units?
Discuss a project where you applied statistical analysis to drive busi…
Discuss a project where you applied statistical analysis to drive business decisions.
Approach
- Work from the decision backwards to the evidence you would need.
- Say what you would check first and why it is the highest-information step.
- Clarify what is being asked and what a complete answer would contain.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Decide a rights renewal on retention, not on plays
A licensed bundle from one rights_holder_id has rights_expires_at in 60 days and renewal is expensive. Finance wants a number that decides it. You have dim_content_version (content_version_id, content_id, rights_holder_id, license_type, rights_expires_at, available_territories), fct_stream (account_id, content_version_id, played_seconds, is_qualified, started_at, play_territory) and fct_subscription_period (account_id, period_end_ts, renewal_outcome, net_amount_usd). Define the metric you would put in the renewal memo, the comparison that identifies it, and the assumption it rests on. Plays on the bundle is not an acceptable answer.
Approach
- Reject the play count with a reason, not a slogan: plays measure what the bundle drew, and the renewal question is what would be lost if it went, which differs by whatever those accounts would have watched instead. A bundle can be the third most played thing in the catalogue and still be worth nothing at the margin if its audience substitutes freely.
- Define the account-level exposure measure the analysis runs on: share of an account's qualified hours in the trailing 90 days falling on content_version_id rows whose rights_holder_id is the bundle's, which turns a catalogue fact into an account attribute that can be related to renewal_outcome.
- State the metric for the memo: incremental retained subscription revenue, estimated as the difference in the rate of renewal_outcome = 'renewed' between exposed accounts and matched unexposed accounts, multiplied by net_amount_usd per period, summed over exposed accounts, and compared directly against the renewal cost.
- Name the identification problem instead of burying it: exposure is chosen, so heavy users of this bundle are heavier users generally and would renew at a higher rate with or without it. Match on pre-period total qualified hours, tenure, plan_tier and billing_interval, and state that residual confounding on taste remains and biases the estimate upward.
- Use the natural experiment the rights data hands you: available_territories means the window has already lapsed somewhere, so a difference-in-differences on renewal rates between lapsed and still-licensed territories identifies the effect under parallel trends, and territory is not randomly assigned so the assumption must be argued with pre-period trend lines rather than asserted.
- Quantify displacement, because it is the whole question: for exposed accounts, measure qualified hours on everything outside this rights_holder_id before and after an expiry that already happened, relative to the matched group, and report what fraction of the lost hours reappeared elsewhere in the catalogue.
Worked solution 35 min
- Define exposure as a continuous share and then a threshold, and show one distribution cut: what fraction of accounts have more than 10 percent of trailing-90-day qualified hours on this rights_holder_id.
- Write the matched comparison: exposed versus unexposed accounts matched on pre-period qualified hours decile, tenure bucket, plan_tier and billing_interval, with renewal_outcome as the outcome and the matching variables listed explicitly.
- Write the difference-in-differences on territories where rights_expires_at has already passed, with the pre-period trend check named as the test of the parallel-trends assumption.
- Compute displacement for the already-lapsed territories: exposed accounts' qualified hours outside the bundle, before versus after, relative to matched accounts elsewhere, expressed as a substitution fraction.
- Assemble the memo number: incremental renewal rate times net_amount_usd per period times exposed accounts, with the substitution fraction applied and the upward-bias caveat stated in the same paragraph.
Follow-up
- The difference-in-differences shows a renewal effect only in two of eleven lapsed territories. What do you report, and does that change the recommendation?
- How would your answer change if the bundle's license_type were 'exclusive_license' rather than 'non_exclusive_license'?
- Exposed accounts substitute 70 percent of the lost hours within four weeks. What number goes in the memo now?
Revenue per engaged account slid with no price change
Net revenue per active account-month fell 7% across two closed months. No list price changed and no discount campaign ran. You have fct_subscription_period (account_id, period_start_ts, period_end_ts, plan_tier, billing_interval, net_amount_usd, currency_code, is_promotional, payment_status), dim_account (signup_country, plan_tier, billing_provider, first_paid_ts) and the qualified-stream denominator from fct_stream. Decide whether revenue per paying account fell or the denominator changed, and where. Deliverable: a decomposition across numerator and denominator naming the two largest contributing segments and whether each is reversible.
Approach
- Split the ratio before splitting any segment. Revenue per engaged account equals revenue per paying account multiplied by paying accounts over engaged accounts. A growing free_ad_supported tier moves only the second factor and looks identical to a pricing problem in the headline.
- Cut the numerator by signup_country and currency_code and recompute at both period-of-record and fixed exchange rates. If local list prices are unchanged, a simultaneous USD fall across many countries is FX, and the fixed-rate series says so in one line instead of a meeting.
- Decompose revenue per paying account into within-segment change and mix over (plan_tier x billing_interval x signup_country) cells. Annual periods recognise pro rata across months, so a monthly-to-annual shift changes recognised revenue per account-month without changing what anybody paid over a year — a real accounting move with no economic content.
- Treat the denominator's composition as its own problem. Engaged accounts are distinct accounts with a qualified stream, so an acquisition push into a low-price market or into the free tier adds denominator months before it adds revenue and dilutes the ratio mechanically for a knowable number of months.
- Report the two segments carrying most of the move with their weight change and within-segment change shown side by side, and label which reverse on their own and which do not. That distinction is the actionable part of the answer; the 7% by itself is not.
Follow-up
- The ratio dilutes for some months after an acquisition push. How many, and how do you present the metric so a marketing success is not read as a regression every time?
- If the shift into annual billing is permanent, is the 7% real? What does the promotional-share guardrail say about it?
Roughly 90 minutes a night on weekdays with one longer weekend block. The plan deliberately cuts scope rather than compressing everything, on the assumption that finishing one thing a night beats half-starting four.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Fix the scope and set a baseline
- Read the role description and write the three things the loop will almost certainly test, then write an explicit not-doing list for everything else and keep it visible all week.
- Take one 20-minute SQL prompt and one 10-minute metric question cold, and write the single sentence that says what blocked each attempt, since that sentence is what decides which two topics get the most evenings.
- Set the week's one rule: one problem finished to completion every night, including the night you only have 40 minutes.
Deliverable: A one-page scope with an explicit not-doing list and two cold attempts, each carrying one sentence on what blocked it.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02One query pattern, written three times
- Choose the single pattern most likely to appear (a cohort retention grid, or a funnel counted by user) and write it three times from a blank file rather than editing the previous attempt.
- On the third attempt, write the grain of every CTE as a comment before writing its body.
- Stop at 90 minutes even if the third version is imperfect, and write the one thing you would fix with another hour.
Deliverable: Three independent versions of the same query plus a note on what changed between them.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Only the statistics you will be asked to defend
- Write, in under 200 words, how you would decide whether a difference between two groups is real: the test, its assumptions, and what you would switch to when an assumption fails.
- Compute a 95 percent confidence interval for a difference in proportions by hand on realistic numbers, then write in one sentence what changes if the two samples are paired rather than independent.
- Write your answer to "what does a p-value mean", check it against a definition, and delete the version that describes it as the probability the hypothesis is true.
Deliverable: A 200-word written answer and one hand-computed interval you can reproduce under pressure.
Practice prompt ↗Practice prompt ↗04One case, and the assumptions holding it up
- Answer one product case aloud in 20 minutes with a recording running, then listen back with a pen and mark every claim you asserted without saying what it rested on: an assumed user behaviour, an assumed data source, an assumed baseline rate, an assumed grain.
- Pick the three assumptions the recommendation actually depends on, write how you would check each one against data, and say which one being wrong would flip the recommendation rather than merely weaken it.
- Write the four-step structure you used onto a card small enough to hold in working memory when you are nervous.
Deliverable: One recording, three load-bearing assumptions each with a written check, and a four-step structure card.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Your own work, timed
- Write a 90-second version and a four-minute version of your main project, and time both out loud rather than reading them.
- Prepare answers to the two follow-ups that always come: what you would do differently, and how you knew it worked.
- Put one number in the first sentence and be able to say exactly where that number came from and what it excludes.
Deliverable: Two timed narratives with one defensible number in the opening line.
Practice prompt ↗Practice prompt ↗06The one full rehearsal, in a longer weekend block
- Run a 60-minute mock covering query work, a case and a behavioural question in a single sitting with no breaks, because sustained attention is the thing evenings have not trained.
- Immediately afterwards, and before hearing any feedback, write the three moments you lost the thread.
- Spend the rest of the block only on those three moments, and on nothing you merely feel shaky about.
Deliverable: Mock notes naming three failure moments with a specific fix written under each.
Practice prompt ↗Practice prompt ↗07Taper
- Write the 20-minute warm-up you will actually do on the morning of the interview: one query you can already write from a blank file, one metric you can define out loud, and nothing you have never seen before.
- Re-read only your own notes from this week, and open no new material.
- Write down the logistics: the tool you will be asked to work in, whether lookups are allowed, and the sentence you will use when you do not know something.
Deliverable: A one-page card holding the case structure, the project numbers, and the logistics.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
An answer without a quantity is hard to interrogate, so interviewers keep probing until they find one. Come with the baseline, the change, the window it was measured over, and how confident you were. If the effect never got measured, say so and say what you would have measured. Fabricated precision is worse than an honest gap.
How do you handle disagreements with team members about data interpret…
How do you handle disagreements with team members about data interpretation?
Approach
- Quantify the outcome, including what you would not claim credit for.
- Name the disagreement or constraint, and how you resolved it with evidence.
- Pick a story where you drove the decision, not one where you observed it.
Follow-up
- What would you do differently if you ran that project again?
- How did you know the outcome was caused by your change?
Defend a flat result on a flagship discovery launch
A new ranker ran to 50 percent of accounts for four weeks. Your read: qualified hours per active account-week is +0.4 percent with a 95 percent interval of [-0.9 percent, +1.7 percent]. Meanwhile the share of qualified streams with start_source = 'algorithmic_slate' rose six points and the share with start_source = 'search' fell five. The team reads the slate shift as the win and wants to ship. The launch review is Friday. Deliverable: a five-minute verbal position and the one table you put on the screen.
Approach
- The probe is whether you can hold a position under social pressure without overclaiming in the other direction. Separate the two claims explicitly: the start-source shift is well measured and real; the hours effect the launch was justified on is not distinguishable from zero at this sample size. Those are different statements and only one is contested.
- Do the power arithmetic before the meeting, using the observed per-account variance on a right-skewed hours metric. Arrive able to say "at this n we could not have detected less than X percent", which is a fact, instead of "it didn't work", which is an opinion the room can simply disagree with.
- Show the substitution as arithmetic, not interpretation: decompose treatment hours by start_source and show slate hours rising by approximately what search hours fell. A start-source mix shift with no change in total is exactly what displacement looks like, and the decomposition sums to the total so there is nothing to argue about.
- Refuse the symmetric overclaim. The interval's upper bound is commercially meaningful, so "the ranker does nothing" is not supportable either; say that out loud, because it is what makes the rest of your position credible.
- Offer the falsifiable next step with a price: a longer read powered for the hours effect, or CUPED on a pre-period consumption covariate measured before assignment, with the required account-weeks stated. Put the disagreement on the pre-registered metric, not on the team's judgement.
Follow-up
- The PM argues start-source mix is a leading indicator of retention. How would you test that claim, and how long would it take?
- Suppose the interval had been [+0.1 percent, +1.9 percent]. Does your position change, and by how much?
- The decision goes against your read and the ranker ships. What do you do on Monday?
Give an executive a number you are not sure of
An executive needs a figure for a board deck by end of day: the effect on month-6 paid retention of a dunning-schedule change that has been running nine weeks. Your estimate is +1.2 points with a 95 percent interval of [-0.3, +2.7], and the month-6 cohort has not matured — you are projecting from month-2 behaviour. They say "one number, no ranges, it's a board deck." Deliverable: the figure you supply, the single sentence that sits under it, and what you do if the sentence is deleted.
Approach
- The probe is whether you can be useful under a constraint you disagree with. Supply the number. A refusal gets replaced within the hour by someone else's number carrying no caveat at all, which is strictly worse than yours carrying a short one.
- Separate the two uncertainties, because they behave differently and only one shrinks with patience. Sampling error is the interval and narrows as weeks accumulate. Extrapolation error from month-2 to month-6 does not narrow at all and is bounded only by evidence.
- Bound the extrapolation empirically before the deck goes out: on the last several fully matured cohorts, check how closely month-2 retention predicted month-6, and report that spread. This converts "we are projecting" from a hedge into a number, which is the only form of caveat that survives a slide.
- Translate the interval into the decision rather than the statistic. The executive needs the range only where it flips an action, so say at which end of it the change stops paying for itself, and otherwise give the point estimate.
- Commit to the date the figure becomes an observation — the cohort reaching 180 days of age, with monthly and annual billing intervals reported as separate curves since an annual account has had no opportunity to churn before day 365 — and put that date in the footnote so the projection has an expiry.
Follow-up
- The deck ships with your number and the footnote removed. What do you do, and when?
- How does your answer change if the interval were [-1.5, +2.7] — wide and straddling zero more evenly?
- What is the difference between what you have produced here and a forecast, and does the executive need to know?
- 01
How do you handle disagreements with team members about data interpretation?
- 02
A new ranker ran to 50 percent of accounts for four weeks. Your read: qualified hours per active account-week is +0.4 percent with a 95 percent interval of [-0.9 percent, +1.7 percent]. Meanwhile the share of qualified streams with start_source = 'algorithmic_slate' rose six points and the share with start_source = 'search' fell five. The team reads the slate shift as the win and wants to ship. The launch review is Friday. Deliverable: a five-minute verbal position and the one table you put on the screen.
- 03
An executive needs a figure for a board deck by end of day: the effect on month-6 paid retention of a dunning-schedule change that has been running nine weeks. Your estimate is +1.2 points with a 95 percent interval of [-0.3, +2.7], and the month-6 cohort has not matured — you are projecting from month-2 behaviour. They say "one number, no ranges, it's a board deck." Deliverable: the figure you supply, the single sentence that sits under it, and what you do if the sentence is deleted.
Is this an official Redhorse interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Redhorse. Rounds and questions reflect what candidates have reported, not a process Redhorse has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult are interviews at Redhorse?
Interviews at Redhorse can be challenging, particularly in technical areas. Candidates should expect to prepare thoroughly, dedicating several weeks to review relevant concepts and practice problem-solving.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates often demonstrate a blend of technical expertise and strong communication skills. They can clearly articulate their thought process and collaborate effectively with others.
PracHub interview research ↗Can you describe the culture at Redhorse?
Redhorse fosters a culture of innovation, teamwork, and integrity. Candidates who align with these values and demonstrate a collaborative spirit are likely to thrive.
PracHub interview research ↗What is the typical timeline from the initial screen to an offer?
The interview process can take 4-6 weeks, depending on scheduling and team availability. Stay proactive during this time to express your ongoing interest.
PracHub interview research ↗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.
1010data Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for 1010data data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.
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.