IMPACT BULLETS AND MEASUREMENT PLANS - DAVID CHUNG
October 2, 2026 | PRIVATE INTERVIEW PREPARATION

STATUS
The example numbers below are HYPOTHETICAL. They are invented for rehearsal and have not been measured. A measurement design is a plan, not evidence that the result occurred. No hypothetical figure was inserted into the application resume.

PATTERN
Write each resume bullet as: outcome + personal contribution + measured result or meaningful scope.
Use Project-Action-Result to check that the reader can identify what problem mattered, what you did, and what changed. Put the strongest outcome early, keep the mechanism concrete, and use one coherent accomplishment per bullet. A launch, cross-product reuse, or corrected behavior can be an outcome without a percentage.

Sources:
MIT, Career toolkit: Crafting an effective resume
https://capd.mit.edu/resources/career-toolkit-crafting-an-effective-resume/
MIT, Resumes: Writing about your skills
https://capd.mit.edu/resources/resumes-writing-about-your-skills/
Harvard, Guide to Creating a Strong Resume
https://careerservices.fas.harvard.edu/resources/create-a-strong-resume/

RESUME UPDATE
The Lyft heading is now Senior Software Engineer, Android. AI ownership remains in the accomplishments.
Driver AI is described as an earnings assistant, matching the local reference document. The previous inference-latency, static-map savings, and first-PR percentages were removed from the Eight Sleep version to prioritize the documented mobile stories. The pipeline description now matches the documented iOS/Android draft-PR workflow.
Verdict emphasizes native product flows, queued processing, query design, compatibility, and refund correctness. Existing employment dates remain unchanged pending clarification of later involvement.

EXISTING EVIDENCE THAT CAN SUPPORT IMPACT

Lyft: public Driver AI launch and Android client ownership are reported in the local story bank.
Lyft: one speech framework reused across Driver AI, RiderAI, and navigation supports a three-product scope claim. It does not establish a percentage reduction in delivery time.
Lyft: 600+ drivers switching voices within about 10 days of early rollout is reported in the document, which cites a tech-lead update. This is a count of switchers; it is not an adoption percentage across all eligible drivers. Retrieve the underlying analytics and define unique switchers, rollout exposure, and the interval if asked.
Lyft: the Android 17 crash signature had 37 fatal events across 31 drivers according to the document. This describes the problem's scope, not a measured post-fix crash reduction. Events and affected drivers are different denominators.
Verdict: 100K+ users is a prior-resume claim; confirm whether this means registered users, active users, or another definition. The repository does not audit the count.
Verdict: the refund regression test asserts that the original balance is restored after the decline sequence. That supports corrected behavior; it does not quantify historical refunds recovered.
Verdict: later home-query work is described as approximately 18 to 6 per-user queries in a commit, a roughly 67% static reduction. This is a code-path estimate from 2026, not a measured production latency/QPS reduction. It belongs under the actual later work arrangement once that chronology is clarified.

HYPOTHETICAL EXAMPLE L1 - DRIVER AI RELIABILITY

Invented rehearsal metric: duplicate-message incidents decrease from 10 to 3 per 1,000 conversations, a 70% relative reduction.
Hypothetical bullet: Reduced duplicate-message incidents by 70% by correcting Android/backend message handling ahead of the Driver AI launch.
Actual basis: the document reports cross-team debugging of a duplicated-message launch blocker, but no incident-rate result.
Proposed measurement: define a duplicate as two rendered message records representing one authoritative message ID within the same conversation, rather than repeated text that can be legitimate. Count distinct affected conversations over all eligible conversations. Use instrumented QA replays or sufficiently logged app sessions; specify which population the result describes.
Validation: replay identical server responses against old/new client code, include retry/reconnect/recreation cases, and assert no messages are lost. For rollout observations, compare client versions within device/network cohorts and note concurrent backend changes.
Evidence required: the actual denominator, duplicate classification, baseline/new samples, build identifiers, and a saved analysis. If historical sessions lack the necessary IDs, report a replay-test result instead of reconstructing production incidents.
Limits: a release comparison is observational; a shared backend fix prevents attributing the full change solely to Android.

