AI Product & Experimentation · 90 minutes
Define a user outcome and baseline
Explain why longer sessions do not justify shipping AI hints, then use a fictional pilot's per-arm figures to propose an evaluation with a real baseline, an independent learning outcome, and guardrails.
1.5 h
Overview
An AI feature is worth shipping only if it improves something users need, compared with what they would otherwise have. This level teaches you to turn a capability into a measurable user outcome, pick a fair baseline, and organize metrics so a proxy such as session length cannot stand in for benefit. You practice on a fictional coding-practice platform's hint pilot.
Study time: 90 minutes
Interview format: Conceptual screen with a metric-classification exercise
By the end you can
- Rewrite a model capability as a user outcome for a named population and situation
- Choose a baseline that represents the real alternative users would have
- Classify metrics as primary, guardrail, diagnostic, operational, or data quality, and define a numerator, denominator, unit, and window
- Explain what offline evaluation can and cannot tell you compared with a randomized online experiment
- Compute absolute and relative change from per-arm counts and say what they do not establish
- Explain why more engagement, such as longer sessions, is not evidence of benefit on its own
Prerequisites
Helpful background: Comfort with percentages helps. No statistics background is assumed.
This topic covers user outcomes, baselines, online experiments, cost guardrails, and ship decisions. Evaluation & Observability covers offline evaluation mechanics.
Start with a user problem
A model capability is not a product outcome. "We can generate explanations" describes a capability. "Learners can identify their mistake and solve a similar exercise independently" describes an outcome.
Suppose a coding-practice platform adds AI hints. They should help learners progress without simply revealing the answer. The product question is whether the experience improves learning under acceptable correctness, latency, accessibility, and cost constraints.
Define the target population and situation. A beginner learning loops and an experienced developer rehearsing system design may need different help. Do not assume one average result applies to both.
Compare with a meaningful baseline
Possible baselines include no feature, existing human-written hints, a search tool, a deterministic rule, or the current AI implementation. Choose the baseline representing the real alternative users would have.
A comparison with a deliberately weak prompt exaggerates the value of a new model. Compare a viable incumbent and include the effort needed to maintain each approach.
AI may be unnecessary when a fixed rubric or curated hint solves the problem reliably. The experiment should test usefulness rather than justify an implementation chosen in advance.
Write a testable hypothesis
A useful hypothesis names a change, a population, an expected outcome, and important limits.
Example: "For learners starting a supported beginner exercise, staged AI hints will increase the probability of solving a related unassisted exercise within seven days, without increasing answer disclosure beyond the agreed tolerance."
This is an illustrative hypothesis, not a recommended universal metric or duration. The observation window must fit the behavior you want to measure and the available traffic.
Build a metric hierarchy
| Metric type | Example | Purpose |
|---|---|---|
| Primary outcome | Unassisted success on a related exercise | Tests the main product claim |
| Guardrail | Incorrect hints or excessive answer disclosure | Limits unacceptable trade-offs |
| Diagnostic | Hint requests, retries, abandonment | Helps explain mechanisms |
| Operational | Latency, availability, cost | Checks feasibility of delivery |
| Data quality | Missing events or assignment imbalance | Checks whether results are trustworthy |
Choose definitions before looking at results. Specify the numerator, denominator, unit of analysis, and time window. "Completion improved" is ambiguous if one variant changes which users are counted.
More hint requests may mean engagement or confusion. More time spent may mean interest or difficulty. Interpret a metric in relation to the user outcome, not its direction alone.
Offline evaluation versus online experiments
Offline evaluation uses a fixed or sampled dataset to assess outputs before broad exposure. It can check correctness, instruction following, schema validity, unsupported claims, and important task slices. It is useful for finding obvious regressions and comparing candidates under controlled inputs, but it cannot fully predict whether users notice, trust, understand, or benefit from the feature. If a model is repeatedly tuned to a benchmark, that benchmark becomes less informative about unseen cases, so keep evaluation examples independent of development choices where practical.
An online controlled experiment (an A/B test) assigns eligible units at random to a control or a treatment and compares outcomes. Random assignment makes the groups comparable in expectation, so a difference can be attributed to the tested change under the experiment's assumptions.
Choose an assignment unit that matches the experience. User-level assignment often avoids showing one learner inconsistent hint behavior across sessions. Team or classroom settings may need different units because people influence one another.
An experiment is not a casual before/after comparison. Traffic, seasonality, marketing, and other releases change over time and can create misleading differences.
Assignment, exposure, and outcomes
Assignment means a unit belongs to a variant. Exposure means the unit actually encountered the relevant feature. Outcome means the defined result was observed during the window.
These are different events. If treatment makes the feature harder to load, analyzing only users who successfully saw it may hide the harm. Start with the planned analysis population and document missing data and delivery failures.
Check that observed assignment counts are consistent with the configured split. A substantial unexpected mismatch, called a sample ratio mismatch, can indicate assignment or logging problems and makes causal conclusions unsafe until investigated. A chi-square test of the observed counts against the configured split is the usual check.
Absolute and relative changes
Worked example
Suppose control has 200 successful learners out of 1,000, while treatment has 220 out of 1,000. The rates are 20% and 22%.
The absolute difference is 2 percentage points. The relative increase is 10%, calculated as (22% - 20%) / 20%. Both describe the same observed change, but answer different questions.
These counts alone do not establish that the effect is reliable or worth shipping. With 1,000 learners per arm, a 95% interval for the difference (normal approximation) runs from about -1.6 to +5.6 percentage points: it includes zero, so this observed gain is also consistent with no effect. Consider uncertainty, experiment validity, practical importance, and guardrails. Relative lift is undefined when the control rate is zero.
Uncertainty and duration
Observed differences fluctuate because the experiment sees a sample of possible users and outcomes. A confidence interval expresses uncertainty under its statistical assumptions; it is not a guarantee about every learner.
Plan sample size and duration around a minimum effect worth detecting, expected baseline rate, variability, and desired error control. A small experiment can be inconclusive even when the observed result looks promising.
Repeatedly checking an ordinary fixed-horizon test and stopping as soon as it looks significant increases false positives. Use the planned analysis or an appropriate sequential method. Safety monitoring can still stop harmful exposure; that does not automatically establish efficacy.
Cost and value
Measure cost at the workflow level: model calls, retries, retrieval, tools, review, and support. A cheap request that often fails may cost more per useful outcome than a more expensive reliable one.
Report per-user or per-task spending as well as total cost. Include users who receive failures so the metric does not reward dropping difficult requests.
For a learning product, the value of a successful outcome is not identical to time spent or immediate revenue. Decide which outcome matters and whether the operational cost is sustainable.
Make a decision
Possible decisions are ship within limits, iterate, stop, or collect more evidence. An inconclusive result is not proof of no effect. A statistically detectable change can still be too small to justify complexity or cost.
A positive primary metric does not override an unacceptable correctness regression. Examine guardrails, important slices, and data quality before interpreting success.
After release, monitor whether the effect persists. Users may react differently after novelty wears off or the population expands.
Worked scenario: a hint pilot
Worked example
The platform, pilot, and figures are fictional.
Suppose a coding-practice platform piloted AI hints on its beginner exercises. Each learner who opened a supported beginner exercise for the first time during a two-week enrollment period was assigned by account, with a configured 50/50 split, to one arm:
- Control: the current curated hint, one human-written hint per exercise, shown on request.
- Treatment: staged AI hints, up to three per exercise on request, from a nudge to a near-complete solution.
Every assigned learner was followed for 7 days after assignment. A related exercise is a different exercise that practices the same concept. Before the pilot, the team agreed two tolerances for reviewed hint responses: at most 5% may reveal the full solution, and at most 3% may contain an incorrect statement. Reviewers scored a random sample of 200 hint responses per arm.
| ID | Metric | Control | Treatment |
|---|---|---|---|
| M1 | Median session length | 19 min | 26 min |
| M2 | Hint requests per assigned learner (mean) | 1.2 | 3.4 |
| M3 | Assigned learners who solved a related exercise without hints within 7 days | 405 of 2,024 | 415 of 1,976 |
| M4 | Sampled hint responses that revealed the full solution | 2 of 200 | 18 of 200 |
| M5 | Sampled hint responses with an incorrect statement | 1 of 200 | 5 of 200 |
| M6 | p95 time to first hint text | 0.2 s | 2.6 s |
| M7 | Model cost per assigned learner | $0.00 | $0.05 |
| M8 | Learners assigned | 2,024 | 1,976 |
The feature team's summary reads: "AI hints raised median session length from 19 to 26 minutes. Learners are clearly more engaged. Let's ship to everyone."
Classify the pilot metrics
Use the pilot table above and the five metric types in "Build a metric hierarchy".
Predict the outcome
Classify the pilot metrics
For each pilot metric, name its type (primary outcome, guardrail, diagnostic, operational, or data quality) and say what its figures show, computing rates over the stated denominators and checking guardrails against the agreed tolerances. Then reveal the answers.
| ID | Metric | Type | What the figures show |
|---|---|---|---|
| M1 | Median session length | ? | ? |
| M2 | Hint requests per assigned learner (mean) | ? | ? |
| M3 | Assigned learners who solved a related exercise without hints within 7 days | ? | ? |
| M4 | Sampled hint responses that revealed the full solution | ? | ? |
| M5 | Sampled hint responses with an incorrect statement | ? | ? |
| M6 | p95 time to first hint text | ? | ? |
| M7 | Model cost per assigned learner | ? | ? |
| M8 | Learners assigned | ? | ? |
Design a test with a different baseline
This exercise changes the baseline. Assume the same platform and traffic as the hint pilot.
Design exercise
Design a test: staged hints versus a full explanation
Suppose the same platform's current help on beginner exercises is a single full explanation: one worked explanation of the solution, shown when the learner asks. The team wants to test staged hints (a nudge, then the concept, then partial code, each on request) against it.
Requirements
- Define the population and the baseline arm
- Define one primary outcome with numerator, denominator, unit of analysis, and window
- Name three guardrails and how each is measured
- Choose the assignment unit and the observation window
- Say who is included in the analysis
Constraints
- Every definition must be written down before any result is seen
- Traffic is about 2,000 new learners per week, as in the hint pilot
Deliverables
- A short test plan as a table or a list, with one reason per choice
Completion checklist
- Rewrite a capability claim as a user outcome with a population and situation.
- Name the baseline that represents the users' real alternative, and say why.
- Classify the eight pilot metrics and define the primary outcome's numerator, denominator, unit, and window.
- Compute absolute and relative change from per-arm counts and say what they do not establish.
- State a decision rule, including guardrail limits, before seeing any result.
Sources
- Microsoft Research: Patterns of Trustworthy Experimentation, Pre-Experiment Stage Recommends starting from a testable hypothesis with success metrics chosen in advance, including guardrail metrics in the core metric set, and checking statistical power before the test.
- A Dirty Dozen: Twelve Common Metric Interpretation Pitfalls in Online Controlled Experiments (Dmitriev et al., KDD 2017) Catalogs common ways experimenters misread metric movements in A/B tests, with examples and guidance on detecting and avoiding each.
- Microsoft Research: Diagnosing Sample Ratio Mismatch in A/B Testing Defines sample ratio mismatch as a statistically significant difference from the configured split, explains why results should not be trusted until it is explained, and detects it with a chi-square test.
- Evan Miller: How Not To Run an A/B Test Shows that repeated significance testing increases the false positive rate, and recommends fixing the sample size in advance.
The coding-practice platform, hint pilot, figures, tolerances, exercises, and rubric are original synthetic teaching material about a fictional application; no real experiment was run. Study times and readiness thresholds are editorial estimates.
Related on CodeSnatch
Lessons, problems, and articles that build the skills this question uses.
Behavioral Interview
Practice reporting a change with its delta, denominator, and baseline, as the pilot's absolute and relative lift calls for.
Practice problem
Code the per-arm rate and lift arithmetic yourself, including the relative lift that has no value at a zero control rate.
AI Engineering
Sorts tool activity from outcome measures and adjusts a before-and-after comparison, applied to a team's coding assistants.
System Design
An advanced read on why offline scores and short-term clicks can mislead, and why outcomes need online tests.
Practice the interview question
Answer it in your own words before you look at the reference answer.
