In this article
Before you start
This page is one question in the product and analytics case interviews path, alongside data science interview questions. It needs three small ideas, each explained in a sentence below.
Why interviewers ask this
The question separates candidates who treat "data quality" as a slogan from candidates who can turn it into measurements. A product-sense round for engineers can ask it about any machine-learning product, and questions of this kind are reported by candidates in interviews at large tech companies.
A weak answer says "collect more data and clean it". That answer names no failure, no metric and no way to tell whether quality improved. A strong answer splits quality into parts, says who labels each part and how many cases they label, and names a trade-off. A Staff-level answer adds the effect most people miss: the data you collect depends on the earlier stages of the product, so changing one stage silently changes the data that every later stage is measured on. Siri is a good example because its pipeline has clear stages, and Apple has published how it reviews them.
Data quality on a voice assistant from first principles
- Data quality dimension
- A data quality dimension is a named property of data, such as accuracy, completeness, consistency, validity, timeliness or uniqueness, that lets a team measure how fit the data is for one purpose. It turns "quality" from a feeling into several separate numbers, each of which can be tracked and fixed on its own.
- False accept
- A false accept is a wake-word error in which the assistant wakes although the user did not mean to call it, for example on another person's voice or on a similar phrase. Audio and a transcript of a non-request then enter the data, and the product may act on them.
- False reject
- A false reject is a wake-word error in which the assistant stays asleep although the user did say the wake phrase. The request never reaches the speech recogniser, so it leaves no transcript, no log line and nothing for a reviewer to examine.
- Ground-truth label
- A ground-truth label is a correct answer written by a trained human reviewer for one example, such as the exact words spoken or the intent behind a request. A metric compares the system's output against it, so the metric is only as good as these labels.
Step-by-step description
- Wake, words and task need separate labels.
- A trigger change alters what reaches the logs.
- A small reviewed sample gives the error rate.
- Fix the weakest dimension, then measure again.
- Wake-word errors, transcription errors and task failures need three different labels.
- A change to the wake trigger changes which requests reach the transcription logs.
- A small human-reviewed sample gives the ground truth for the error rate.
- Fix the weakest dimension at its source, then re-measure.
In plain words
Think of a kitchen that serves thousands of dishes a day. The head chef cannot taste every dish. She tastes a small random sample and scores each one on separate things: temperature, seasoning, look. Then she fixes the worst of those. Data quality on Siri works the same way. The analogy breaks in one place: a kitchen sees every dish it makes, but Siri never sees the requests it failed to wake for. So the sample you review is always a sample of what got through, and you must say so when you report a number.
In one precise sentence, you improve data quality by defining separate measurable dimensions, estimating each from human-labelled samples, and acting on the weakest one.
Step 1: Split quality into three kinds of label
Quality on Siri is at least three problems with three kinds of label. Apple says its grading reviewed a small sample of audio from Siri requests, less than 0.2 percent, with computer-generated transcripts, to measure how well Siri was responding (Apple Newsroom, August 2019). Contractors told The Guardian (26 July 2019) that they graded whether the activation was deliberate or accidental, whether Siri could help and whether its response was appropriate.
Those reported criteria suggest three labels. Wake intent on logged requests finds false accepts. False rejects never reach the logs, so they need a separate labelled test set (Step 2). Hearing accuracy gives a transcript to compare against, which yields a word error rate. Appropriate response gives a task-success label.
Standards such as the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standard 25012 define data quality through characteristics like accuracy and completeness. Dagster's 2026 explainer lists accuracy, completeness, consistency, validity, timeliness and uniqueness. Accuracy is how correctly data represents the real event. Completeness is whether all required data is present, so false rejects are a completeness failure.
Step 2: Fixing the wake trigger changes the data you collect
The wake trigger decides which audio ever becomes data, so changing it changes every later metric. A very small speech recogniser runs all the time and listens for the wake phrase, and only then does the rest of Siri parse the speech (Apple, 2017). Unintended activations come from similar phrases or other people's voices (Apple). Apple chose the balance between false alarms and false rejects experimentally, and its word error rates are directly influenced by trigger performance (Apple, HomePod research).
Misses leave no transcript and are more likely in noisy places, so measure them on a scripted, labelled evaluation set recorded in quiet and noisy conditions; the HomePod research reports false-reject rates on evaluation data. In live logs, near-threshold trigger scores and repeat requests within seconds are proxy signals.
In this illustrative case, 10,000 requests are spoken, 2,000 in noisy rooms. Cutting the noisy miss rate from 10 to 4 percent adds hard audio to the logs, and a more sensitive trigger would also add false accepts, which this model leaves out.1
| Quantity (illustrative) | Before | After |
|---|---|---|
| Noisy-room requests logged | 1,800 | 1,920 |
| Measured word error rate | 9.67% | 9.92% |
The recogniser did not get worse; the logs got harder. Report quality by condition and keep trigger and recogniser dashboards separate.
Step 3: Measure each dimension on a reviewed sample
Humans label a small random sample, and the sample gives the error rate for the whole stream. Word error rate (WER) is the Levenshtein distance between the recognised words and the human reference transcript, divided by the number of words in the reference; the distance is the fewest substitutions, insertions and deletions that turn one word string into the other (arXiv 2211.16112). Automatic speech recognition (ASR) is the part of the system that turns speech into text, and WER is how it is scored.
| Reference | Heard | Edits | Reference words | WER |
|---|---|---|---|---|
| set a timer for ten minutes | set a time for ten minutes | 1 substitution | 6 | 16.67% |
| call mum at six | call at six thirty | 1 deletion, 1 insertion | 4 | 50% |
Take 1,000,000 requests a day (illustrative). Reviewing under 0.2 percent, the share Apple reported, means about 2,000 requests.1 For a yes/no rate such as false-accept share, 2,000 reviews give a worst-case margin of error of about 2.19 points at 95 percent confidence, shrinking with the square root of the sample size.1 WER can exceed 100 percent and its errors cluster within utterances, so bootstrap over sampled utterances for its interval.
Text description of the diagram
- At 2,000 reviewed requests the worst-case margin of error is about 2.19 points.
- The margin shrinks with the square root of the sample size.
Do not stop at WER. The arXiv paper notes that no single definition serves every purpose, and WER ignores how serious each error is: mishearing "timer" costs more than dropping "the".
Step 4: Fix the weakest dimension at its source, then re-measure
Fix the weakest dimension at its source, then re-measure. If noisy rooms drive the errors, the source is coverage: collect and label more noisy audio and re-score the same sample design. If false accepts drive them, the source is the trigger, and the trade-off against false rejects must be tuned and judged together.
Data collection has privacy limits that shape the fix. Apple says that by default it no longer retains audio recordings of Siri interactions and continues to use computer-generated transcripts to help Siri improve (Apple Newsroom). The consequence is that old audio cannot be re-transcribed by a better model, so ground-truth review has to rely on consented samples. Apple later made manual review opt-in and brought audio grading in-house, and its Siri Speech Study app lets participants explain what they meant when Siri misheard (TechCrunch, 2021). Apple also says personalised speech recognition runs on the device, which cuts what is sent to servers (Apple Legal). Test a fix with an experiment, as in reading an A/B test like a product owner.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
How would you improve data quality on a product like Siri?
I would not say "collect more data". I would first split quality into dimensions, because a voice assistant has several different failures: it wakes when nobody called it, it stays asleep when you did, it mishears the words, or it hears correctly and does the wrong thing.
Each needs its own labels: reviewers grade a small random slice of logged requests for false accepts, words and task success, and misses come from a scripted test set, since they leave no logs. I would watch for selection effects: changing the wake threshold changes which audio reaches the transcription logs. Then I would fix the weakest dimension at its source, re-measure on the same sample design, and keep privacy limits like opt-in review and no default audio retention in the plan.
What makes it Staff-level is the selection effect: you show that metrics at different stages of the pipeline are linked through the data, and you still end on a measurable fix. The spoken structure is: split the dimensions, sample and label each, name the trigger effect, fix and re-measure.
The rubric
This rubric is our own teaching tool, not any company's scoring sheet.
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | Says "clean the data" with no definition | Names accuracy and completeness | Maps each dimension to a Siri failure with its label |
| Depth | One metric, transcription only | Wake, transcription and task success | Adds the trigger's effect on the logs |
| Trade-offs | None | False accepts against false rejects | Adds privacy limits on retention and review |
| Communication | Lists ideas at random | Orders ideas: define, measure, fix | Says the sample size and the margin it buys |
| Follow-up readiness | Stuck on "how many samples" | Gives a rough sample size | Explains label agreement and re-measuring |
Three variants of this question
How would you measure whether Siri's answers are good?
Use the task-success label from Step 1: a reviewer judges whether Siri responded appropriately, and you report the share of sampled requests judged appropriate with its margin. The measuring AI products page covers the wider metric set.
How would you reduce false wake-ups without missing real requests?
Treat it as one trade-off with two error rates, not two goals. Move the trigger threshold, then report false accepts and false rejects together, split by noisy and quiet conditions, as in Step 2. If a metric moves after the change, work through it as in how to investigate a watch-time drop.
How would you collect more training data while protecting privacy?
Prefer opt-in review, on-device processing and transcripts over raw audio, and ask users to say what they meant, as the Siri Speech Study app does. Keep the labelled sample small and random so that a few thousand reviewed requests still give a usable error rate. For more case-style practice, see domain case rounds outside big tech.
Common mistakes
- "More data means better data." (wrong) Quality is fitness for a purpose, not volume. (right) "I would first find which dimension fails, then collect data for that dimension."
- "Data quality is transcription accuracy." (wrong) The reported grading also checked wake intent and response appropriateness. (right) "I score false accepts from logs, misses from a test set, and words and task success on a reviewed sample."
- "Fewer false accepts is always better." (wrong) Apple describes tuning false alarms against false rejects experimentally, so cutting one raises the other. (right) "I report both rates and pick the balance for the user experience."
- "Have people check every request." (wrong) Apple's grading reviewed under 0.2 percent of requests, and a sample is enough for a rate. (right) "A random sample with a stated margin."
- "Drop human review to protect privacy." (wrong) Human labels are the ground truth that every metric depends on. (right) "Keep review, make it opt-in and keep it in-house, as Apple did."
Follow-up questions
How do you measure requests Siri never woke for?
Misses leave no logs, so record a scripted, labelled evaluation set in quiet and noisy conditions and count how often the known phrase fails to wake the device; Apple's HomePod research reports false-reject rates on evaluation data. In live logs, near-threshold trigger scores and a repeat request within a few seconds are proxy signals, not ground truth.
How many requests do you need to review?
These margins apply to per-request rates such as false-accept share or task success, not to word error rate. About 2,401 for a plus or minus 2 point margin at 95 percent confidence in the worst case, or about 457 if the true error rate is near 5 percent.1 Review more when you want to compare conditions, because each condition needs its own sample.
How do you know the human labels are right?
Have two reviewers label the same small subset and measure agreement with a statistic such as Cohen's kappa, which corrects for chance agreement, then settle disagreements with written guidelines. If agreement is low, the labels are the problem, not the model.
Why not just use word error rate?
WER ignores how serious each error is and does not cover wake intent or task success, and the arXiv paper notes that no single definition serves all purposes. Use it as one dimension among several.
Does dropping stored audio hurt data quality?
It limits what you can re-label, because a new model cannot re-transcribe audio that no longer exists, while transcripts remain usable for training. Opt-in audio samples cover the gap for ground truth.
Should you drop human review because of privacy?
No. Apple suspended grading in 2019, then made review opt-in and brought it in-house, so the labels the metrics need still exist (TechCrunch).
- Split quality into dimensions, and give wake, words and task success their own labels.
- A change to the wake trigger changes which requests reach the transcription logs.
- Review a small random sample; a few thousand requests give a usable error rate.
- Fix the weakest dimension at its source, then re-measure with the same sample design.
- Keep privacy limits in the plan: opt-in review, in-house labelling and no default audio retention.
Sources
- Improving Siri's privacy protections — Apple Newsroom, 28 Aug 2019
- Siri, Dictation & Privacy — Apple Legal (undated page, read date shown), 26 Oct 2026
- Personalized Hey Siri — Apple Machine Learning Research (undated page, read date shown), 26 Oct 2026
- Optimizing Siri on HomePod in Far-Field Settings — Apple Machine Learning Research (undated page, read date shown), 26 Oct 2026
- Hey Siri: An On-device DNN-powered Voice Trigger — Apple Machine Learning Research, 1 Oct 2017
- On Word Error Rate Definitions and their Efficient Computation (arXiv 2211.16112) — arXiv (version 2, read date shown), 26 Oct 2026
- Apple launches a new iOS app, Siri Speech Study, to gather feedback for Siri improvements — TechCrunch, 20 Aug 2021
- Data quality dimensions — Dagster (vendor explainer, read date shown), 26 Oct 2026
- Apple contractors regularly hear confidential details on Siri recordings — The Guardian, 26 Jul 2019