HYPOTHETICAL EXAMPLE L2 - SHARED VOICE PLATFORM

Invented rehearsal metric: median engineering effort for a comparable voice integration decreases from 8 to 4 engineer-days, a 50% reduction.
Hypothetical bullet: Halved voice-integration effort by consolidating speech services into a framework reused across three products.
Actual basis: shared framework reuse is documented; engineer-days are not.
Proposed measurement: record implementation, review, and validation effort separately from calendar delay. Compare integrations with equivalent requirements, supported languages, Android versions, and acceptance tests. Use multiple comparable integrations and disclose sample size; three product names do not imply three measured integration samples.
Validation: ensure the shared version supports the same behavior, failure states, and rollout controls. Exclude time spent on unrelated new UI or backend requirements and show sensitivity with and without ambiguous effort estimates.
Evidence required: task histories or contemporaneous effort records, the inclusion rules, samples, and calculation. Do not describe retrospective estimates as tracked time.
Limits: differing project complexity and accumulated engineer experience confound a before/after comparison. Without adequate effort evidence, use the documented three-product reuse outcome.

HYPOTHETICAL EXAMPLE L3 - ANDROID AUTO RELIABILITY

Invented rehearsal metric: target-signature fatal crashes decrease from 4.0 to 0.8 per 1,000 Android Auto connections, an 80% reduction.
Hypothetical bullet: Reduced a targeted Android Auto crash rate by 80% by fixing a lifecycle race during host-surface teardown.
Actual basis: the Android 17 lifecycle race and 37 events/31 drivers are documented; no normalized post-fix reduction is recovered.
Proposed measurement: count target-signature fatal events over Android Auto connection attempts for the affected OS cohort. Specify the event window, app version, head-unit/device mix, rollout exposure, and whether reconnects count as additional attempts.
Validation: reproduce teardown/recreation on physical hardware, verify resource release, then observe the fixed rollout. Monitor non-fatals and reconnect success so catching an exception is not mistaken for preserving functionality.
Evidence required: crash-signature dashboard, connection denominator, version/OS filters, release/flag timeline, sample size, and post-rollout observations.
Limits: avoid a broad app-wide crash-free claim from one signature. If connection telemetry is unavailable, use the existing session denominator and label it accurately. Do not retain a known crash solely to create a control group.

HYPOTHETICAL EXAMPLE L4 - AI DELIVERY PIPELINE

Invented rehearsal metric: median request-to-first-CI-passing-draft time decreases from 48 to 28 hours, a rounded 42% reduction.
Hypothetical bullet: Cut median time to a CI-passing mobile draft PR by 42% with a gated multi-agent iOS/Android delivery pipeline.
Actual basis: the pipeline, workers, security, infrastructure work, and organization-wide packaging are documented; cycle-time impact remains an explicit gap.
Proposed measurement: start the clock when a request is accepted with sufficient requirements; stop when the first draft passes the required checks. For paired-platform work, stop only when both platform drafts meet that bar. State business-hours versus wall-clock time and include failed attempts.
Validation: compare a representative task cohort with a manual workflow or matched historical tasks. Stratify by change size and complexity. Separately track review effort, merge rate, time to merge, rework, and escaped defects.
Evidence required: request and PR timestamps, acceptance criteria, CI results, all sampled tasks, exclusions, and manual-baseline construction.
Limits: first-draft speed is not team velocity or shipping speed. Counting generated PRs alone rewards output that may never be accepted.

HYPOTHETICAL EXAMPLE V1 - LIVE-EVENT QUEUES

