The role of a Data Scientist at Rokt is pivotal in harnessing data to drive business decisions and enhance user experiences. As a Data Scientist, you will analyze vast datasets to extract actionable insights that contribute to the optimization of Rokt's products and services. Your work directly impacts customer engagement and revenue generation, making it an influential position within the organization.
At Rokt, Data Scientists collaborate closely with teams across product development, engineering, and marketing to solve complex problems. You will engage in projects that involve machine learning, predictive modeling, and data visualization, allowing you to work at the intersection of data and strategic business initiatives. The role is not only technical but also requires a keen understanding of business dynamics and customer behavior, giving you a unique opportunity to drive meaningful change within a high-scale, fast-paced environment.
Video Interview with Recruiter
reportedMost candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.
What to demonstrate
- Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
- Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
- The substance of the questions you ask back, which an experienced screener reads as a level signal
How to prepare
- Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
- Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
- Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered
Online Assessment
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
Technical Interviews
reportedThis round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.
What to demonstrate
- Whether your row counts survive each join, and whether you notice on your own when they do not
- Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
- Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
- Reaching a defensible answer inside the window instead of a refined one after it
How to prepare
- Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
- Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
- Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither
Collaboration Skills Assessment
reportedMuch of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.
What to demonstrate
- Whether the query you write matches the plan you just described
- What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
- Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly
How to prepare
- Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
- Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
- Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock
Discussion of Past Projects
reportedBecause the format is not fixed, prepare the reasoning rather than the ritual. Nearly every version of this round draws on the same underlying material: a design you can defend, a metric you can define exactly, an analysis whose assumptions you can state out loud. Only the wrapper changes, whether that is a take-home, a live case, a deep dive on past work, or a rough estimate on a whiteboard. Answers rehearsed to fit one shape stall the moment the shape differs. Practise naming the assumption behind a number, then saying how much the conclusion moves if that assumption is wrong.
What to demonstrate
- Whether your justification for a method survives the question 'why not the simpler thing', including when the simpler thing would have worked
- Precision under pressure: what exactly counts as an active user, a conversion or a success, over what window, with what exclusions
- Whether you carry an argument through to a recommendation instead of stopping at a list of tradeoffs
How to prepare
- For each project you plan to mention, write the metric definition in one sentence: numerator, denominator, time window, exclusions. Say it out loud once, because vagueness shows up in speech before it shows up on paper.
- Rehearse the same project at three lengths: two minutes, ten minutes, and a deep dive on one technical decision. Cutting live is harder than it sounds.
- For your headline result, write down what would have had to be true for it to be wrong, and how you ruled that out.
8 candidate reports. Individual accounts describe a particular role and hiring cycle.
Rokt Software Engineer interview with onsite coding, design, and leadership rounds
My process started with online aptitude and personality testing, followed by a behavioral evaluation and a one-way video interview where I recorded answers to a prompt. After those early steps, I was invited to an in-person onsite sequence with multiple parts. In the later rounds, the technical work shifted toward live problem solving and deeper evaluation. I worked through standard algorithmic c…
Read full experienceRokt Account Executive interview with two CCAT assessments and HireView
After applying, I went through a fast-moving assessment sequence centered on CCAT-style cognitive testing. I took two different CCAT versions, which felt a little odd and even useless to me, although the tests themselves weren’t especially hard. After reviewing my results, the recruiter scheduled a HireView step. It was short and not difficult, but I found the format oddly off-putting. I then mov…
Read full experienceRokt Software Engineer interview with coding, system design, and behavioral rounds
My process dragged on much longer than it should have. Recruiters were difficult to reach and gave me incorrect information about what the interviews would involve. Some interviewers also came across as though they didn't want to be there. At times, the whole process felt cold and stressful instead of inviting. Communication problems kept making the process feel unreliable. In some interviews, th…
Read full experienceRokt Software Engineer interview with a full-day bar raiser
The later stage became the most memorable part of my process, and not in a good way. After the earlier rounds, I was brought into an Amazon-style bar raiser interview. The tone felt scripted and as if the decision had already been made. The interviewer began by asking me to walk through a specific period from my resume. They mostly stayed quiet and gave very little feedback while I spoke. There w…
Read full experienceRokt Software Engineer interview: aptitude screen, LeetCode, and onsite rounds
I went through an assessment-heavy funnel that felt disconnected from actual software work. After applying, I completed a cognitive aptitude and personality-style screen, followed by a one-way video interview where I recorded responses to behavioral prompts. By then, the process already felt automated and generic. The later stages followed a more traditional technical path, but the pacing and com…
Read full experiencePracHub editorial advice for the preparation topics above.
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.
Counting plays without a qualification threshold, or changing the threshold without restating history.
Playback arrives as heartbeats, so a play only exists once you decide what counts, and the common 30-second convention is not a neutral analytics choice: in music it is also the boundary at which a play becomes payable, which makes the warehouse definition a payout definition. The threshold interacts violently with content length, so a catalogue of three-minute tracks and one of forty-minute episodes move in opposite directions when you change it, and a skip-heavy surface can add plays while adding no hours. Any metric mixing pre-threshold and post-threshold counts, or pooling short-form and long-form on a per-stream basis, moves by double digits for reasons that have nothing to do with the product.
Reading a dozen metrics with no multiplicity control
Nominate one primary metric before launch and treat the rest as guardrails or exploratory, with Bonferroni or Benjamini-Hochberg applied when you intend to make claims from them. Twenty independent tests at 0.05 under the null produce at least one false positive about 64 percent of the time.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
What evaluation metrics do you use to assess the performance of a clas…
What evaluation metrics do you use to assess the performance of a classification model?
Approach
- Check what information would not exist at prediction time, and exclude it.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
Design an experiment to test the effectiveness of a new recommendation…
Design an experiment to test the effectiveness of a new recommendation algorithm.
Approach
- Set a baseline first, so any model has something honest to beat.
- Say how the offline result would be validated online before it is trusted.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
Permutation test for hours per account across two ranker arms
arm_hours holds one row per account: account_id, arm in {control, treatment}, qualified_hours over a seven-day window. Roughly 40 thousand accounts per arm, about 38 percent of them at zero hours, and the non-zero tail is long. Without calling a library test function, write a permutation test on the difference in mean hours with 10,000 relabellings. Then run it as two parts: the difference in the share of accounts with any hours, and the difference in mean hours among accounts with hours. Report all three and say which belongs in the readout.
Approach
- Shuffle the labels, not the data. Draw a permutation of the arm indicator over accounts, which is the unit that was randomised, and hold the hours vector fixed.
- Make each replication O(n): precompute the grand sum and the arm sizes, so a shuffled difference is the treated subset sum over n_t minus (grand sum minus that subset sum) over n_c. Ten thousand replications then take seconds instead of a minute.
- Use the two-sided p-value (1 + count of permuted absolute differences at or above the observed) divided by (B + 1). The plus one is not cosmetic: it makes the p-value valid rather than optimistic, and it means the smallest reportable value here is 1/10001, not zero.
- For the two-part version, run the same machinery on the 0/1 indicator for the rate, then on the non-zero subset for the conditional mean, and say plainly that conditioning on a post-treatment outcome breaks the randomisation, so the conditional arm is descriptive rather than causal.
- Report the rate test and the overall mean test as the result, with the conditional mean as colour, and give the effect size in hours beside each p-value, because at 80 thousand accounts almost anything is detectable.
Worked solution 30 min
- Pull hours into a float array and arm into a boolean array; record n_t, n_c, the grand sum and the observed difference of means.
- Loop B = 10,000 times, taking np.random.permutation(n)[:n_t] as the treated index set and accumulating hours[idx].sum().
- Convert each shuffled treated sum into a difference of means, compare its absolute value against the observed, count, and apply the plus-one form.
- Repeat with hours replaced by (hours > 0).astype(float) for the rate test.
- Subset to hours above zero, re-run for the conditional mean, and assemble a three-row result carrying effect, p-value and the unit each is defined on.
Follow-up
- The permutation p-value on the mean is 0.03 and the rate test is flat. What is the most likely explanation, and does it change the decision?
- How would CUPED on pre-period hours change your power here, and what would disqualify a covariate?
- Accounts are households. Does that affect the validity of this test, or only its interpretation?
Given a list of integers, find all pairs that sum to a specific target…
Given a list of integers, find all pairs that sum to a specific target.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- State the window function and its partition and ordering out loud before writing it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
Write a function to calculate the Fibonacci sequence up to n.
Write a function to calculate the Fibonacci sequence up to n.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- Say which table is the grain you start from, and join outward from it.
Follow-up
- How would you verify this result without re-running the same query?
- How does the query change if the join becomes one-to-many?
Weekly engaged accounts from qualified streams on distinct days
fct_stream has one row per playback with account_id, started_at (UTC), played_seconds, is_qualified (true when played_seconds >= 30) and event_date, a date partition key derived from started_at. dim_account has account_id and is_test_account. Write one query returning, for the seven days ending 2026-03-31 inclusive, the count of weekly engaged accounts: distinct non-test accounts with at least one qualified stream on two or more distinct UTC dates inside that window. Return a single row. Count at the account level, not the profile level.
Approach
- Filter fct_stream on event_date BETWEEN '2026-03-25' AND '2026-03-31' and is_qualified = true. Filtering on started_at alone leaves the engine no partition to prune, so it reads every day the table holds; event_date is the partition key and is what belongs in the predicate.
- Drop test accounts before the date count, with a join or semi-join to dim_account on is_test_account = false. Excluding them afterwards is too late, because a test account that streamed on two days has already been counted as engaged.
- GROUP BY account_id and take COUNT(DISTINCT event_date) AS active_days. The distinct is the entire metric: an account with forty qualified streams inside one calendar day has one active day.
- Filter HAVING COUNT(DISTINCT event_date) >= 2, then wrap in an outer COUNT(*). The group-by has already made account_id unique, so an outer COUNT(DISTINCT account_id) adds a sort for nothing.
- Sanity-bound the answer before reporting it: it must be no larger than the count of distinct non-test accounts with any qualified stream in the window.
Worked solution 20 min
- Compute the ceiling first: COUNT(DISTINCT account_id) over non-test accounts with any qualified stream in the window.
- Build a CTE of (account_id, COUNT(DISTINCT event_date) AS active_days) over the filtered rows.
- Select COUNT(*) from that CTE where active_days >= 2.
- Re-run the final filter at >= 1 and >= 3 to see the shape of the distribution and confirm the metric is not being carried by accounts sitting exactly on the boundary.
Follow-up
- If you counted distinct dates per profile and then rolled up to the account, would the number rise or fall, and which unit does the metric actually want?
- An account plays one 40-second track at 23:58 and another at 00:03. That is two distinct UTC dates and therefore engaged. Is that the intent, and what would you change if not?
- Offline plays upload in bulk several days late with started_at backdated. Which part of this query silently changes when they land?
How would you approach predicting customer churn for an e-commerce pla…
How would you approach predicting customer churn for an e-commerce platform?
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
- Which segment would you cut first, and what would that rule out?
- What would you do if the primary metric and the guardrail moved in opposite directions?
Discuss how you would analyze user engagement metrics to improve a pro…
Discuss how you would analyze user engagement metrics to improve a product.
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- Restate the decision this analysis has to support, and who acts on the answer.
- 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?
- Which segment would you cut first, and what would that rule out?
How would you prioritize features for a data product?
How would you prioritize features for a data product?
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
- 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?
Given a dataset, how would you identify trends and patterns?
Given a dataset, how would you identify trends and patterns?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- Which segment would you cut first, and what would that rule out?
- What would you do if the primary metric and the guardrail moved in opposite directions?
Explain the difference between supervised and unsupervised learning.
Explain the difference between supervised and unsupervised learning.
Approach
- Work from the decision backwards to the evidence you would need.
- State your assumptions explicitly before working the problem.
- 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?
Read a test that won early and faded late
A ranker test was declared for 21 days at 80 percent power for a 1.0 percent lift in qualified hours per account-week, alpha 0.05 two-sided, with every eligible account ramped on day one. The team watched a daily dashboard. It crossed p < 0.05 on day 3 reading plus 2.9 percent, read plus 1.7 percent at p = 0.002 on day 9, and at day 21 reads plus 0.6 percent at p = 0.09. The same dashboard reports weekly slices of plus 2.1, plus 0.4 and minus 0.7 percent. Reconcile the cumulative readings against the slices and against the declared power before interpreting either, say what the day-21 p-value is worth given the daily looks, and say what you would run next.
Approach
- Reconcile the dashboard against itself before interpreting anything on it. With a day-one ramp, exposure is roughly flat across the window, so each cumulative estimate must be the day-weighted average of the slices beneath it, and the declared MDE pins the standard error at the horizon. Both the point estimates and the p-values are checkable arithmetic; a cumulative that does not match its own slices is computed on a different population and neither number is usable.
- Separate the arithmetic from the decision. Because the test ran to its pre-declared 21-day horizon and nobody stopped, the day-21 p-value is a valid fixed-horizon p-value needing no correction. What the daily looks damaged is the decision rule, not this number.
- Quantify what stopping would have cost. Under the null, repeated significance testing on accumulating data at alpha 0.05 gives a true error rate near 14 percent at five looks, 19 percent at ten and roughly 25 percent at twenty, so shipping on day 3 was a bet at those odds.
- Recognise the day-3 estimate as conditioned on having crossed. An effect read at the moment it becomes significant is selected for being large, so it is biased upward before any decay argument is made.
- Re-index the effect on days since each account's first exposure rather than on calendar date. Novelty appears as a per-account effect decaying with exposure age; a calendar decay that vanishes under re-indexing is a release or a mix shift.
- Separate novelty from primacy by tenure. Accounts created after the change never saw the old surface, so a genuine novelty effect is absent or much smaller in them, while primacy has the opposite sign and grows with exposure.
- Distinguish the cumulative from the steady state. A cumulative estimate over a decaying profile is an average of a launch effect the product delivers once and a post-novelty effect it delivers forever. Neither is the other, and the second is the one a ship decision needs.
- Conclude at the declared horizon: not significant at 0.05, a cumulative effect around plus 0.6 percent whose post-novelty component is not separable from zero, and any further looking requires an alpha-spending boundary fixed in advance.
Worked solution 25 min
- Reconcile the cumulative readings against the slices. Day 9 = (7 * 2.1 + 2 * 0.4) / 9 = 15.5 / 9 = 1.72 percent, matching the reported plus 1.7. Day 21 = (2.1 + 0.4 - 0.7) / 3 = 0.6 percent, matching the reported plus 0.6. Back out the within-week-one profile too: days 1 to 3 at plus 2.9 forces days 4 to 7 to average (7 * 2.1 - 3 * 2.9) / 4 = 1.5 percent, so the per-day path is 2.9, 1.5, 0.4, minus 0.7, monotone decay.
- Reconcile the p-values against the declared power. 80 percent power for 1.0 percent at alpha 0.05 two-sided fixes the day-21 standard error at 1.0 / 2.802 = 0.357 percent, so z = 0.6 / 0.357 = 1.68 and p = 0.09. Scaling the standard error as 1 / sqrt(t) gives 0.545 percent at day 9 (z = 3.12, p = 0.002) and 0.944 percent at day 3 (z = 3.07, p = 0.002). Every reported number falls out of the design; none of them has to be taken on trust.
- Recompute the day-21 estimate outside the dashboard with one row per account and the pre-registered cap, and confirm plus 0.6 percent at p = 0.09 reproduces.
- Rebuild the series indexed on days since first exposure per account rather than calendar day, and plot the treatment effect against exposure age 1 to 21.
- Split the day-21 estimate by tenure at assignment: accounts created after the change versus accounts with 90 or more days of history.
- Check the release and rights calendar inside the window, and confirm the week-one lift is not one arm's share of a release landing.
- Estimate the steady state from the week-three slice alone: minus 0.7 percent with a one-week standard error of 0.357 * sqrt(3) = 0.618 percent, so z = minus 1.13 and p = 0.26. It is not separable from zero, and it is the quantity the follow-up must be powered on.
Follow-up
- Specify a boundary that lets the team look daily and still ship at 5 percent. What does an O'Brien-Fleming boundary cost in final-look MDE compared with a Pocock boundary?
- The team proposes re-running the test powered for plus 0.6 percent. What is wrong with that target, and which quantity should the follow-up be powered on instead?
- What would primacy look like on this dashboard, and which metric would register it first?
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.
Saying no well is a senior skill and it is rarely rehearsed. Think of a time you told someone their analysis was not worth doing, or that the experiment could not answer their question at the sample size available. Explain what you offered instead. Refusal without an alternative reads as obstruction rather than judgement.
What motivates you as a Data Scientist, and how do you stay updated in…
What motivates you as a Data Scientist, and how do you stay updated in the field?
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Name the disagreement or constraint, and how you resolved it with evidence.
- Close with what you would do differently, concretely.
Follow-up
- What would you do differently if you ran that project again?
- How did you know the outcome was caused by your change?
Announce a stream-definition change that shifts payouts
You find that the 60-second idle gap used to sessionise heartbeats into fct_stream rows splits one continuous listen into two streams whenever a phone backgrounds briefly on cellular. Correcting the gap lowers qualified stream counts on phones by an estimated four percent; total played_seconds is unchanged. Per-stream counts drive rights-holder payout shares. Deliverable: what you verify before telling anyone, the order in which you take it to the engineering owner, finance and content partnerships, and your recommendation on restating history.
Approach
- The probe is whether you can tell a technical correction from a commercial decision and keep them apart in the room. Verify the split streams are genuinely one listen before anything else: same profile_id, same content_version_id, contiguous max_position_seconds across the boundary, and a gap distribution with a spike at the background-timeout duration rather than a smooth tail.
- Compute the distributional effect, not the average. The four percent aggregate is not what anyone will argue about; recompute under the corrected gap and report which rights_holder_id groups gain and lose share, because short-form catalogue on mobile is where the splits concentrate and that is not spread evenly across counterparties.
- Defend the new rule on its own terms rather than on the direction of the number. The idle gap is a choice, so the argument is evidence that the two rows describe one continuous listen — never that the corrected count is lower and therefore more conservative, which invites the symmetric accusation next time the fix goes the other way.
- Name the ownership boundary out loud: engineering owns the sessionisation rule, finance and partnerships own whether payouts are restated. Conflating them is how a correct fix gets blocked by a commercial objection it should never have been exposed to.
- Sequence the conversations so the number stops moving before it leaves the building: engineering owner first to confirm the rule and land the fix, finance second to size the restatement, partnerships last. Recommend restating history for internal metrics so trends stay comparable, and recommend against retroactive payout adjustment unless the contracts require it — naming who must answer that contractual question rather than answering it yourself.
Follow-up
- Partnerships asks you to hold the fix until after the quarter closes. What do you do, and who else needs to know you were asked?
- How do you present a change that raises some counterparties' shares and lowers others', in the same meeting, to people who will compare notes afterwards?
- The four percent estimate itself has an interval spanning roughly two to seven percent. Does that change the recommendation or only the sequencing?
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
What motivates you as a Data Scientist, and how do you stay updated in the field?
- 02
You find that the 60-second idle gap used to sessionise heartbeats into fct_stream rows splits one continuous listen into two streams whenever a phone backgrounds briefly on cellular. Correcting the gap lowers qualified stream counts on phones by an estimated four percent; total played_seconds is unchanged. Per-stream counts drive rights-holder payout shares. Deliverable: what you verify before telling anyone, the order in which you take it to the engineering owner, finance and content partnerships, and your recommendation on restating history.
- 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 Rokt interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Rokt. Rounds and questions reflect what candidates have reported, not a process Rokt has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult are the interviews for the Data Scientist role?
The interviews are generally challenging, as they require a solid understanding of both technical concepts and business applications. Candidates should thoroughly prepare to demonstrate their expertise.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates often showcase a blend of deep technical knowledge, effective communication skills, and a strong alignment with Rokt's culture and values.
PracHub interview research ↗What is the typical timeline from the initial screen to an offer?
The interview process can take several weeks, depending on the number of candidates and team schedules. It's essential to stay engaged and follow up with the recruiter if there are delays.
PracHub interview research ↗Is remote work an option?
Rokt has embraced flexible work arrangements, including remote work opportunities, depending on the team's needs and the role's requirements.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Yahoo Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at Yahoo candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.
Warner Bros. Data Scientist Interview Questions & Guide 2026
Take-home style practice for data scientists preparing for Warner Bros.: a messy dataset, a fixed time budget, and a written analysis, reviewed for whether it states its assumptions and whether a reader could reproduce your numbers.
Tubi Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Tubi, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Spotify Data Scientist Interview Questions & Guide 2026
Case practice for the Spotify data scientist interview, where the prompt is deliberately underspecified and your first move is scoping it into something measurable.