Interview guides · DAZN

DAZN Data Scientist Interview Questions & Guide 2026

A two-week prep plan for DAZN data scientist candidates: write your answer before reading the solution, revisit misses three days later.

The 60-second brief

As a Data Scientist at DAZN, you are at the intersection of high-scale sports streaming technology and data-driven decision-making. You will be responsible for building, training, and deploying machine learning and deep learning models that directly impact millions of concurrent users globally. Your work is not just theoretical; it is a critical engine that powers recommendation systems, optimizes infrastructure, and provides the intelligence required to challenge traditional sports broadcasting models.

A large share of questions open as "how would you measure X", where the real work is choosing the metric, fixing its denominator, and defining the population it applies to. Any computation comes last and is frequently not required at all.

Focus areas

Define a qualified stream and defend it
Measure catalogue breadth beyond head consumption
Split voluntary churn from involuntary payment failure

Overview

You will play a pivotal role in evolving DAZN into an AI-first organization. Whether you are working on fine-tuning Large Language Models (LLMs) or optimizing deep learning architectures, your contributions will directly translate into a more seamless and personalized user experience. You will collaborate with cross-functional teams to solve complex, real-world problems, making this a high-impact position for someone passionate about scaling global tech systems.

The DAZN interview process

DAZN candidates report 3 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

Recruiter Screen

A screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.

What to demonstrate

Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
Whether timeline, location and compensation expectations make the rest of the loop worth scheduling

How to prepare

Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice

Technical Assessments

Before 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

Final Round

A day of back-to-back interviews samples your floor, not your ceiling. Four hours in, the habits that carry a good answer are the first to go: restating the question before solving it, asking what the data would have to look like, checking a number before quoting it. What the day decides is whether the tired version of you is still someone to leave alone with an ambiguous problem. The round that sinks a candidate is usually not the hardest one. It is the one immediately after the round that went badly.

What to demonstrate

Whether the late rounds get the same clarifying questions as the first one, or whether you start answering immediately to save effort
Whether a weak answer stays in the room it happened in, instead of following you into the next conversation as apology or distraction
Whether the quality of your questions holds up, since fatigue removes curiosity about the problem before it removes knowledge of the method

How to prepare

Rehearse the length, not just the content: book four mock interviews of different types in one afternoon with short gaps, because the one you need to observe is the fourth
Put the two or three questions you ask at the start of any problem on a card in front of you, so that under fatigue it is a habit you run rather than a decision you make
Decide in advance what the gap between rooms is for: water, one line of notes on anything you promised to follow up, and an explicit close on the round that just ended so it does not travel
Prepare a different closing question for each interviewer, so the end of a long day does not produce the same one four times

Where candidates lose points

Treating the account as the person, or the profile as the person.

A household account carries several people, profiles frequently are not switched, and shared-screen, car and speaker playback often lands on a default profile with no user behind it. Personalisation trained on a profile therefore learns a mixture, retention regressions attribute one member's behaviour to another, and a per-account taste statistic describes a household composite. The practical consequence is that apparent personalisation wins can be device or context effects, so any identity-level claim needs a stated unit and an acknowledgement of what that unit actually aggregates.

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.

Solving silently instead of narrating the reasoning

Say which branch you are taking and why you chose it over the alternative, for example checking the denominator first because it changes what the comparison means. A correct answer that arrives with no visible path scores below a rigorous one that needed a hint.

Comparing periods without accounting for seasonality or day-of-week

Compare whole weeks against whole weeks and check whether the same swing appeared in prior cycles or prior years before attributing it to anything you changed. Weekday and weekend populations often differ enough that a Tuesday-to-Saturday comparison is meaningless.

Questions & practice

Explain the architecture of a transformer model and its application in recommendation engines.

Medium · machine learning and modelling

Approach

Pick an evaluation metric that matches the cost of each error type, not a default.
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?

Optimize a Python function to handle large-scale feature engineering.

Medium · machine learning and modelling

