Interview guides · Brigham Young University (BYU)

Brigham Young University (BYU) Data Scientist Interview Questions & Guide 2026

Case practice for Brigham Young University (BYU) data scientist candidates: scope a vague prompt into a measurable question before you analyze it.

The 60-second brief

As a Data Scientist at Brigham Young University (BYU), you will serve as a critical bridge between complex data systems and the strategic goals of a large, multifaceted institution. Your work directly impacts how the university understands its community, optimizes operational efficiency, and supports student success. This role is not merely about running models; it is about providing the analytical foundation for decision-making across campus, from enrollment management to administrative operations.

Coding rounds for this role are usually data-manipulation shaped rather than data-structure shaped: group-bys, joins, time windows, ranking within a partition. Confirm the format before spending a week on graph traversal.

Focus areas

Model seat activation as the renewal leading indicator
Separate mastery signals from raw usage exposure
Reconstruct active time from raw heartbeat streams

Overview

You will often find yourself working in an environment that values deep research and methodical inquiry, similar to the academic culture of the university itself. The complexity of the data—often spanning diverse departments and legacy systems—requires a candidate who is both technically proficient and capable of navigating institutional nuances. You will be expected to define your own path, as the Data Science ecosystem at Brigham Young University (BYU) is an evolving space where your ability to articulate the "why" behind your technical choices will be as important as the code you write.

The Brigham Young University (BYU) interview process

Brigham Young University (BYU) candidates report 4 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

Initial Screening

Most candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.

What to demonstrate

Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
The substance of the questions you ask back, which an experienced screener reads as a level signal

How to prepare

Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered

Panel Interviews

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

Technical Evaluation

This round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.

What to demonstrate

Whether your row counts survive each join, and whether you notice on your own when they do not
Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
Reaching a defensible answer inside the window instead of a refined one after it

How to prepare

Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither

Final Panel Rounds

Where a loop includes a partner from outside the data team, that conversation usually carries the same weight as the technical ones and gets the least preparation. The person opposite you will not follow a derivation and does not need to. They are working out whether having you involved would make their decisions better or slower. The failure mode is not being too technical. It is answering a question about a decision with a description of your method, leaving the translation to them. What they carry into the debrief is the sentence you handed them, not the analysis underneath it.

What to demonstrate

Whether a statistical result arrives as something the partner could act on, with the one caveat that would change their decision kept and the rest left out
Whether you can state what you need from their side, in their terms: instrumentation that does not exist yet, a definition they own, or a holdout they have to agree to
Whether uncertainty is given as a range someone can plan against, rather than as hedging that invites them to ignore the result
Whether you ask what decision is actually on the table before explaining anything

How to prepare

Take a result you know well and write the version for someone who stops reading after one sentence, then the three-minute version, and check the short one is not the long one with the qualifications stripped out
For a past project, list everything you asked a non-technical partner for and how you phrased it, then rewrite each ask so it names what goes unmeasured without it
Practise saying where a result does not apply, out loud, in one sentence that a partner could repeat accurately to someone else

Where candidates lose points

Consent and age rules silently truncate the data, not just the joins.

Where age_gated is TRUE, behavioural logging and cross-system joins are restricted, so those learners are missing from the very tables used to compute engagement. An analysis that simply inner-joins will produce a population skewed to older learners and self-serve accounts while appearing complete. Check the age_gated share of every population you report on, and state it.

Roster sync creates and deactivates accounts in bulk, and it is not behaviour.

An automated roster import at term start can create thousands of accounts in one hour and deactivate thousands more at term end. Signup, activation, and churn series computed without filtering enrollment_source IN ('roster_sync','admin_bulk') will show spikes and cliffs driven entirely by an integration job. It also breaks cohort retention: a roster-created account that never activates is a provisioning artefact, not a churned learner.

Answering a product-sense question with a list of features

Answer with a decision and the measurement that would settle it: the hypothesis, the primary metric, the guardrails, and the result that would make you not ship. A feature brainstorm cannot be wrong, which is exactly why it earns no points.