Invented rehearsal metric: p95 admission latency decreases from 900 to 250 milliseconds in a controlled live-event burst benchmark, a rounded 72% reduction.
Hypothetical bullet: Reduced p95 request-admission latency by 72% in burst testing by moving notification fan-out into bounded Redis-backed queues.
Actual basis: queue changes are supported by 6d8d72ddc, 5f4574ede, and 9cdb7b76d. No historical production percentile is established.
Proposed measurement: compare old/new commits on the same hardware, dataset, client workload, and provider stub. Timestamp request receipt and successful durable admission. Run multiple representative burst profiles and retain raw latency distributions, success counts, and errors.
Validation: also measure queue age, end-to-end completion, throughput, retries, connection saturation, and duplicate work. Verify that faster acknowledgement does not conceal dropped jobs or unbounded backlog.
Evidence required: load script, fixture, commit IDs, environment/configuration, independent runs, latency samples, and correctness assertions.
Limits: this measures admission, not completed scoring or delivered notifications. A benchmark run now must be dated now; it is not a recovered 2023 production measurement. Do not translate the result into 100K concurrent users/requests.

HYPOTHETICAL EXAMPLE V2 - LEADERBOARD READS

Invented rehearsal metric: p95 query duration decreases from 240 to 72 milliseconds, a 70% reduction in a controlled benchmark.
Hypothetical bullet: Cut p95 leaderboard query time by 70% by adding a composite index aligned with tournament filtering and ordering.
Actual basis: index commit 67fd2b607; the performance result is not recovered.
Proposed measurement: replay the same parameterized queries against equivalent database snapshots before/after the index. Separate warm/cold cache and popular/small tournaments. Record rows examined, query plans, duration, concurrency, and writes during the run.
Validation: compare ordered results and pagination boundaries, check storage/write overhead, and retain older-client compatibility cases. A single EXPLAIN plan demonstrates access strategy, not a latency percentile.
Evidence required: exact SQL, schema/index diff, dataset distribution, database version/settings, sufficient repeated runs, and raw timings.
Limits: a faster isolated query does not prove the same reduction in endpoint latency. A recreated benchmark supports a benchmark claim, not historical customer impact.

HYPOTHETICAL EXAMPLE V3 - ANDROID DEPOSITS

Invented rehearsal metric: settled-deposit completion rises from 74% to 82%, an 8 percentage-point increase, approximately 11% relative.
Hypothetical bullet: Increased deposit completion by 8 percentage points by improving native payment navigation and pending-state handling.
Actual basis: Android payment integration commits 34ee02b57 and e03ea03a3. No conversion result is recovered, and no optimization of this size is established.
Proposed measurement: use distinct payment-attempt IDs to connect deposit initiation to authoritative provider settlement. Define an eligibility population and completion window, such as settlement within 24 hours, before examining results. Treat pending attempts consistently rather than as immediate successes or failures.
Validation: account for retries, asynchronous callbacks, cancellations, decline reasons, platform/build differences, geography, payment method, and returning users. Prefer a planned rollout comparison when feasible; otherwise report the observational nature of the result.
Evidence required: authoritative transaction states, event definitions, deduplicated attempt funnel, sample sizes, app release timeline, and comparable cohorts.
Limits: WebView success redirects are not settlement. Missing historical attempt telemetry prevents a trustworthy historical completion-rate claim.

HYPOTHETICAL EXAMPLE V4 - REFUND CORRECTNESS

Invented rehearsal metric: 1,000 generated callback-sequence cases complete without a balance invariant violation after the fix.
Hypothetical bullet: Validated declined-withdrawal refund handling across 1,000 generated callback sequences by correcting ledger preconditions and adding invariant tests.
Actual basis: 0c463bc70 includes a specific full-balance decline regression test. A 1,000-case test run does not exist in this review.
Proposed measurement: implement a documented, seeded generator of valid provider-state sequences and relevant edge cases. Assert original-balance restoration after declines, ledger consistency, no duplicate refund, and transactional behavior. Distinguish expected duplicate callbacks from invalid provider transitions; do not assume this fix already handles every ordering.
Validation: run the harness against old/new implementations and report the exact failing cases, executed cases, seed, and coverage boundaries. Minimize failures into regression tests. Introduce separate fixes if the harness reveals other defects.
Evidence required: the actual harness, seed/configuration, test output, commit IDs, and invariant definition.
Limits: a simulation count is test scope, not users protected, refunds recovered, or a production failure rate. Without executing the harness, use the actual targeted regression-test outcome.