Approach

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.
Frame the prediction: the label, the moment of prediction, and the action it triggers.

Follow-up

What would you monitor after launch to know the model is still valid?
How would you choose the decision threshold, and who owns that choice?

Describe a situation where you had to deploy a model into production under a tight deadline.

Medium · machine learning and modelling

Approach

Pick an evaluation metric that matches the cost of each error type, not a default.
Frame the prediction: the label, the moment of prediction, and the action it triggers.
Set a baseline first, so any model has something honest to beat.

Follow-up

Where could label leakage enter this setup?
How would you choose the decision threshold, and who owns that choice?

Five invariant checks over a playback fact table

Easy · data-quality · pandas · validation

fct_stream arrives with stream_id, started_at, ended_at (nullable), played_seconds, max_position_seconds, completion_ratio, is_qualified, event_date, and duration_seconds joined from the content dimension (null for live events). Write one function returning a tidy frame with a row per rule: rule name, eligible rows, violations, violation share, one example stream_id. The five rules are duplicate stream_id; played_seconds exceeding wall-clock ended_at minus started_at; max_position_seconds exceeding duration_seconds; completion_ratio disagreeing with max_position_seconds divided by duration_seconds; and event_date not equal to the UTC date of started_at.

Approach

Give every rule its own eligible-row mask before its violation mask. Rules 2 to 4 are undefined where ended_at or duration_seconds is null, and a comparison against NaN evaluates False, so a mostly-null column otherwise reports a clean bill of health.
Compare the recomputed completion_ratio with a tolerance (absolute difference above 1e-6), never with ==. It is stored as a float division and exact equality fails on rows that are correct.
Allow a small tolerance on rules 2 and 3 too: a final segment can carry the playhead a second or two past duration_seconds, and heartbeat timestamps come off client clocks. State the tolerance you chose rather than burying it.
Return violations and eligible rows as separate columns so the share has a stated denominator, and carry one example stream_id per rule so the output is actionable rather than a number.
Read rule 5 as a signal rather than corruption: event_date drifting from the UTC date of started_at is the signature of offline playback uploaded after the partition closed, and its distinct dates are the recompute list.

Worked solution (20 min)

Write a helper taking (name, eligible_mask, violation_mask) and returning one result row, which forces every rule to declare its eligible population.
Rule 1: duplicated('stream_id', keep=False), eligible is all rows. Rule 5: event_date not equal to started_at.dt.date, eligible is all rows.
Rules 2 to 4: eligible masks are ended_at.notna() and duration_seconds.notna(); violation masks are played_seconds above wall_seconds plus 2, max_position_seconds above duration_seconds plus 2, and the absolute completion_ratio difference above 1e-6.
Take one example stream_id per rule with .loc[mask].head(1), guarding the empty case so a clean rule does not raise.
Concatenate the five rows and sort by violation share descending.

Expected result: A five-row frame with columns rule, eligible_rows, violations, violation_share and example_stream_id, where eligible_rows for rules 2 to 4 is strictly below the table length whenever ended_at or duration_seconds contains nulls.

Verify it yourself

Injecting one row whose played_seconds is ten times its wall clock raises exactly rule 2's count by one and leaves the other four unchanged.
Setting duration_seconds to null on that same row moves it out of the eligible counts for rules 3 and 4, rather than into their violation counts.
violation_share is violations divided by that rule's eligible_rows, not by len(df); the two differ for rules 2 to 4.
Rule 1's violation count is even when duplicates arrive in pairs, because keep=False flags both copies.

Follow-up

Rule 5 fires on 0.4 percent of rows, all from one app_version, all with reported_at days after started_at. Is that a bug, and what do you do about the daily numbers already published?
How would you turn these into a blocking check in the pipeline without failing the load every time one client version misbehaves?
Which of the five would you expect to fire on live events specifically, and how do you keep them out of the denominator?

Explain how you would handle missing values in a massive dataset with both structured and unstructured inputs.

Medium · sql and data manipulation