Defining the cohort on a post-treatment condition

Ask how rows entered the table. Filtering on something that treatment itself influences, such as users who finished onboarding or accounts still active at ninety days, breaks comparability between arms; define the population at an entry point that precedes exposure and keep everyone in it.

Questions & practice

Implement verified mastery events with a delayed check

Medium · first crossing · window logic · metric implementation

From fct_assessment_response (learner_id, objective_id, content_item_id, submitted_at, attempt_no, is_correct, score_points, max_points, scoring_mode, scored_at, mastery_state_after), count verified mastery events for one calendar month. A mastery event is the first time a (learner_id, objective_id) pair reaches mastery_state_after 'mastered'. It is verified when the earliest scored response on that objective submitted at least 7 days later scores score_points/max_points >= 0.8. Return the monthly count and the verified rate, with the denominator restricted to events that have an eligible later check.

Approach

Filter to rows with mastery_state_after = 'mastered', then take the earliest submitted_at per (learner_id, objective_id). This is not the same as the first row overall for the pair, since earlier attempts sit in 'learning'.
Restrict those crossings to the target month in UTC. A pair that first crossed in an earlier month never enters this month's count even if it crosses again after a lapse, so the first-crossing filter must run over all history, not just the month.
Build the candidate check set by joining the full response table back on (learner_id, objective_id) and keeping rows with submitted_at >= crossing + 7 days, score_points not null, scored_at not null, and max_points > 0.
Take the earliest eligible candidate per pair, not the best one. Taking the maximum score turns a retention check into an ever-passed-later check, which is a much weaker claim and a materially higher number.
Mark verified where score_points / max_points >= 0.8. The denominator is crossings with at least one eligible candidate; report the count of crossings with none alongside, because that share moves with the reporting lag and a large share means the month is not ready to publish.

Follow-up

A pair crosses to 'mastered', lapses, and crosses again inside the same month. What does your code count, and what should it count?
Why does this metric need a 30-day reporting lag, and what shape does the series take if you publish it at 7 days?
The 0.8 ratio is a product choice. How would you check it actually separates learners rather than just passing almost everyone?

Audit response rows against the versioned content dimension

Easy · data quality · referential integrity · joins

Write a check function over fct_assessment_response (response_id, learner_id, content_item_id, content_version_no, attempt_no, submitted_at, scoring_mode, scored_at, score_points, max_points) and dim_content_item (content_item_id, version_no, status, published_at, retired_at). Return one row per check with check_name, failing_count, denominator, and up to five example response_ids. Cover at least four checks: version pairs missing from the dimension, responses submitted before published_at or after retired_at, attempt_no that is duplicated or not gapless from 1 within a learner and item, and rubric_human rows still unscored more than 5 days after submitted_at.

Approach

Do the existence check as a left merge on the pair (content_item_id, content_version_no) to (content_item_id, version_no) with indicator=True. Joining on content_item_id alone both hides the defect you are looking for and fans rows out by the number of versions per item.
Evaluate the publication window only on rows that matched, and treat NULL retired_at as open-ended. Report the two directions separately: an early submission points at a publishing race, a late one points at a retirement that never removed the item from a live form.
For attempt_no, group by (learner_id, content_item_id) and compare the sorted attempts to range(1, n+1). A duplicate and a gap are different defects with different causes, so emit them as two rows.
For scoring lag, restrict to scoring_mode = 'rubric_human' with scored_at null and submitted_at older than 5 days. Anything more recent is expected lag, not a defect, and counting it makes the check permanently red.
Give every check its own denominator. A shared total row count makes the version check look negligible and the attempt check look enormous when neither is true, because their natural units are rows and (learner, item) groups respectively.

Worked solution (20 min)

merged = responses.merge(dim, left_on=['content_item_id','content_version_no'], right_on=['content_item_id','version_no'], how='left', indicator=True); missing = merged._merge == 'left_only'.
On matched rows: early = submitted_at < published_at; late = retired_at.notna() & (submitted_at > retired_at).
attempts = responses.groupby(['learner_id','content_item_id']).attempt_no.agg(['count','nunique','max']); duplicated = nunique < count; gapped = (nunique == count) & (max != count).
lagged = (scoring_mode == 'rubric_human') & scored_at.isna() & (submitted_at < now - 5 days).
Assemble a frame of check_name, failing_count, denominator, and head(5) of the failing response_ids per check.