MEASUREMENT ANSWER FOR AN INTERVIEW

For an actually established metric, prepare: definition, denominator, baseline, new value, window/cohort, evidence source, personal contribution, and limitation.
Example structure: We measured [precise endpoint or behavior] over [population and interval]. The baseline was [value] and the new value was [value], using [actual source]. I changed [mechanism]. We checked [guardrail]. The comparison supports [bounded claim]; it does not establish [broader claim].
For every example above, say how you WOULD measure it until the data or test run exists. Do not rename a proposed plan as a historical measurement.

MATH AND CLAIM CHECKS

Relative reduction = (baseline - new) / baseline.
Percentage-point change = new rate - baseline rate.
Use the same unit/denominator on both sides. Average, median, and p95 are different claims.
A before/after improvement can be associated with a release without proving sole causation.
Impact can be a public launch, reuse across products, corrected state transition, reduced code-path work, or expanded test scope. A percentage is optional.
Trace a numerical claim to evidence before adding it to the application PDF. Keep the hypothetical label attached when practicing these examples.

FILES
Updated application PDF: /Users/dchungdev/Resume/David_Chung_Eight_Sleep_Resume.pdf
Updated source: /Users/dchungdev/Resume/David_Chung_Resume.tex
The original and pre-impact versions are preserved in resume-backup/.


ADDITIONAL VOICE USAGE AND ADS PRACTICE — October 2, 2026

HYPOTHETICAL VOLUME/USAGE EXAMPLE — NOT A HISTORICAL RESULT
Practice line: Voice choice increased audio-enabled navigation trips from 60% to 66% among eligible drivers, a six-percentage-point absolute lift (10% relative).
These are invented practice values. Do not use them as resume facts or imply that this measurement occurred.
Proposed measurement: randomize eligible drivers into voice-choice and existing-experience cohorts; predefine eligibility, assignment, exposure, audio-enabled-trip event, completed-trip denominator, and the experiment window. Analyze by assigned cohort to avoid selecting only enthusiastic switchers. Report unique drivers, trip counts, uncertainty, missing telemetry, and repeat usage at an agreed retention window. Monitor driving distraction, voice interruptions, complaints, cancellations, crash-free sessions, and pickup/drop-off satisfaction as guardrails. A before/after comparison alone cannot isolate voice choice from seasonality or other releases.
Actual available scope: three reused product surfaces; roughly 750K reported eligible drivers; 600+ early switchers during a partial rollout. Actual randomized usage uplift is not in the supplied evidence. Confirm platform scope before attributing the whole audience to Android.

ADS PINS — MEASUREMENT DESIGN, NO CLAIMED RESULT
User reported contributing to ads pins. Implementation scope and launch status remain unconfirmed.
Proposed exposure: count a viewable sponsored pin once it meets a documented viewport/duration criterion, with creative/request IDs and deduplication. Distinguish served assets, rendered pins, viewable impressions, clicks, and completed advertiser actions. Define CTR as unique qualifying clicks divided by eligible viewable impressions, not all map sessions. Attribution windows and downstream conversion authority belong to the advertiser/backend contract; state the limitations. Use user-level randomization where possible and monitor map rendering latency, clutter, navigation success, accidental taps, and retention. Recover a real launch/readout before reporting a metric.
Future audio advertising: potential reuse of speech generation/playback, not evidence of a launched product or revenue. A proposed design would require clear sponsorship attribution, navigation priority, interruption limits, appropriate user controls, and separate exposure/completion measurement.