Approach

Say which table is the grain you start from, and join outward from 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

How would you verify this result without re-running the same query?
How does the query change if the join becomes one-to-many?

Perform a SQL join across multiple tables to calculate churn rates for a specific region.

Medium · sql and data manipulation

Approach

State the window function and its partition and ordering out loud before writing it.
Say which table is the grain you start from, and join outward from it.
Check whether any join is one-to-many before aggregating, or the sums inflate.

Follow-up

How would you verify this result without re-running the same query?
What breaks if events arrive late or out of order?

Write a script using pandas to clean and aggregate raw user interaction logs.

Medium · sql and data manipulation

Approach

Check whether any join is one-to-many before aggregating, or the sums inflate.
Say which table is the grain you start from, and join outward from it.
Compute rates by summing numerator and denominator separately, never by averaging rates.

Follow-up

How would you verify this result without re-running the same query?
What breaks if events arrive late or out of order?

Home-row impressions that never converted, and an empty result

Medium · anti-join · null semantics · attribution

fct_impression has impression_id, profile_id, content_version_id, surface, slate_position, rendered_at and viewport_visible_ms. fct_stream has stream_id, profile_id, content_version_id, started_at, is_qualified and a nullable impression_id, populated only when the play started from a rendered slate. For surface = 'home_row' impressions rendered yesterday with viewport_visible_ms > 0, return content_version_id and the number of impressions that produced no qualified stream within 30 minutes. A colleague's draft filters WHERE impression_id NOT IN (SELECT impression_id FROM fct_stream) and returns zero rows on data that plainly contains misses. Explain why, then write the correct query.

Approach

Name the mechanism rather than the symptom. fct_stream.impression_id is nullable, so the subquery returns a set containing NULL. In SQL's three-valued logic x NOT IN (..., NULL) evaluates to UNKNOWN whenever x matches nothing else, never to TRUE, so the WHERE clause admits no rows. This is correct engine behaviour on correct data.
Fix with NOT EXISTS, which is a correlated existence test and is NULL-safe by construction, or with LEFT JOIN ... WHERE s.impression_id IS NULL. Adding IS NOT NULL to the subquery also works but leaves the same landmine armed for whoever edits the query next.
Put is_qualified = true and the 30-minute window inside the join or the correlated predicate, never in an outer WHERE over a LEFT JOIN. An outer filter on a right-side column turns a LEFT JOIN back into an inner join and returns the exact complement of the set you were asked for.
Match on impression_id, not on (profile_id, content_version_id). The second is a many-to-many between two event tables and will count one stream against every impression of that title for that profile.
Keep viewport_visible_ms > 0. A row that was never scrolled into view is not a recommendation that failed; it is a recommendation that was never made, and including it depresses every title's conversion by whatever share of the row went unseen.

Worked solution (20 min)

Prove the mechanism in one line: SELECT COUNT(*) FROM fct_stream WHERE impression_id IS NULL. A non-zero count is the entire explanation and should be shown before the rewrite.
Rewrite as NOT EXISTS, with is_qualified and started_at BETWEEN rendered_at AND rendered_at + INTERVAL '30 minutes' inside the correlated predicate.
Compute eligible and converted impression counts per content_version_id separately; the requested answer must be their difference.
Spot-check one high-count content_version_id by listing its impressions alongside any streams sharing those impression_ids.

Expected result: Rows of (content_version_id, unconverted_impressions) where, for every title, unconverted + converted equals the count of eligible home_row impressions with viewport_visible_ms > 0 rendered yesterday.

Verify it yourself

The NOT IN version returns zero rows while NOT EXISTS returns a non-empty result on the identical filtered data.
converted + unconverted reconciles to the eligible impression count for every content_version_id, with no title missing from either side.
Every impression counted as converted has a matching fct_stream row with is_qualified = true and started_at inside the 30-minute window.

Follow-up

