The role of a Data Scientist at tvScientific is pivotal in harnessing data to drive informed decision-making and optimize business operations. As a Data Scientist, you will play a crucial role in developing algorithms and statistical models that enhance the company's advertising and analytics solutions. This position is vital for transforming raw data into actionable insights that improve product performance, user engagement, and overall business strategy.
In this role, you will work closely with teams across various disciplines, including engineering, marketing, and product development, to ensure that data insights are effectively integrated into decision-making processes. You will tackle complex problems, ranging from user behavior analysis to campaign effectiveness, allowing you to significantly impact product offerings and customer satisfaction. The diversity of projects and the emphasis on innovation and scientific rigor in data analysis make this position both critical and intellectually stimulating.
Introductory Conversation
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.
Technical Screening
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
Technical Interviews
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
reportedThis round decides whether you owned a decision or watched one happen nearby. Interviewers for data roles listen for the point where the analysis stopped being a report and started changing what someone did, so build each story around that hinge: what was going to happen by default, what you found, and what happened instead. The most common weakness is a story that ends at delivery. If you can name the decision your work changed and the number that moved because of it, most follow-ups become easy.
What to demonstrate
- Whether the decision was yours to influence, or whether you are narrating a team outcome in the first person
- The counterfactual: what would have been done without your analysis, and why that default was worse
- How far your involvement ran past the handoff, and whether you checked that the change did what you predicted
How to prepare
- Pick three projects and write one sentence for each naming the decision-maker, the choice in front of them, and what they chose after seeing your work. If you cannot name a person and a choice, the story is not ready for this round.
- Reconstruct the baseline for your strongest project from the original query or dashboard rather than memory, so the before-number survives a follow-up asking where it came from.
- Prepare an honest version of a project where your recommendation was overruled, including what you did with the analysis afterwards.
PracHub editorial advice for the preparation topics above.
Reading a recent week's cost per action or return on ad spend before the conversion window has closed.
Spend for a period is final within hours, but conversions attributed to that period keep arriving for as long as the click window allows plus ingestion lag, and offline uploads can land weeks later. The denominator of cost per action is therefore systematically incomplete for recent dates, so recent CPA is biased high and recent ROAS biased low, and a dashboard comparing a fresh week to a matured week will show a regression that does not exist. The correct handling is to freeze a period only after click_window_days plus the observed ingestion lag, and to publish a maturation curve so readers can see how much of a given day's conversions have landed so far.
Comparing conversion rates between users who were exposed to an ad and users who were not.
Exposure is the output of a targeting and bidding system that ranks users by predicted conversion propensity, so the exposed group has a higher baseline conversion rate before the ad renders. The measured difference therefore estimates the quality of the targeting model, not the effect of the advertising, and it is biased upward by an amount that grows as the model gets better. The valid control is the set of users the system would have shown the ad to but deliberately did not, captured through a ghost-bid or public-service-announcement holdout that records auction wins without serving the advertiser's creative. Anyone who proposes matching or covariate adjustment to fix this should be asked what unobserved feature the bidder used that the matching model does not have.
SQL that silently fans out on a one-to-many join
State the grain of each table and the grain you want in the result before writing the join. Pre-aggregate the many side to the join key, or use EXISTS or a window function, and verify with a row count against COUNT(DISTINCT id) rather than trusting that the numbers look plausible.
Building features from data that postdates the prediction time
Check every feature against the timestamp at which the model would actually score, and drop anything computed from a window that includes or follows the label event. For a forecasting use case, split train and test by time rather than at random, and split by entity when the same entity recurs.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
What is the significance of p-values in hypothesis testing?
What is the significance of p-values in hypothesis testing?
Approach
- Write down the assumption the method needs before you use the method.
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Sanity-check the answer against a simple bound or a simulated case.
Follow-up
- Which assumption here is most likely to be violated in practice?
- What sample size would you need to detect an effect half this size?
Write a function to calculate the mean and standard deviation of a lis…
Write a function to calculate the mean and standard deviation of a list of numbers.
Approach
- Sanity-check the answer against a simple bound or a simulated case.
- Say what the estimate is of, and over what population it generalises.
- Write down the assumption the method needs before you use the method.
Follow-up
- What sample size would you need to detect an effect half this size?
- Which assumption here is most likely to be violated in practice?
How would you implement a decision tree from scratch?
How would you implement a decision tree from scratch?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Check what information would not exist at prediction time, and exclude it.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- What would you monitor after launch to know the model is still valid?
- Where could label leakage enter this setup?
Sessionise a device event stream with a 30-minute gap
events holds about 5 million unsorted rows: device_id (nullable, roughly 18% null), event_ts, event_type in {impression, click, landing_arrival, conversion}, line_item_id, value_usd (nullable). Define a session as a maximal run of events for one device_id in which consecutive events are at most 30 minutes apart. Assign a session_id to every sessionisable row and return a per-session summary with device_id, start_ts, end_ts, n_impressions, n_clicks, converted and total value_usd. Do not use a library sessionisation helper, and do not scan the frame more than once after sorting.
Approach
- Separate null device_id rows first and report their share. Null identity is a supply-source property, not random missingness, so grouping them under one null key would fabricate a single session spanning millions of unrelated events; excluding them means the summary describes identified traffic only, and that has to be said out loud.
- Sort once by (device_id, event_ts) with a deterministic tiebreak such as an event_type rank then a row id. Without a tiebreak, an impression and its click sharing a timestamp order differently between runs and the summary is not reproducible.
- Compute the boundary mask as (device_id != device_id.shift()) | (event_ts - event_ts.shift() > 30min) and take its cumsum as session_id. This is a grouped run-length in two vectorised operations: O(n log n) for the sort and O(n) afterwards.
- Create indicator columns (is_impression, is_click, is_conversion) before the groupby, then summarise with one named aggregation pass. Building each count from its own filtered groupby re-scans the frame per metric and violates the single-pass constraint.
- Assert the structural invariant rather than eyeballing it: within a device, sessions ordered by start_ts must be disjoint and increasing, every within-session consecutive gap at most 30 minutes, every between-session gap strictly greater.
Worked solution 25 min
- Split on device_id.notna(), record the null share, and keep the null rows aside rather than dropping them silently.
- Add an event_type rank column, sort by (device_id, event_ts, type_rank, row_id), and reset the index.
- boundary = (device_id != device_id.shift()) | (event_ts.diff() > pd.Timedelta('30min')); session_id = boundary.cumsum().
- Add is_impression/is_click/is_conversion indicators, then one groupby('session_id').agg giving device_id first, start_ts min, end_ts max, the three sums, converted as is_conversion.max() > 0, and value_usd sum.
- Run the invariant assertions per device on the summary before returning it.
Follow-up
- A conversion arrives three hours after the click and lands in its own session. Is that the right answer, and how does a session boundary differ from an attribution window?
- One device shows negative gaps from a clock four hours off. What does your boundary mask do with it, and what would you prefer it did?
- Make the 30 minutes a parameter. How would you choose it from the data rather than from convention?
Given a dataset, how would you identify outliers?
Given a dataset, how would you identify outliers?
Approach
- State the window function and its partition and ordering out loud before writing it.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
Follow-up
- What breaks if events arrive late or out of order?
- How would you verify this result without re-running the same query?
Daily effective CPM per line item from billable impressions
ad_impression has impression_id, served_ts TIMESTAMPTZ, line_item_id, billed_price_micros_usd BIGINT, is_billable BOOLEAN, ivt_status TEXT (valid, givt, sivt) and currency_code. billed_price_micros_usd is the amount charged for that single impression, in USD micros. Write one query returning, per line_item_id and per UTC calendar day over a supplied date range, the billable impression count, total spend in USD, and effective CPM meaning spend per thousand impressions. Count only rows with is_billable = TRUE and ivt_status = 'valid'. Order by day, then spend descending.
Approach
- Apply the two filters positively rather than by exclusion: is_billable = TRUE AND ivt_status = 'valid'. Writing ivt_status <> 'givt' silently keeps the sophisticated-invalid rows, which is the larger and later-arriving category.
- Bucket with (served_ts AT TIME ZONE 'UTC')::date rather than date_trunc('day', served_ts). date_trunc on a TIMESTAMPTZ resolves in the session's TimeZone setting, so the same query returns different day boundaries for two analysts on the same warehouse.
- Aggregate once: COUNT(*) and SUM(billed_price_micros_usd) grouped by line item and day. Everything else is arithmetic on those two columns.
- Collapse the unit conversion into a single divisor. Micros to USD is a division by 1e6, per-thousand is a multiplication by 1000, so eCPM = SUM(billed_price_micros_usd) / (1000.0 * COUNT(*)). Use numeric literals so a BIGINT sum is not divided with integer arithmetic.
- Return the impression count in the output, not just the rate. eCPM rises mechanically whenever cheap inventory is filtered out, so the rate is uninterpretable without the volume beside it.
Worked solution 15 min
- Count rows before and after the is_billable and ivt_status filters and note the drop; it is usually a few percent, and a sudden change in that drop is itself the finding.
- Bucket the day as (served_ts AT TIME ZONE 'UTC')::date so the result does not depend on anyone's session timezone.
- Group by (line_item_id, day) and emit COUNT(*) AS impressions and SUM(billed_price_micros_usd) AS micros.
- Derive spend_usd = micros / 1e6 and ecpm_usd = micros / (1000.0 * impressions) in an outer select over that aggregate.
- Order by day then spend_usd descending, and reconcile the top row against a line item whose spend you already know.
Follow-up
- eCPM rose 12% week over week while spend was flat. What are the candidate causes, and which column separates a price change from a mix shift?
- How do you compute a period-level eCPM across 30 days, and why is the mean of the 30 daily eCPMs a different number?
- currency_code is not always USD. What does billed_price_micros_usd mean on those rows, and what would you need before the sum is trustworthy?
How would you assess the impact of external factors on sales performan…
How would you assess the impact of external factors on sales performance?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- State what result would change your recommendation, so the answer is falsifiable.
- 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?
What steps would you take to analyze customer churn?
What steps would you take to analyze customer churn?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- State what result would change your recommendation, so the answer is falsifiable.
- Fix the population and the time window before naming any metric.
Follow-up
- Which segment would you cut first, and what would that rule out?
- How would you detect that the metric is being gamed rather than genuinely improving?
How would you approach measuring the effectiveness of a marketing camp…
How would you approach measuring the effectiveness of a marketing campaign?
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.
- Fix the population and the time window before naming any metric.
Follow-up
- Which segment would you cut first, and what would that rule out?
- How would you detect that the metric is being gamed rather than genuinely improving?
What motivates you to work in data science, and how do you stay update…
What motivates you to work in data science, and how do you stay updated on industry trends?
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.
- Fix the population and the time window before naming any metric.
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?
Discuss how you would design an A/B test for a new feature.
Discuss how you would design an A/B test for a new feature.
Approach
- Say whether units interfere with each other, and switch design if they do.
- Decide the analysis before seeing data, including how long it runs and when you look.
- Name the randomisation unit first; it decides the variance and what the test can detect.
Follow-up
- What would you do if you could not randomise at all?
- How would you handle interference between treated and control units?
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.
- Clarify what is being asked and what a complete answer would contain.
- State your assumptions explicitly before working the problem.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Price the trade between ad revenue and viewer retention
A supply-side change raises the number of ad slots per session. Expect eligible revenue per thousand bid requests to rise, and viewer negative feedback per thousand impressions and 28-day viewer retention to fall. The experiment can run four weeks. Deliverable: the primary metric, the guardrail, and a decision rule pre-registered before the readout — including the explicit rate at which you would trade retention for revenue, and how you handle the two quantities maturing at different speeds.
Approach
- Refuse the fake resolution up front. There is no metric definition that makes this trade disappear; the design task is to price it in advance so the decision is not made by whichever number is read first, or by whichever team reads it.
- Set the primary at the level of the trade, not of the impression. Ad load moves both price per opportunity and the number of opportunities, so a per-impression metric hides half the effect. Use revenue per active viewer over the full test horizon, or eligible RPM reported jointly with session volume so the volume term cannot be quietly dropped.
- Convert retention into the primary's units before the test starts. Estimate the value of a retained viewer from historical cohorts — revenue per viewer-month times expected remaining months under the observed churn hazard — so a 0.3-point retention loss becomes a dollar figure directly comparable to the RPM gain. State the assumption explicitly, constant hazard or a fitted survival curve, because the dollar answer is sensitive to which one you used.
- Handle the maturity mismatch honestly. In a four-week test only the earliest cohort has a full 28-day retention window, so retention is both late and underpowered. Pre-register a 14-day proxy validated against 28-day retention on historical cohorts, state its bias direction — it under-detects slow churn, so it is optimistic — and commit to a 28-day confirmation read before any full rollout.
- Write the decision rule with a tripwire. Ship if the dollarised net is positive at the lower bound of the retention confidence interval, not at the point estimate. Hard-stop regardless of revenue if negative feedback per thousand impressions crosses a fixed pre-set threshold, because that metric matures in days and leads the retention loss you cannot yet see.
- Name who owns the exchange rate. A data scientist can compute the frontier and the dollar conversion; choosing the acceptable rate is a business decision, and forcing that choice into writing before the readout is the point of the exercise.
Worked solution 40 min
- Compute historical viewer lifetime value under a stated hazard assumption and convert one retention point into dollars per thousand viewers.
- Run the power calculation for 28-day retention at the available sample and horizon, and write down the minimum detectable effect it actually supports.
- Validate the 14-day proxy against 28-day retention on past cohorts and record the direction and size of its bias.
- Write the dollarised net formula, evaluated at the lower confidence bound of the retention estimate.
- Write the pre-registration: primary, guardrail, proxy and its bias, the negative-feedback tripwire threshold, the ship rule and the confirmation read date.
Follow-up
- Revenue is up 6% and retention is down 0.2 points but not statistically significant. What is your recommendation?
- How would you detect the retention loss concentrating in high-value viewers while the average looks fine?
- If the 14-day proxy and the 28-day metric disagree at the confirmation read, which one governs and why?
Attributed conversions vanished for six hours, then partly returned
Attributed conversions for 3 September show a hole between 02:00 and 08:00 UTC. A re-query the next morning shows most of the missing conversion_event rows now present, but attribution_credit for those touchpoint dates is still low and CPA on the dashboard is still wrong. conversion_event has conversion_ts and received_ts; attribution_credit is keyed on (conversion_id, touchpoint_id, attribution_model, model_version) and carries computed_at_ts. Determine what broke, what is still broken, and specify the repair.
Approach
- Count conversion_event by received_ts hour, not by conversion_ts. An ingestion outage is a hole on the arrival clock; on the event clock it looks like a dip that mysteriously heals, which is why the second query disagrees with the first.
- Confirm the backfill on the event clock: for the affected conversion_ts hours, compare the row count at the first query against the count now, and read the received_ts of the recovered rows to pin the recovery window.
- Ask whether anything downstream ran during the hole. Take max(computed_at_ts) per touchpoint date in attribution_credit. A computed_at_ts inside the outage means credit was computed against a partial conversion set and, if the job is not re-run, will never see the recovered rows.
- Distinguish the two failures in the writeup because they have different owners and different fixes: upstream ingestion lost six hours and self-healed, while the downstream attribution run is non-idempotent in effect and needs an explicit re-run for the affected touchpoint dates.
- Re-run attribution for those dates only, then verify the fix moved the affected dates and left neighbouring dates untouched before republishing.
Follow-up
- How would you make the attribution job safe to re-run, and what does it cost to recompute a touchpoint date every day until its window closes?
- What alert would have caught this in under 30 minutes, and on which clock would it be evaluated?
- Which already-published numbers need a restatement note, and what do you say in it?
For someone who has spent the last year in notebooks, dashboards or modelling work and has not written raw SQL under time pressure. The first four days rebuild query fluency against a fixture you control and can verify by hand; the last three attach that fluency to the rest of the loop.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Build a fixture you can check answers against
- Create a local Postgres or SQLite database with four tables (users, sessions, events, orders) holding roughly 200 rows you generated yourself, so you know the contents well enough to predict every result.
- Deliberately seed the cases that break queries: a user with no sessions, a session with no events, two orders sharing a timestamp, a NULL in one join key, and one duplicated user row.
- Before writing any SQL, hand-compute five answers on paper (how many users placed at least one order, median orders per ordering user, and three others) and save them as the ground truth for the week.
Deliverable: A one-command seed script plus a text file of five hand-computed answers to grade every later query against.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Joins, filters and NULL semantics
- Answer "which users have no orders" three ways (LEFT JOIN with IS NULL, NOT EXISTS, NOT IN) and confirm that the NOT IN version returns zero rows once the subquery contains a NULL, because the comparison is never TRUE.
- Reproduce the LEFT JOIN that silently collapses to an inner join by putting a right-table predicate in WHERE, then fix it by moving the predicate into the ON clause, and record both row counts.
- Create a fan-out bug on purpose by joining orders to order_items and summing the order total, then correct it with a pre-aggregated subquery and explain in one line which table changed the grain.
Deliverable: One annotated .sql file holding the three join traps, each with the wrong result and the corrected result side by side.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Window functions and frames
- Write three window queries against the fixture: a running order total per user, the rank of each order within its user by value, and the day gap to that user's previous order, then check each against the day-one ground truth.
- Run ROW_NUMBER, RANK and DENSE_RANK over a column containing ties, print all three side by side, and write one sentence on when each is the correct choice.
- Switch one query from the default frame (RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, which is what you get when ORDER BY is present and no frame is written) to ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and explain why the output differs only when the ORDER BY column has duplicates.
Deliverable: Three verified window queries plus a short note explaining the RANGE versus ROWS difference in your own words.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04The four analytical query patterns
- Write a monthly retention grid: first order month per user, then months-since-first as the column, and verify that month zero equals the cohort size exactly.
- Sessionize the events table under a 30-minute inactivity rule using LAG plus a cumulative sum over a new-session flag.
- Build a four-step funnel that counts distinct users rather than events at each step, and state the rule you applied to a user who reaches step three without ever logging step two.
Deliverable: One file with the retention, sessionization and funnel patterns, each carrying a one-line note on the assumption it bakes in.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Write SQL the way you will have to write it live
- Set a 12-minute timer and solve three medium prompts in a plain editor with no execution and no autocomplete, then run them and tally syntax errors separately from logic errors.
- Narrate one solution aloud while writing it, stating the grain of each intermediate result (one row per user, one row per user-day) before you type its body.
- Rewrite your slowest solution as a CTE chain where every CTE name states its grain, and time yourself re-solving it from blank.
Deliverable: A recording of one narrated solution plus an error tally that separates syntax from logic.
Practice prompt ↗Practice prompt ↗06One day for everything that is not SQL
- Write the preconditions of the two-sample t-test from memory, then check them: independent observations, and a difference in means whose sampling distribution is approximately normal, which at large sample sizes follows from the central limit theorem rather than from normality of the raw values.
- Write the difference between an odds ratio from logistic regression and a relative risk, and state the condition under which the two are close (low outcome prevalence).
- Prepare a 90-second answer to "how would you know this model is any good" that names the metric, the baseline you would beat, and the cost of the errors you care about.
Deliverable: One page of notes covering test preconditions, the odds-ratio caveat and the model-quality answer.
Practice prompt ↗Practice prompt ↗07Full loop rehearsal
- Run a 45-minute mock with someone willing to interrupt: 20 minutes of SQL, 15 minutes defining a metric, 10 minutes on a past project.
- Re-solve from blank the two queries you were slowest on this week and compare the times against day five.
- Write a five-line answer to "walk me through a project" that puts a number in the first sentence and names the decision the work changed.
Deliverable: Mock feedback notes plus a timed project narrative you can deliver without reading it.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Interviewers here are not checking whether you can describe a project. They want the decision you made, why you made it under the information you had, and what changed afterwards that someone else could measure. A story that ends at 'I built a model' has no ending. Say what the model caused, or what you stopped doing because of it.
Describe a situation where you had to present complex information to a…
Describe a situation where you had to present complex information to a non-technical audience.
Approach
- Pick a story where you drove the decision, not one where you observed it.
- Quantify the outcome, including what you would not claim credit for.
- Close with what you would do differently, concretely.
Follow-up
- How did you know the outcome was caused by your change?
- What did you decide not to do, and why?
Defending a null incrementality result against a headline ROAS
Your geo holdout shows a retargeting line item's incremental conversions per $1,000 of spend are indistinguishable from zero. The same line item reports last-click ROAS of 8.3 and is the headline number in a renewal deck presented in six days. The account team believes your test is wrong; the advertiser has never questioned the 8.3. Deliverable: the internal case you make, the specific evidence you bring, the limits you concede, and the smallest reversible experiment you propose if your reading is rejected.
Approach
- The interviewer is probing whether you can hold an unpopular finding without turning it into a credibility fight, so open by granting that both numbers are computed correctly: last-click measures which touchpoint was nearest in time, the holdout measures what changed because of the spend. Framing attribution as 'wrong' converts a methodological point into a turf argument you will lose on relationship grounds.
- State the null as a bound rather than as zero. Report the minimum detectable effect the 20-market design could resolve and say 'we can rule out incremental ROAS above this value'. A null without an MDE is not a finding and is trivially dismissed as an underpowered test.
- Bring converging evidence from tables you already have, and say what each piece can and cannot show. Credit sensitivity: recompute the same conversion cohort under a second attribution_model, first-touch or even credit across in-window touchpoints, holding cohort and windows fixed, and report what share of the line item's credited volume survives; that bounds how much of the 8.3 is a property of the crediting rule rather than of the spend, and it is a sensitivity result, not a lift estimate. Harvesting signature: the share of retargeting-credited conversions whose user already had an earlier impression, click or site session inside click_window_days, together with the distribution of conversion_ts minus click_ts, where a heavy mass inside a few minutes is consistent with an ad served into a session that was already converting.
- Quantify both error directions before recommending anything: the spend at risk if you are right and ignored, and the renewal revenue at risk if you are wrong and act. This is what separates a defensible position from an ideological one.
- Propose the reversible version rather than the shutdown: a 20% budget reduction in half the matched markets for six weeks, powered against the MDE you just computed, with the analysis window extended past the flight by the click window plus ingestion lag.
Follow-up
- The account lead says telling the advertiser their favourite channel does nothing will cost us the renewal. How do you respond without either caving or escalating?
- What specific evidence would change your mind about this line item?
- How do you handle it if the budget-down test also comes back underpowered?
Claiming impact for three projects with honest counterfactuals
You are writing a performance self-review. Over two quarters you shipped a bid-shading recalibration, a rewrite of the click-through-rate query that fixed an invalid-traffic filter applied to only one side of the ratio, and an incrementality test that led to a line item being paused. Deliverable: for each, the number you would claim, the counterfactual you claim it against, and the portion of credit that belongs to someone else. One of the three has no defensible dollar figure. Say which, and what you claim instead.
Approach
- The interviewer is probing whether you apply the same causal standard to your own work that you apply to an advertiser's, so write the counterfactual for each claim before the number: what would the metric have been over the same period without this work?
- For the shading recalibration, compare clearing price and profit on won impressions at matched supply mix across exchange_id, ad_format, device_type and geo_country, and report the profit change rather than the win-rate change; under first-price clearing a higher win rate can accompany worse profit.
- For the query fix, claim the magnitude of the bias removed rather than a revenue number: the gap between the old rate, which filtered invalid traffic on the numerator only, and the corrected symmetric rate, plus the decision that was being made on the wrong figure.
- For the incrementality test, claim the decision, not the savings. The paused budget's fate was never measured, so any dollar figure would assume that money vanished rather than moved. This is the item with no defensible number.
- Name specific collaborators and what they contributed, and pre-empt the obvious challenge by stating the confound you know about, such as seasonality or supply mix drift, and the bound you put on it.
Follow-up
- Your manager points out the paused line item's spend simply moved to another line item. Does your claimed impact survive?
- How do you claim credit for work whose value is a bad decision that did not happen?
- 01
Describe a situation where you had to present complex information to a non-technical audience.
- 02
Your geo holdout shows a retargeting line item's incremental conversions per $1,000 of spend are indistinguishable from zero. The same line item reports last-click ROAS of 8.3 and is the headline number in a renewal deck presented in six days. The account team believes your test is wrong; the advertiser has never questioned the 8.3. Deliverable: the internal case you make, the specific evidence you bring, the limits you concede, and the smallest reversible experiment you propose if your reading is rejected.
- 03
You are writing a performance self-review. Over two quarters you shipped a bid-shading recalibration, a rewrite of the click-through-rate query that fixed an invalid-traffic filter applied to only one side of the ratio, and an incrementality test that led to a line item being paused. Deliverable: for each, the number you would claim, the counterfactual you claim it against, and the portion of credit that belongs to someone else. One of the three has no defensible dollar figure. Say which, and what you claim instead.
Is this an official tvScientific interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at tvScientific. Rounds and questions reflect what candidates have reported, not a process tvScientific has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult are the interviews at tvScientific?
The interviews are generally considered average in difficulty, focusing on both technical and behavioral aspects. Preparation is essential to navigate the technical assessments and showcase your problem-solving skills.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates demonstrate a strong grasp of data science principles, effective communication skills, and the ability to collaborate within teams. Highlighting past project experiences can set you apart.
PracHub interview research ↗What is the company culture like at tvScientific?
tvScientific promotes a culture of innovation and data-driven decision-making. Collaboration and scientific rigor are highly valued, making it important for candidates to align with these principles.
PracHub interview research ↗What is the typical timeline from initial screen to offer?
The interview process can vary, but candidates often receive feedback within a few weeks. It’s important to maintain communication with your recruiter for updates.
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.
Truliant Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for Truliant data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.
StackAdapt Data Scientist Interview Questions & Guide 2026
Experiment-design practice for StackAdapt data scientist candidates, covering randomisation units, power, minimum detectable effect and the traps that invalidate a result.
Taboola Data Scientist Interview Questions & Guide 2026
Take-home style practice for data scientists preparing for Taboola: 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.
Samba TV Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Samba TV, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.