Expected result: A small frame with one row per check, each carrying its own denominator so shares are comparable. On a clean synthetic input every failing_count is zero, and injecting one defect of each kind makes exactly that check report one.

Verify it yourself

Inject a response with content_version_no 99 on an item that has versions 1 to 3 and confirm only the missing-version check fires.
Duplicate one attempt_no and confirm the duplicate check fires with a denominator equal to the number of (learner, item) groups, not the row count.
Set retired_at into the past on one item and confirm the window check counts every later response on that item and no others.

Follow-up

Which of these four would you page someone about at 2am, and which is a ticket for the week?
How do you keep this check from timing out once the fact table is in the billions of rows, without weakening what it detects?

Compute pace adherence at term-week six

Easy · metric implementation · calendar alignment · null handling

Given fct_enrollment (enrollment_id, learner_id, course_id, section_id, term_id, enrollment_source, enrolled_at, scheduled_start_date, due_date, completed_at, units_total, units_completed, status) and dim_term (term_id, term_start_date, term_end_date, term_length_weeks), compute the share of enrollments at or ahead of pace at the end of term-week 6. An enrollment is on pace when units_completed >= units_total * (6 / term_length_weeks). Count only enrollments active at that moment. Handle NULL scheduled_start_date and units_total of zero explicitly, and return one value per term with its denominator.

Approach

Join to dim_term on term_id and derive the cutoff as term_start_date plus 42 days. The metric is anchored to the term calendar, not to each enrollment's own start, which is what makes it comparable across institutions on different calendars.
Resolve NULL scheduled_start_date by falling back to term_start_date, and count how often the fallback fired. A large fallback share is a finding about roster sync, not a detail to bury.
Reconstruct active-at-cutoff rather than trusting the status column: enrolled_at <= cutoff and (completed_at is null or completed_at > cutoff). If status is current-state only, say so, because then filtering on it removes learners who fell behind and dropped later.
Exclude units_total = 0 from both numerator and denominator and report that count separately. Left in, 0 >= 0 marks every empty enrollment as on pace and drags the rate up.
Group by term_id and return numerator, denominator, and rate together, never the rate alone.

Follow-up

A two-week holiday falls inside weeks one to six for one term. How do you stop that punishing those enrollments without hand-editing the threshold?
Two terms have term_length_weeks of 10 and 16. Is a single week-6 number comparable across them, and what would you report instead?

Given two tables with mismatched schemas, how would you join them to minimize data loss?

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?
How does the query change if the join becomes one-to-many?

How would you use SQL window functions to calculate a moving average of student engagement metrics over the last 30 days?

Medium · sql and data manipulation

Approach

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.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.

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?

Deduplicate retried submissions before computing first-attempt accuracy

Medium · window functions · deduplication · fan-out

A client retry bug wrote duplicates into fct_assessment_response(response_id, learner_id, content_item_id, content_version_no, attempt_no, submitted_at, is_correct, max_points, scoring_mode): the same learner, item, version and attempt_no appears two or three times, submitted_at within two seconds, different response_id. Deduplicate keeping the earliest row per logical attempt, then compute 28-day first-attempt accuracy over items whose course has dim_course.uses_adaptive_selection = FALSE and whose (content_item_id, version_no) did not change inside the window. Report how many rows the dedup removed and its share of raw rows.

Approach