Two home rows on the same screen render the same title, and the stream carries one impression_id. Should the other impression count as a miss? Defend whichever rule you pick.
Would NOT EXISTS and LEFT JOIN ... IS NULL produce the same plan here, and is there a case where you would prefer one over the other?
What attribution window between rendered_at and started_at do you allow, and why does an unbounded window overstate conversion rather than merely add noise?

What are the differences between CNNs and RNNs, and when would you choose one over the other for time-series data?

Medium

Approach

Say what you would check first and why it is the highest-information step.
Clarify what is being asked and what a complete answer would contain.
State your assumptions explicitly before working the problem.

Follow-up

What assumption would you test first?
How would you know your answer was wrong?

Build a surrogate index for six-month paid retention

Hard · metric design · surrogate validation · experimentation · long-term outcomes

The engagement org runs experiments that read out in three weeks, but the outcome it is judged on is month-6 paid retention. You are asked for a single surrogate index that experiments can ship on. Using the spine's account-level metrics (first-week habit rate, qualified hours per active account-week, duration-normalised completion rate) and fct_subscription_period (account_id, period_end_ts, renewal_outcome, is_promotional), propose the index, specify exactly how you would validate it, and state the condition under which shipping on it is unsafe.

Approach

State the estimand and the binding constraint together: the decision outcome is the month-6 paid retention effect of a treatment, and the constraint is a three-week readout, so the index is standing in for an effect that will not be observed until long after the ship decision. Say what surrogacy requires, namely that the treatment effect on retention must flow entirely through the index, and say that this is an assumption about the treatment, not a property of the index.
Construct the candidate from metrics that are already defined and already measurable in three weeks: an account-level index combining first-week habit rate (qualified streams on three or more distinct UTC dates in the first 168 hours) with qualified hours per active account-week over weeks two and three, weights estimated rather than chosen, with duration-normalised completion rate as a third term only if it earns its place in the fit.
Specify the validation at the right level of analysis, because this is where the answer is won or lost: regress the observed month-6 retention effect on the observed index effect across the historical corpus of completed experiments, one point per experiment, and report the slope with its confidence interval and the residual spread. A correlation between engagement and retention across accounts is not evidence of surrogacy at all, because it is driven by account quality rather than by transmission of a treatment effect.
Quantify what the validation buys: the usable output is the residual standard deviation of the retention effect given the index effect, which converts an index reading into a retention interval. If that interval routinely spans zero at the index effect sizes teams actually ship, the index does not support the decision it is being built for and the honest answer is to say so.
Name the invalidation condition concretely rather than as a caveat: the extrapolation fails for any treatment whose mechanism is absent from the validation corpus, and the clearest examples are those that raise the index through a channel that does not carry: autoplay and push notifications raise hours without raising intent, and an ad-load reduction raises hours while removing the revenue the retention is worth.
Close the loop with governance: a pre-registered fraction of index-shipped changes is held out for a confirmatory 180-day readout, the corpus is refreshed with those results, and the slope is re-estimated on a schedule, because a surrogate validated once and never revisited is a surrogate that drifts silently.

Worked solution (45 min)

Write the surrogacy condition in one sentence and state explicitly that it is untestable from any single experiment, which is why the validation has to pool evidence across many completed experiments.
Define the index at the account level from the three named component metrics, and state that the weights come from the cross-experiment fit rather than from judgement.
Set up the validation regression with one row per completed experiment: the month-6 retention effect on the three-week index effect, and report slope, confidence interval and residual standard deviation.
Convert a worked index reading into a retention interval using the slope and residual spread, and check whether that interval excludes zero at the effect sizes teams typically ship.
Write the invalidation rule as a named list of mechanisms absent from the corpus, and the governance rule for confirmatory holdouts and periodic re-estimation.

Expected result: An account-level index built from first-week habit rate and weeks two-to-three qualified hours, with weights fitted across experiments. Validation is a cross-experiment regression of month-6 retention effects on index effects, reporting slope, interval and residual spread, explicitly not a cross-account correlation. Unsafe whenever the treatment's mechanism is unrepresented in the corpus, with autoplay, push notifications and ad-load changes named. Governance: pre-registered confirmatory 180-day holdouts and scheduled re-estimation.

