As a Data Scientist at Strike Social, you sit at the intersection of high-scale advertising technology and advanced machine learning. Your work directly influences how the world’s top brands optimize their marketing spend across platforms like YouTube, TikTok, and Snapchat. You are not just building models; you are architecting the "brain" of a platform that manages massive, real-time datasets to drive tangible business outcomes.
This role is critical because Strike Social operates in a fast-paced, agile environment where the ability to turn raw data into predictive insights is the core product. You will collaborate closely with Data Engineering to integrate your models into microservices, ensuring that your algorithms are not just theoretically sound, but performant and reliable in a production environment.
The team culture at Strike Social is described as "work-hard/play-hard." You should be prepared to discuss how you thrive in small, high-impact teams where individual ownership and grit are highly valued.
Preparation focus
editorialNo round sequence has been reported for this company, so work the categories below and confirm the format with your recruiter.
What to demonstrate
- Breadth across SQL, experimentation and product reasoning
- Ability to state assumptions before choosing a method
How to prepare
- Drill the practice exercises below and time yourself
- Prepare three quantified stories about decisions you drove
PracHub editorial advice for the preparation topics above.
Reading engagement rates off impressions the ranker chose to serve
Engagement per impression by content type, author or topic is conditioned on the ranker's selection, and the ranker selected precisely what it predicted would be engaged with. A content type with a high observed engagement rate may simply be one the ranker only shows in easy contexts, and a type with a low rate may be one it shows indiscriminately. The same logic makes rank position a confounder: slot 1 outperforms slot 20 for reasons that have nothing to do with the item. Any counterfactual claim from this data needs either logged, strictly positive propensities and an inverse-propensity or doubly-robust estimator, or a randomised exploration slot. Where log_propensity is NULL because serving was deterministic top-k, no reweighting recovers the answer and an online test is the only option.
Using report volume as a measurement of how much violating content exists
Reporting is a member behaviour, not an observation of the content. Report counts rise when the report control is made easier to reach, when a coordinated campaign targets an account, and when the audience shifts toward people who object; they fall when violating content is shown mainly to members who agree with it. A ranker that gets better at matching bad content to receptive audiences will drive reports down and harm up at the same time. Prevalence must come from a random sample of served impressions with recorded selection probabilities, labelled by humans against the written policy, and reported with an interval. Reports are useful as a detection signal and as a demand-side complaint rate, not as a denominator-anchored measure of harm.
Extrapolating a first-week lift inflated by novelty effects
Plot the treatment effect by days since first exposure instead of quoting one pooled average. A lift that decays toward zero across the test window is behaviour that will not persist, and annualising it produces a forecast that misses by an order of magnitude.
Treating a non-significant result as proof of no effect
Say whether the confidence interval excludes the effect sizes you would have cared about. If it does not, the honest reading is that the test was underpowered, so report the minimum detectable effect the design could have found and what sample size would resolve it.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
What statistical methods do you use to validate the performance of mar…
What statistical methods do you use to validate the performance of marketing campaign predictions?
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Sanity-check the answer against a simple bound or a simulated case.
- Translate the result into the decision it informs, in one plain sentence.
Follow-up
- How would you explain this result to someone who does not know statistics?
- What sample size would you need to detect an effect half this size?
How would you handle a situation where your model performance degrades…
How would you handle a situation where your model performance degrades over time in a production environment?
Approach
- Check what information would not exist at prediction time, and exclude it.
- Set a baseline first, so any model has something honest to beat.
- Pick an evaluation metric that matches the cost of each error type, not a default.
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?
How do you approach feature engineering for large-scale, multi-platfor…
How do you approach feature engineering for large-scale, multi-platform advertising data?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- 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.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- Where could label leakage enter this setup?
Off-policy estimate with a positivity and weight audit
logged has impression_id, rank_position, reward (1 if the viewer engaged), log_propensity (float, NULL where serving was deterministic top-k) and target_propensity (the candidate policy's probability of placing the same item in the same slot, precomputed). Estimate the candidate policy's engagement rate per impression with inverse propensity scoring and with self-normalised IPS. Report the effective sample size as the square of the sum of weights over the sum of squared weights, the 99th percentile weight, the share of rows excluded for NULL or near-zero propensity, and the estimate under weight clipping at 20. State precisely what population your number describes.
Approach
- Audit before estimating. Split the rows into three buckets: usable (log_propensity strictly positive and recorded), NULL propensity, and positive but below a floor you choose and state. The NULL rows come from deterministic top-k serving, where no reweighting identifies the counterfactual, so they are not a data gap to impute; they are outside what this method can answer.
- Compute w = target_propensity / log_propensity on the usable rows. IPS is the mean of w * reward. It is unbiased under positivity and no unobserved confounding, and it has the variance problem that makes the rest of this exercise necessary.
- Compute SNIPS as sum(w * reward) / sum(w). It carries a small bias that vanishes with sample size, it is bounded inside the reward range so it cannot return an engagement rate above 1, and it is usually the number you would report.
- Report the effective sample size (sum w)^2 / sum(w^2) next to n. It is the honest denominator: 400,000 rows with ESS 3,100 is a 3,100-row estimate, and quoting the raw n next to a confidence interval derived from these weights is the way this analysis misleads people.
- Clip weights at the stated threshold, recompute, and describe the trade in the right direction: clipping caps variance and introduces downward bias wherever the target policy wants to act in regions the logging policy rarely visited, which is exactly where the candidate ranker differs most.
- State the estimand explicitly. After excluding the NULL and sub-floor rows, the number describes the sub-population of impressions where the logging policy explored, which is not the surface as a whole, and the decision that follows is whether to run an online test or add randomised exploration slots.
Worked solution 40 min
- Bucket the rows: usable = logged.log_propensity.notna() & (logged.log_propensity >= floor); report counts and impression share for usable, null, and below-floor
- u = logged[usable]; w = u.target_propensity / u.log_propensity
- ips = (w * u.reward).mean(); snips = (w * u.reward).sum() / w.sum()
- ess = w.sum()2 / (w2).sum(); p99 = w.quantile(0.99)
- w_clip = w.clip(upper=20); ips_clip = (w_clip * u.reward).mean(); snips_clip = (w_clip * u.reward).sum() / w_clip.sum()
- Write the estimand sentence naming the excluded share and the surface it no longer covers
Follow-up
- Sixty percent of rows have NULL log_propensity. What do you change about the serving system to make this analysis possible next quarter, and what does it cost?
- Add a doubly-robust estimator on top of this. What does the reward model buy you, and what happens when it is wrong?
- The offline estimate says plus 4 percent and the online test comes back flat. Give two mechanisms that produce exactly that pattern.
Compare engagement on first delivery versus later re-deliveries
fct_feed_impression(impression_id, event_date, viewer_member_id, content_id, served_at_utc, rank_position) records every delivery, and the same item can be served to the same viewer many times. fct_engagement_event(impression_id, action_type, is_negative_feedback, undone_at_utc) links an action back to the impression it came from. For one week, compute positive engagement rate per impression split by delivery ordinal for a fixed viewer-content pair: first delivery, second, third, fourth or later. Return the ordinal bucket, impressions, engaged impressions and rate.
Approach
- Number the deliveries with ROW_NUMBER() OVER (PARTITION BY viewer_member_id, content_id ORDER BY served_at_utc, impression_id). The impression_id tiebreak makes the numbering deterministic when two rows share a timestamp, which matters because re-deliveries in one scroll can land in the same millisecond.
- Bucket the ordinal to 1, 2, 3 and 4-or-later rather than reporting a long tail. The far tail is sparse and its rate swings on a handful of viewers.
- Deduplicate the engagement side to one row per impression_id before joining. A viewer can like and comment on the same impression, and counting both makes engaged impressions exceed impressions in the bucket.
- Aggregate by summing numerator and denominator per bucket and dividing once. Averaging per-viewer rates answers a different question and is dominated by light viewers, who have one impression and a rate of 0 or 1.
- Say plainly that the resulting curve is not a causal read on re-delivery. The ranker decides what to re-serve and re-serves what it predicts will be engaged with, and rank_position also differs systematically across ordinals. Controlling for rank_position narrows the gap without closing it.
Worked solution 30 min
- CTE ranked: the week's impressions with ROW_NUMBER() OVER (PARTITION BY viewer_member_id, content_id ORDER BY served_at_utc, impression_id) AS ordinal.
- CTE eng: SELECT DISTINCT impression_id FROM fct_engagement_event WHERE event_date in the window AND is_negative_feedback = FALSE AND impression_id IS NOT NULL, applying whichever undone rule you declared.
- LEFT JOIN eng onto ranked on impression_id and set bucket = LEAST(ordinal, 4).
- GROUP BY bucket: COUNT() AS impressions, COUNT(eng.impression_id) AS engaged, 1.0 * COUNT(eng.impression_id) / COUNT() AS rate.
- Check the shape of the ordinal distribution before interpreting the rates: bucket 1 should hold exactly the distinct viewer-content pair count for the week.
Follow-up
- Re-deliveries show a higher rate than first deliveries. Does that mean re-showing content is good?
- Design the exploration slot or experiment that would actually answer the question this query cannot.
- The same query cut by rank_position shows slot 1 at four times slot 20. What is that number measuring?
Count creators reaching fifty distinct viewers in a week
Using fct_feed_impression(event_date, viewer_member_id, content_id, author_member_id) and fct_content_item(content_id, author_member_id, item_kind), count members who published an original item that reached at least 50 distinct viewers during one calendar week. A re-delivery of the same item to the same viewer is a separate impression row. Reach is measured per item, not pooled across an author's items. Return one row per qualifying author with the distinct-viewer count of their best item. Replies, reposts and quotes are excluded.
Approach
- Filter fct_content_item to item_kind = 'original' first. The join then does double duty as a filter and keeps reply and repost deliveries out of the impression scan entirely.
- Aggregate impressions with COUNT(DISTINCT viewer_member_id) per content_id. COUNT(*) answers a different question — deliveries, not people — and the two diverge by however aggressively the ranker re-serves an item.
- Filter the per-item counts at 50, then group up to author_member_id taking MAX of the per-item reach. The definition is one item reaching 50 viewers, not 50 viewers accumulated across several items, and pooling would let three items of 20 viewers qualify a creator who never reached anyone.
- Use fct_feed_impression.author_member_id wherever the author is needed. It is denormalised precisely so reach and concentration queries avoid joining the largest fact in the warehouse; the join to fct_content_item is only for item_kind.
- Filter the week on event_date, which is already viewer-local. Mixing it with a UTC timestamp predicate on served_at_utc would include or drop a sliver of the boundary days depending on the viewer's offset.
Follow-up
- Extend this to retained reaching creators: qualified in week w and again in week w+1, divided by those qualified in week w.
- Why might this count rise in a week when the total number of publishes fell?
- An item was removed by moderation on day 6 of the week. Should the impressions it earned on days 1 through 5 still count toward its reach?
Can you explain the trade-offs between black-box models and more inter…
Can you explain the trade-offs between black-box models and more interpretable, bespoke solutions?
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.
- Decompose the metric into the rates that drive it, and say which one you would check first.
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?
Apply CUPED when eighteen percent of members lack history
You are powering a 14-day home_feed test on qualified sessions per member. Fourteen days of pre-assignment history are available per member, and the pre-period count correlates 0.60 with the in-test count. Eighteen percent of assigned members registered after the pre-period opened and have no history at all. Deliver the adjusted estimator you would use, the variance reduction it buys, your handling of the 18 percent, and one condition under which the adjustment silently biases the result toward zero.
Approach
- Write the estimator: Y_adj = Y - theta (X - Xbar), with theta = Cov(X, Y) / Var(X) estimated pooled across both arms. Because X is measured strictly before assignment, its expectation is equal across arms and the adjusted arm difference is unbiased for the same estimand as the raw difference.
- Quote the gain where it actually applies: Var(Y_adj) = Var(Y) (1 - rho^2), so rho = 0.60 buys a 36 percent variance reduction among the 82 percent of members who carry a covariate and nothing among the 18 percent who do not. The sample-wide reduction is the stratum-share-weighted blend of the two, always smaller than 36 percent, and it is the blend that sets the sample size.
- Handle the members with no history by adjustment, not deletion: set X to zero for them and add the missingness indicator as a second covariate, or equivalently stratify into has-history and no-history strata, adjust inside the has-history stratum only, leave the other unadjusted, and pool the arm differences by stratum share. Setting X to zero without the indicator is the error, because it asserts a new member had zero pre-period sessions rather than an unmeasured count, and it drags theta toward zero. Centring covariates and interacting them with the treatment indicator keeps the estimator consistent even if the linear form is wrong.
- Say why deletion is worse than it looks: tenure is pre-treatment, so restricting is not biased, but it changes the estimand to tenured members only and discards the newest cohort, which is the group whose response to a feed change is most likely to differ.
- Name the failure mode: any covariate whose measurement window overlaps exposure absorbs part of the treatment effect, shrinking the estimate toward zero while the variance still falls, so it looks like a clean win. This is the reason theta is fitted on pre-period data and the covariate window is required to close before assignment.
- Stack stratification on top only where it explains variance the covariate does not: post-stratify on platform, country and tenure bucket with weights fixed in advance, and report the incremental reduction so the complexity is justified by a number.
Worked solution 25 min
- Confirm the covariate window closes strictly before the assignment timestamp for every member.
- Estimate theta pooled across arms, then form Y_adj member by member.
- Build the two strata (has history, no history), adjust within the first, and pool the arm differences weighted by stratum share.
- Compute the within-stratum variance ratio 1 - rho^2, blend it with the unadjusted stratum weighted by stratum share, and only then convert the blended ratio into a revised sample size against the unadjusted baseline.
- Check covariate balance across arms before reporting anything.
Follow-up
- Treatment changes who is eligible to enter the analysis. Can you still use CUPED, and what breaks first?
- How does the adjustment combine with a cluster-randomised design?
- Your best available covariate has rho = 0.15. Is it worth using, and what would you look for instead?
Reactivated users spiked the week the frequency cap loosened
DAU rose 3.1 percent. The four-class flow shows reactivated up 41 percent and retained down 1.2 percent. In the same week the push frequency cap loosened, so fct_notification_decision shows more rows with decision = 'sent' and far fewer with suppression_reason = 'frequency_cap'. holdout_group assignment has been stable for 28 days. Establish two things: whether the reactivated rise is partly an artefact of how a qualified session is bounded, and what share of it notifications actually caused. Deliverable: a launch or revert recommendation with the cost priced.
Approach
- Run the partition check first: the four classes must sum exactly to DAU on every day. If they do not, the classification logic is the story and everything downstream is noise.
- Test the measurement artefact before the causal question. Reactivated requires no qualified session on d-1 with one somewhere in d-28 to d-2, and a qualified session needs 30 or more foreground seconds plus a non-negative engagement or an authored item. If the sessionisation inactivity gap shortened in the same release, one visit splits into two shorter sessions and either may fail the 30-second test, which makes a previously retained member read as inactive on d-1 and therefore reactivated on d. Recompute both weeks under one fixed definition version to settle this.
- Follow individuals rather than aggregates across the boundary. Reactivated rising while retained falls is exactly the signature of reclassification, so take the members classified reactivated this week and check what class they held in the comparable prior week. Aggregate class counts cannot distinguish reclassification from genuine return.
- Only now attribute causally, and only against the holdout: qualified sessions per member in holdout_group = 'send' minus qualified sessions per member in holdout_group = 'holdout_global', denominated in sends per member in the send arm. Never compare members who opened a push against those who did not, since opening is produced by the same intent the notification is supposed to create.
- Price the cost over the full 28-day window: growth in suppression_reason = 'opt_out', delivered but never opened volume, and negative feedback per 1,000 impressions. Frequency response is non-linear, so an incremental rate per send estimated at the old volume does not extrapolate to the new one, and the per-send incremental rate can fall while the total still rises.
- Recommend on the pair, not the headline: state incremental qualified sessions gained, opt-outs spent, and the exchange rate, then give a launch, hold or partial re-tighten decision that names which number would reverse it.
Follow-up
- The cap change was global, so there is no concurrent product control. Is the standing holdout arm still a valid control here, and under what conditions does it stop being one?
- How long must the window be before you trust the opt-out cost, given that uninstalls are invisible in this schema?
- Incremental sessions per send fell while total incremental sessions rose. Do you keep the looser cap?
For a candidate whose interviews will centre on A/B testing, metric movement and causal claims. Design comes before arithmetic, arithmetic before analysis, and the week ends by rehearsing the readout rather than the derivation.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Design one test end to end on paper
- Take a single feature change and write the full design: randomization unit, the exact point of exposure, the primary metric with its grain, guardrails, allocation, planned duration, and the decision rule committed before any data exists.
- Write why the randomization unit must sit at or above the level where treatment can spill over, and give one case where user-level randomization is still contaminated (shared accounts or devices, or two participants in the same marketplace).
- State in advance what you will do if the primary metric is flat while a secondary metric is significant.
Deliverable: A one-page test design with a decision rule written before launch.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Power arithmetic until it is automatic
- Compute required sample size per arm for a binary metric with the normal approximation, n is approximately 2 times (z for alpha/2 plus z for power) squared times p(1 minus p) divided by delta squared, for baselines of 2, 10 and 40 percent at a 5 percent relative lift, and note that for a fixed relative lift the requirement falls as the baseline rises because delta grows proportionally with p.
- Redo the calculation for a continuous metric using variance in place of p(1 minus p), and show why a heavy-tailed quantity such as revenue per user needs either far more traffic or a capped version with a stated cap.
- Convert one of the results into weeks given a weekly eligible traffic figure, then list the two honest ways to shorten it (accept a larger detectable effect, or reduce variance) and write why quietly lowering the power target is a decision to miss more real wins, not a speedup.
Deliverable: A small script or sheet that maps baseline, minimum detectable effect, alpha and power to sample size and weeks, cross-checked against a published calculator.
Practice prompt ↗Practice prompt ↗03Variance and the unit-of-analysis problem
- Take a ratio metric whose denominator is not the randomization unit (clicks per session, randomized by user) and compute the standard error twice, once naively at session level and once by the delta method or a user-level bootstrap, then record how much the naive version understates it.
- Implement CUPED on simulated data: choose a pre-period covariate X measured before assignment, estimate theta as Cov(Y, X) divided by Var(X), and analyse Y minus theta times (X minus its mean) in place of Y. Confirm the variance of the adjusted outcome equals the raw variance multiplied by one minus the squared correlation between Y and X, so a correlation of 0.45 removes about 20 percent of the variance and not 80.
- Now run that simulation a few hundred times and confirm the adjusted effect estimate is unbiased for the same effect rather than numerically identical to the raw one. Within any single run the two differ, sometimes by a large fraction of the true effect, because the two arms' pre-period covariate means never coincide exactly in a finite sample; they agree in expectation, which is the property that matters and the one to state out loud.
Deliverable: A notebook showing the adjusted estimator with a measurably smaller variance than the raw one, plus a repeated-simulation table showing the two estimators agreeing on average while differing run by run.
Practice prompt ↗Practice prompt ↗04Validity threats you can actually test for
- Run a sample ratio mismatch check as a chi-square goodness-of-fit test against the intended allocation, and write the three causes you would chase first (assignment logged before exposure, an arm-specific redirect or load failure, bot filtering applied asymmetrically).
- Simulate peeking: generate A/A data, test daily at alpha 0.05 across 14 looks, record the inflated false positive rate, then apply an alpha-spending boundary or commit to a fixed horizon and confirm the rate returns to nominal.
- Write how you would separate a novelty effect from a durable lift using the treatment effect plotted against days since first exposure, and what shape would change your recommendation.
Deliverable: One table showing the peeking false positive rate before and after correction, plus a written SRM triage list.
Practice prompt ↗Practice prompt ↗Worked solution ↗05When randomization is not available
- Write the identifying assumption for difference-in-differences (parallel trends in the absence of treatment), then plot pre-period trends for two candidate control groups and justify rejecting one of them.
- Design a switchback test for a change where user-level randomization would leak across participants, choosing a time-block length against the carryover you expect and saying how you would detect carryover in the data.
- List what an interrupted time series or a synthetic control buys you and the one thing neither can rule out: an unobserved shock that coincides with the launch.
Deliverable: A one-page memo recommending a single quasi-experimental design and naming its weakest assumption explicitly.
Practice prompt ↗Practice prompt ↗06The readout query
- Write the assignment-to-exposure join that returns exactly one row per unit per experiment, and handle units appearing in both arms by excluding and counting them rather than silently keeping one.
- Compute the per-arm metric, its variance and the relative lift with a confidence interval in SQL, then reproduce the identical numbers in a notebook as a cross-check.
- Add a segment breakdown and write the sentence that keeps it from being p-hacking: segments declared in advance, everything else reported as exploratory and corrected for multiplicity.
Deliverable: A single query that outputs the full readout table, matched to a notebook recomputation.
Practice prompt ↗07Present it to someone who will not read the appendix
- Give a 10-minute readout of a real or simulated experiment in the order decision, number, uncertainty, caveat.
- Have your listener ask "can we ship it" in the case where the primary is flat and a guardrail moved, and answer with a recommendation rather than a request for more data.
- Rewrite your opening line so the recommendation lands before any methodology.
Deliverable: A one-page readout whose first line is the recommendation.
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.
Describe a time you had to explain a complex statistical concept to a …
Describe a time you had to explain a complex statistical concept to a non-technical stakeholder.
Approach
- Close with what you would do differently, concretely.
- 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.
Follow-up
- What would you do differently if you ran that project again?
- How did you know the outcome was caused by your change?
Recommend holding a ranker that lifts engagement and hides
A ranking change finished a four-week cluster-randomised test on the home feed. Impressions per engaged session rose 3.1 percent and authored interactions per weekly active member rose 0.4 percent. Negative feedback per 1,000 impressions rose 6 percent, concentrated in hide and not_interested; unfollow was flat. Creator reach concentration rose 1.4 points. The product owner has already briefed the launch upward. In ten minutes give your recommendation, the exchange rate you are applying between engagement and quality, and the specific result that would change your mind. You may request two extra cuts of the data.
Approach
- Put both movements on the same base before arguing about them. Negative feedback is denominated per impression, and impressions per engaged session rose 3.1 percent, so absolute negative actions per engaged session rose about 9.3 percent (1.06 times 1.031), not 6 percent. Say that number out loud; it is usually the first thing nobody has computed.
- Ask whether the negative feedback rise is broad or concentrated: report distinct actors per 1,000 impressions beside the event rate. A rise driven by more members hiding is a distribution problem that affects the median viewer; a rise driven by the same members hiding more is a targeting problem in a segment that may be separable.
- Connect the 1.4 point concentration move to the supply-side guardrail rather than treating it as a curiosity. Pull retained reaching creators by arm and the median viewer's negative feedback on impressions from sub-threshold creators. Concentration is the plausible mechanism that pays for the engagement, and it is paid in creator churn that a four-week window barely registers.
- Read the effect by week with the burn-in excluded, not pooled. A 0.4 percent authored-interaction effect that is 1.1 percent in week 1 and 0.1 percent by week 4 is novelty decay, not a lift. State whether the ranking model was frozen for the test; if it retrained on experiment data, the arms are not independent and a pooled estimate is not interpretable either way.
- Deliver the recommendation as an exchange rate the owner can argue with: this buys roughly N additional hides per additional authored interaction at current volume. Then name the falsifier, for example the week-4 authored-interaction effect holding above 0.3 percent with flat concentration and the negative feedback rise confined to a removable segment.
Follow-up
- The owner launches anyway. What do you instrument on day one, and what is your stop rule?
- Negative feedback rate depends on how reachable the hide control is. Did the treatment change any surface affordance, and how would you know?
- If concentration rose, does the cluster randomisation still hold? Whose feeds leaked into whose?
State the impact of your last six months without inflation
Summarise your last two quarters in five minutes, with numbers. For each claim state the decision it changed, the counterfactual (what would have been decided without your work), how the effect was measured (randomised read, before-after, or estimate), and who else has to be credited. Rank the projects by realised impact, not effort, and name the one that produced nothing. Do not present a shipped feature as your impact unless you can say what would have shipped otherwise.
Approach
- Structure every claim the same way so the interviewer can compare them: decision changed, counterfactual, measurement method, shared credit. A list of projects without counterfactuals is a job description, not an impact statement.
- Separate the two kinds of impact an analyst actually has and price them differently instead of converting both into a revenue figure. Decisions changed (a launch held, a cap not raised, a metric redefined before it locked in) are one kind; capability added (a definition, a holdout, a pipeline that later decisions ran on) is the other and usually compounds harder.
- Label the measurement honestly per claim. A randomised read supports a causal number; a before-after during a season or a marketing push supports a bounded statement at best. Saying which is which before being asked is the fastest credibility signal available in this question.
- Discount shared attribution out loud. A launch carries engineering, design and product with it, so claim the part your analysis moved: the decision that would have gone the other way, or the magnitude that was wrong until you corrected it.
- Name the project that produced nothing and say when you should have stopped it. Then rank by realised impact and be ready for the ranking to put your largest effort in third place, which is the point of the exercise.
Follow-up
- Which of these would have happened without you, roughly on the same timeline?
- What did you stop working on, and what was the signal that made you stop?
- How would your manager order this list differently, and why?
- 01
Describe a time you had to explain a complex statistical concept to a non-technical stakeholder.
- 02
A ranking change finished a four-week cluster-randomised test on the home feed. Impressions per engaged session rose 3.1 percent and authored interactions per weekly active member rose 0.4 percent. Negative feedback per 1,000 impressions rose 6 percent, concentrated in hide and not_interested; unfollow was flat. Creator reach concentration rose 1.4 points. The product owner has already briefed the launch upward. In ten minutes give your recommendation, the exchange rate you are applying between engagement and quality, and the specific result that would change your mind. You may request two extra cuts of the data.
- 03
Summarise your last two quarters in five minutes, with numbers. For each claim state the decision it changed, the counterfactual (what would have been decided without your work), how the effect was measured (randomised read, before-after, or estimate), and who else has to be credited. Rank the projects by realised impact, not effort, and name the one that produced nothing. Do not present a shipped feature as your impact unless you can say what would have shipped otherwise.
Is this an official Strike Social interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Strike Social. Rounds and questions reflect what candidates have reported, not a process Strike Social has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How long does the process usually take?
Candidates typically move through the process within a few weeks. The two-round structure is designed to be efficient.
PracHub interview research ↗Is this role fully remote?
Yes, Strike Social encourages remote work, though you should be prepared to operate in an Agile environment with regular communication via stand-ups.
PracHub interview research ↗What is the most common reason candidates do not move forward?
Often, it is a lack of experience with the "engineering" side of Data Science—specifically, the ability to turn models into production-ready microservices.
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.
TELUS Digital AI Community Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of TELUS Digital AI Community, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Suno Data Scientist Interview Questions & Guide 2026
Timed practice for Suno data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.
Reddit Data Scientist Interview Questions & Guide 2026
Data-quality drills for Reddit 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 genu
Patreon Data Scientist Interview Questions & Guide 2026
Timed practice for Patreon data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.