Rank with ROW_NUMBER() OVER (PARTITION BY learner_id, content_item_id, content_version_no, attempt_no ORDER BY submitted_at, response_id) and keep rn = 1. Including response_id in the ORDER BY makes the survivor deterministic when submitted_at ties, which it will at second resolution.
Validate the duplicate definition before deleting anything. Count partitions with rn > 1 and inspect MAX(submitted_at) - MIN(submitted_at) inside each. A spread of minutes is a genuine re-attempt the client failed to increment attempt_no for, and dropping it is data loss rather than dedup.
Apply the version restriction by excluding content_item_id values that show more than one distinct content_version_no among responses in the window, or whose dim_content_item.published_at falls inside it. An item edited mid-window mixes two different questions into one accuracy figure.
Filter attempt_no = 1 AND is_correct IS NOT NULL. Treating NULL is_correct as incorrect biases accuracy down by exactly the unscored rubric share, and that share is not stable week to week.
Report accuracy with its denominator, plus removed_rows and removed_rows / raw_rows, so the size of the bug is visible next to the number it corrupted.

Worked solution (25 min)

Run the ROW_NUMBER over the raw table and count rows with rn > 1, grouped by the within-partition submitted_at spread in seconds.
Materialise the deduplicated CTE and record removed_rows.
Build the eligible-item CTE from the version-change rule and the uses_adaptive_selection = FALSE join.
Compute AVG(is_correct::int) over attempt_no = 1 rows on eligible items, and report it twice, once with and once without the version restriction.

Expected result: A deduplicated set where COUNT(*) equals COUNT(DISTINCT (learner_id, content_item_id, content_version_no, attempt_no)), a removed-row count with its share of raw rows, and one accuracy figure with its denominator over surviving first attempts on eligible items.

Verify it yourself

Re-running the ROW_NUMBER over the deduplicated set produces no rn > 1.
Every removed row sits inside a partition whose submitted_at spread is under the two-second threshold. A removal outside it means the partition key is wrong.
If the version restriction moves accuracy by more than a point or two, one edited item carries a large share of the responses. Confirm which item that is before publishing either number.

Follow-up

attempt_no is 1-based within learner and item, not within item version. If an item is edited between a learner's first and second attempt, which row is the first attempt on the new version, and does the metric want it?
The retry bug fires more often on poor connections. If that population differs in accuracy, what does silently dropping their duplicates do to the number?
How would you make this query cheap to leave in place after the bug is fixed, so it costs nothing on a clean table?

What is the most important metric for measuring student retention, and why?

Medium · product sense and metrics

Approach

Restate the decision this analysis has to support, and who acts on the answer.
State what result would change your recommendation, so the answer is falsifiable.
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?

How would you design a set of product metrics to track the success of a new campus-wide digital tool?

Medium · product sense and metrics

Approach

Name one primary metric, then the guardrail that stops it being gamed.
Decompose the metric into the rates that drive it, and say which one you would check first.
Restate the decision this analysis has to support, and who acts on the answer.

Follow-up

What would you do if the primary metric and the guardrail moved in opposite directions?
Which segment would you cut first, and what would that rule out?

If you noticed a sudden metric drop in student login frequency, what would be your step-by-step process for diagnosis?

Medium · product sense and metrics

Approach

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.
State what result would change your recommendation, so the answer is falsifiable.

Follow-up

How would you detect that the metric is being gamed rather than genuinely improving?
Which segment would you cut first, and what would that rule out?

If an A/B test shows a significant lift in one metric but a decline in another, how do you decide which result takes precedence?

Medium · a/b testing and experimentation

Approach

Say whether units interfere with each other, and switch design if they do.
Name the randomisation unit first; it decides the variance and what the test can detect.
State the primary metric and the minimum effect worth shipping, then size the test.

Follow-up

How would you handle interference between treated and control units?
What would you do if you could not randomise at all?

How would you design an experiment to test the impact of a new interface on user adoption?

Medium · a/b testing and experimentation

Approach

State the primary metric and the minimum effect worth shipping, then size the test.
Name the guardrails that would stop a launch even on a positive primary result.
Decide the analysis before seeing data, including how long it runs and when you look.

Follow-up

What would you do if you could not randomise at all?
How would you handle interference between treated and control units?

Choose a success metric for autoplay lesson advance

Easy · gameable metrics · engagement · guardrails