Verify it yourself

The validation has one observation per experiment, not one per account, and the candidate can say in one sentence why that distinction is the whole answer.
The output of the validation is an interval on the retention effect, not a single correlation coefficient, so a reading can actually be acted on or refused.
The invalidation condition names mechanisms rather than saying results should be interpreted with caution.
A confirmatory long-horizon readout remains in the process after the index is adopted, which is the only thing that detects drift.

Follow-up

Your corpus has 40 completed experiments and the slope confidence interval is wide. What do you ship on in the meantime, and what do you tell the teams?
A team's treatment raises the index by exactly the amount your slope says is worth one retention point, but the mechanism is push notifications. What is your recommendation?
How would you detect that the surrogate has drifted, using only the confirmatory holdouts you have been collecting?

Qualified streams drop the week a client shipped

Easy · instrumentation · release-debugging · segmentation

Qualified streams in fct_stream (is_qualified, played_seconds, max_position_seconds, app_version, device_type, started_at, ended_at, end_reason) fell 11% on phone in the seven days after version 8.4.0 reached staged rollout. Smart TV and desktop are flat. The mobile team says nothing in the release touched playback. Using fct_stream and dim_profile only, decide within one day whether engagement fell or whether the client stopped reporting playback correctly, and say what evidence settles it. Deliverable: a one-page finding with the decomposition and a recommendation on whether to halt the rollout.

Approach

Split the 11% into stream count and per-stream played_seconds. Cut phone streams by app_version into 8.3.x and 8.4.0 on the same dates and compare starts per active profile-day against played_seconds per start. A real engagement fall moves starts; a telemetry fall moves played_seconds per start while starts hold.
Check the accrual mechanics that change silently: share of rows with ended_at null, share with end_reason in ('unknown','app_kill'), and the played_seconds distribution in 5-second buckets from 0 to 60. A heartbeat regression piles rows up just under 30 seconds and raises the null-ended_at share, because is_qualified is a threshold on a counter rather than on the fact of playback.
Use the staged rollout as the control, but use it correctly. Within phone and within the same dates, prefer profiles that have streams on both versions so each profile is its own before-and-after. Rollout order is not random — early upgraders skew toward frequent users — so report the within-profile change and treat the between-version gap as an upper bound.
Compare max_position_seconds per start against played_seconds per start. max_position_seconds is the furthest playhead reached and does not depend on how time is accrued, so if the playhead still travels the same distance while played_seconds falls, playback happened and the counter is wrong. That comparison is decisive; the others are only suggestive.
Recommend on the basis of which number moved. Halt the rollout for an engagement regression only if starts fell. If accrual broke, the halt is a data-integrity call, the affected days need a caveat on every series built on played_seconds, and the music payout path that reads is_qualified has to be told the same day.

Follow-up

If played_seconds under-reports on 8.4.0, how would you restate the qualified-stream series across the rollout window rather than blanking it?
Staged rollout is ordered by store and device, not randomised. What does that do to a between-version estimate, and how would you bound the bias?
The per-stream payout boundary is the same 30-second threshold. Who needs to know, and before what deadline?

Suggested practice checklist

For someone who can already write the query and train the model but stalls when asked what to measure or whether a change is worth making. Metric definition and case structure come first; the technical work is kept as maintenance rather than the centre of the week.

Day 1 — Metric anatomy

For three products you use daily, write one primary metric, two input metrics that plausibly move it, and one guardrail that would catch a cheap way of moving the primary at the cost of the product.
For one of them, specify the metric precisely enough that two analysts would return the same number: numerator, denominator, unit of observation, time window, and how returning and deleted accounts are treated.
Pick a ratio metric and write what happens to it when the denominator shrinks for reasons unrelated to the numerator, with a concrete example of that happening.

Deliverable: A one-page metric tree for one product, with the primary metric written as an unambiguous spec.

Day 2 — Diagnosing a drop without guessing

Take the prompt "weekly active users fell 8 percent week over week" and write the segmentation plan before proposing any cause: platform, region, tenure cohort, acquisition channel, and whether the movement sits in the numerator or in a changed denominator.
List the instrumentation failures that manufacture fake drops (a client release that stopped firing an event, a bot filter change, a shifted date boundary or timezone) and write the query that rules out each one.
Rehearse stating the boring explanations first, seasonality and day-of-week composition, before reaching for a product cause.

Deliverable: A drop-diagnosis checklist short enough to recite from memory in under a minute.

Day 3 — Should we build it

Take a feature idea and write it as a bet: what you believe is true, what would have to be true for it to pay off, the metric that would confirm it, and the effect size that would justify the engineering cost.
Size the opportunity top-down and bottom-up, then reconcile the two numbers in writing instead of quoting whichever is friendlier.
Write the counter-metric that would make you kill the feature even if it wins on the primary metric.

Deliverable: A one-page product memo ending in a decision rather than a list of considerations.

Day 4 — The places aggregate numbers lie

Construct a Simpson's paradox numerically: two segments where the treatment wins within each segment yet loses overall, and identify the shift in segment weights that causes it.
Take a heavy right-tailed quantity such as revenue per user and write why the mean is the wrong summary, which percentile you would report instead, and what a moving mean with a stable median tells you.
Write your definition of a session for the product from day one, then name two real behaviours it misclassifies.

Deliverable: One page holding a worked Simpson's paradox table and a session definition with its two known failure cases.

Day 5 — Technical maintenance, aimed at metrics

Solve four timed SQL prompts that all end in a ratio metric, so the question of grain stays live in every answer.
Compute a 95 percent confidence interval for a proportion on a small sample, and state why the normal approximation is unreliable when either np or n(1 minus p) falls below roughly 10, along with which interval you would use instead.
Take one metric from your day-one tree, write the query that computes it correctly, then write the query that computes it wrong in the most plausible way and explain how you would notice.

Deliverable: Four solved prompts plus a matched correct and plausible-wrong query for one metric.

Day 6 — Turning engineering work into data science stories

Write three project stories as situation, decision, trade-off, outcome, each carrying one number and one thing you got wrong.
For the story you will lead with, prepare an answer to "what would you do differently" that names a decision you made, not a constraint you were handed.
Practise the sentence that reframes a systems project as a question project: the question the work answered, ahead of the pipeline it shipped.

Deliverable: Three written stories with the lead story delivered aloud and timed under four minutes.

Day 7 — Mock case and gap list

Run a 40-minute mock case with someone playing a product manager who pushes back on your metric choice, and record it.
Listen back and mark every moment you proposed a solution before the success metric existed.
Rewrite those moments as the question you should have asked, and rehearse the first 90 seconds of the case until scoping comes before solving.

Deliverable: A recorded case plus a rewritten opening 90 seconds.

Ambiguous requests are the test

Most of the questions in this section reduce to one thing: can you be handed a vague request and come back with something useful? Prepare an example where the ask was underspecified, you chose an interpretation, and you said out loud which interpretation you chose. Describing how you narrowed the question matters more than the technique you eventually used.

How do you stay updated with the rapid advancements in GenAI and determine what to implement?

Medium · behavioural and stakeholder questions

Approach

State the situation in two sentences and spend the rest on your reasoning.
Close with what you would do differently, concretely.
Name the disagreement or constraint, and how you resolved it with evidence.

Follow-up

What did you decide not to do, and why?
How did you know the outcome was caused by your change?

How do you prioritize projects when you have conflicting business requirements?

Medium · behavioural and stakeholder questions

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 did you decide not to do, and why?
How did you know the outcome was caused by your change?

Give an executive a number you are not sure of

Medium · communicating uncertainty · executive communication · retention

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?