A change autoplays the next lesson when a video ends. Week one: lessons opened per learner rose 33%, active minutes rose 8%, scored submissions per active learner fell from 2.1 to 2.0. You have fct_lesson_activity (active_seconds, wall_seconds, completion_status, is_assigned), dim_content_item (item_type, expected_minutes) and fct_assessment_response (attempt_no, is_correct, max_points). Name the primary metric you would have pre-registered, two guardrails, and state exactly how lessons opened and completion_status are moved by the mechanism rather than by learning.

Approach

Sort every candidate metric into exposure or outcome. Autoplay decides what starts, so any metric whose numerator is a start, an open, or a video reaching its end is written by the feature itself and cannot be primary.
Check whether active_seconds is also contaminated: it caps each inter-heartbeat gap at 120s and excludes backgrounded tabs, so a foreground autoplay with nobody watching still accrues time while a background one accrues none. Ask how the client emits heartbeats before quoting the 8%.
Pick a primary metric that requires an action the feature does not perform for the learner: weekly learners with at least one scored submission, or verified mastery events per active learner where the delayed retention check is available for the grade band.
Add guardrails that close the two obvious gaming routes: scored submissions per active learner reported alongside mean max_points per submission, and median active_seconds per completed (content_item_id, version_no) so click-through shows up as a drop.
Decide against the pre-registered rule rather than against whichever number came back largest, and say that one week of data is a direction, not a result.

Worked solution (20 min)

List the four reported numbers and label each exposure or outcome, with one sentence per exposure metric describing how autoplay moves it at zero learning.
Compute the outcome change: 2.0 versus 2.1 scored submissions per active learner is -4.8% relative, the only number in the set the feature does not write directly.
Write the primary metric definition with its numerator, denominator and window, then the two guardrail definitions.
Write the ship rule: ship only on a non-negative primary with both guardrails flat or better, holding the exposure metrics out of the decision entirely.

Expected result: Primary: weekly learners with at least one scored submission (or verified mastery events per active learner). Guardrails: scored submissions per active learner paired with mean max_points, and median active_seconds per completed content item version. Lessons opened, completion_status='completed' and wall_seconds are explicitly disqualified as primary because the feature writes them.

Verify it yourself

Every metric you kept requires a learner action that autoplay does not perform on their behalf.
The -4.8% on scored submissions is stated as a one-week directional warning, not as a significant result.
You said which of wall_seconds and active_seconds autoplay can inflate, and why the backgrounded-tab exclusion matters to that answer.

Follow-up

What evidence would convince you the 8% active-minutes lift is attention rather than a foreground tab left open?
Verified mastery is not calibrated for the youngest grade bands. What do you report there instead, and what do you lose?
Autoplay may genuinely help learners who would have stopped at a natural break. How would you measure that group without slicing after seeing the results?

Active minutes fell eighteen percent with session count flat

Easy · instrumentation · event-logging · metric-regression

Weekly active learning minutes per active learner fell from 42 to 34 the week a new client build shipped. Distinct learner_id and row count in fct_lesson_activity are both flat week over week. You have fct_lesson_activity (session_id, started_at, ended_at, active_seconds, wall_seconds, device_type, content_version_no, activity_date) and nothing else today. Decide whether this is a real engagement change or an instrumentation change, name the column that settles it, and write the query. Deliverable: a one-paragraph call within the day.

Approach

Compute the daily median of active_seconds / wall_seconds per session for fourteen days either side of the release. active_seconds is heartbeat-derived and capped per gap; wall_seconds is ended_at minus started_at and is untouched by heartbeat cadence, so the ratio isolates the instrument from the behaviour.
Hold the denominator fixed alongside it: sessions per learner per week and median wall_seconds per session. If both are flat, nothing about how long learners stayed changed, which leaves only how time was counted.
Split the ratio by device_type. Managed Chromebook fleets typically run a pinned build and update on a school IT cycle, so that group is a natural unexposed comparison for a client-side change.
State the mechanism explicitly: active_seconds sums inter-heartbeat gaps with each gap capped at 120 seconds, so a heartbeat interval raised above 120 seconds discards the excess on every gap and shrinks active_seconds proportionally while wall_seconds is unaffected.
Size it: apply the pre-release ratio to post-release wall_seconds to get counterfactual minutes, and report the difference from the published number as the artefact.

Follow-up

What would you backfill, and what would you leave as a documented break in the series?
If wall_seconds had fallen by the same proportion, what would you check next before calling the drop real?
How would you make this metric robust to the next heartbeat cadence change without re-litigating it?

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.

Your part, not the team's

Most data work is done by groups, so an interviewer has to work out which piece was yours. An answer that runs on 'we' for several minutes gets interrupted with a question about what you personally did, and by then the answer sounds defensive even when it is true. Mark your own contribution as you go, and name the parts that belonged to someone else instead of leaving them ambiguous. Keep a few specifics back as well, like the name of the metric or who actually objected, so a probe can be answered with something you had not already said.

How do you handle null values or outliers when preparing a dataset for predictive modeling?

Medium · behavioural and stakeholder questions

Approach

Name the disagreement or constraint, and how you resolved it with evidence.
Quantify the outcome, including what you would not claim credit for.
State the situation in two sentences and spend the rest on your reasoning.

Follow-up

What would you do differently if you ran that project again?
How did you know the outcome was caused by your change?

Account for an analysis you later discovered was wrong

Hard · postmortem · analytical rigor · ownership

Describe a case where you reported a result and later found it was wrong. Choose one where the error was yours and the number had already been used for a decision. Cover: the claim, the actual defect at the data or design level, how you found it, how long it had been live, who you told and in what order, and what you changed so the same class of defect cannot recur. The interviewer will push on the mechanism, not the apology. Probed: whether you understand your own failure modes well enough to have engineered around them.

Approach

Pick an error with a nameable mechanism, such as a grain mistake, a survivorship filter, or a join that silently dropped age_gated learners. 'I misread a chart' has nothing testable in it.
State the blast radius in decisions rather than in dashboards: what was decided, what was spent or promised, and to whom.
Describe detection honestly, including whether someone else caught it and how long it ran undetected. A slow external catch is a usable answer; a vague one is not.
Give the disclosure order and the reason for it: the decision owner first, with the corrected number and its direction in the opening sentence, then the wider audience.
Close on the systemic fix and say whether it has fired since. A control that has never triggered on anything is a resolution, not a fix, and saying so is worth more than claiming otherwise.

Follow-up

What did the corrected number change about the decision? If nothing changed, why did you escalate at all?
Has the check you added caught anything since, and on what?
What class of error would still get past you today?

Scope a vague request to investigate falling engagement

Easy · scoping · metric definition · stakeholder management

A curriculum director messages you: engagement is down in middle school, can you dig into it. You have dim_learner, fct_lesson_activity, fct_assessment_response, fct_enrollment and dim_term. Before writing any query you get one fifteen-minute conversation. Deliverable: the questions you ask in that conversation, the written scope you send afterwards, and the first three things you compute, with the reason each comes before the others. Probed: whether you convert an ambiguous request into a decision and a single metric before touching data, rather than after.

Approach

Find the decision behind the request first: what the director would do differently depending on the answer, and by when. That sets how much of this analysis is worth doing at all.
Pin the four ambiguities that make 'engagement is down' uncomputable: which population (grade_band = '6_8', which orgs), which metric (active_seconds, activity days, scored submissions), which comparison window, and against which baseline.
Ask where the belief came from. 'Down' is almost always a chart someone saw, and reproducing that exact chart is faster than building a new one and then arguing about why the two differ.
Check the calendar before believing the shape at all: a decline spanning a term boundary is the default explanation in this domain, so term-week alignment through dim_term is the first computation, not a later refinement.
Send the scope back in writing with an explicit out-of-scope list and a time box, so follow-on questions arrive as new requests instead of as scope creep.

Follow-up

The director cannot name the decision this feeds. Does that change whether you do the work, and how much of it?
Your term-aligned version shows no decline at all. What do you send, and to whom first?