OpenAI & Anthropic.
Referrals and interview preparation.

• Separate durable conversation state from transient UI state; give messages stable IDs.
• Demonstrate success, failure, and retry; avoid double submission.
• Keep the first version small enough to run before adding polish.

• What survives rotation and what survives process death?
• How do you handle an empty or extremely long reply?

Your evidence: L02, V06

• Spend the first minutes reproducing and ranking symptoms.
• Trace ownership of asynchronous work and the source of UI state.
• Verify fixes by replaying the original steps, then add a focused regression check.

• A slower earlier request overwrites a newer result: where should cancellation or request-version checks live?
• Which bug do you leave for later, and why?

Your evidence: L04, V04

• Define generating, completed, stopped, and failed states explicitly.
• Tie each stream to a response ID; stop stale collectors updating the active conversation.
• Keep durable messages separate from transport events and consider batching UI updates.

• How do cancellation and network failure differ?
• Can a retry duplicate text or duplicate billing?

Your evidence: L02, L03

• Specify whether saved state denotes the next unread item.
• Test empty input, exhaustion, nested empty lists, and replay from a saved state.
• Keep state independent of caller mutation, or explicitly reject mutable inputs.

• What if input changes after state is saved?
• How do you version a persisted state format?

Your evidence: V07

• Normalize and deduplicate according to an explicit URL policy before scheduling.
• Track pending and active work so termination does not race with discovery.
• Test cycles, repeated links, fetch failures, and concurrency limits.

• What happens when two workers discover the same URL?
• How would retries and a durable frontier change the design?

Your evidence: V01

• Define conservation-of-funds and insufficient-balance rules.
• Make ordering of scheduled events and duplicate operation IDs explicit.
• Test a full-balance withdrawal and its reversal as separate transitions.

• What changes when an account is merged?
• Which validation rules apply to a refund rather than a new debit?

Your evidence: V04, V03

• Specify missing-key, overwrite, deletion, and scan-order behavior.
• Make the expiry boundary deterministic and test just before/at/after expiry.
• Do not add backup/restore or thread safety unless the requested contract needs them.

• Does an overwrite reset expiry?
• How would a restore interpret the remaining lifetime?

Your evidence: V02, V08

• Agree on duplicate timestamps and out-of-order writes.
• Test missing keys, times before the first value, exact hits, and between-version queries.
• Explain lookup/write costs for the chosen representation.

• How do concurrent readers observe a consistent version?
• What changes under a memory-retention limit?

Your evidence: V02, V04

• Draw the mobile/service boundary before scaling the backend.
• Specify message IDs, ordering, acknowledgments, completion, and reconnect semantics.
• Define time to first visible content, completion latency, error rate, and crash-free sessions as proposed metrics.

• The app restarts during generation: what does it render?
• When should partial output become durable?

Your evidence: L02, V06

• Declare authoritative versions and a conflict policy.
• Separate local draft state from committed conversation history.
• Explain reconciliation, tombstones, and how old clients handle additive models.

• What happens if both devices retry the same send?
• How are branching replies represented?

Your evidence: L02, V07

• Name a small reusable contract and what stays product-specific.
• Describe adoption, compatibility, ownership, and migration sequencing.
• Propose rollout and reliability measures rather than assuming a velocity gain.

• How do you avoid a framework that blocks product teams?
• When do you permit a local implementation instead of extending the library?

Your evidence: L03, L11

• Separate sponsorship labeling, eligibility, rendering, and measurement.
• Define visible impressions, clicks, exposure deduplication, and reliability guardrails.
• Preserve user control and protect normal conversation interaction.

• How do you distinguish a downloaded ad from a viewed ad?
• How would you gate a rollout and evaluate engagement without claiming causality from a raw count?

Your evidence: L15, L03

• Define ownership of recording, playback, and audio focus.
• Specify cancellation and cleanup on navigation or lifecycle changes.
• Explain permissions, failure UI, and tests using deterministic fake audio components.

• A reply arrives after the screen closes: what should happen?
• How do navigation guidance and conversational playback share audio priority?

Your evidence: L03, L04

• Separate a successful agent run from an accepted and merged PR.
• Bound permissions, isolate workspaces, and make restarts recoverable.
• Propose a measured cohort with comparable task complexity, review effort, defects, and cost.

• How do you prevent duplicate jobs creating duplicate branches?
• Which steps always require a human decision?

Your evidence: L01, V01, V08

• Write invariants for debit, settlement, decline, and refund.
• Do not claim a queue or single regression test gives exactly-once processing.
• Explain server authority, transaction boundaries, reconciliation, and user-visible pending states.

• A decline follows a full-balance debit: which account is checked?
• How is a duplicate callback recognized?

Your evidence: V03, V04

• Distinguish accepted work from completed user-visible effects.
• Use queue age, arrival/completion rate, failure count, and dependency saturation to identify overload.
• Explain graceful degradation and which operations cannot be delayed.

• What changes when processing fails after a partial write?
• How would you decide whether to throttle producers or add workers?

Your evidence: V01, V02

• Use Driver AI, reusable speech, or ads-pin contribution according to the role.
• Explain a specific interest in AI products and a real engineering concern.
• Keep AI product integration distinct from model-training expertise.

• Why this team over a generic AI company?
• What would you need to learn in your first month?

Your evidence: L02, L03, L15

• Connect interest in trustworthy interaction to engineering behavior, not a memorized mission statement.
• Use one real rollout or callback example and name its limits.
• Be candid about open questions and what evidence could change your opinion.

• Would you delay a feature that behaves unpredictably?
• What safety concern about an AI assistant do you disagree with or find unresolved?

Your evidence: L04, V04

• Name your Android responsibility, partners, and contract ownership separately.
• Explain one difficult state transition and the chosen tradeoff.
• Use launch/reuse evidence; reserve engagement or earnings claims for an actual experiment.

• What did you personally implement?
• What would you change if you rebuilt it?

Your evidence: L02

• Lead with queued workers, review gates, recovery, and integration you owned.
• Do not present tool-repository PR counts as generated-PR output.
• Label proposed measures as future evaluation rather than results already observed.

• What generated changes did reviewers reject?
• How would you compare assisted and unassisted tasks fairly?

Your evidence: L01

• Keep the Android 16 incident separate from the Android 17 lifecycle race.
• Describe your responder role without adopting incident-commander decisions.
• Use the roughly three-day targeted-fix timeline without inventing a reliability percentage.

• What proved the affected cohort?
• How did you validate a release build on actual hardware?

Your evidence: L04, L05, L12

• State the other person's valid concern.
• Name the alternatives, evidence, and decision owner.
• Use an actual resolution; do not manufacture agreement or an experiment result.

• What if the team chose the option you opposed?
• What feedback changed your approach?

Your evidence: L06, L09, L02

• Walk through balances before debit, after debit, and after refund.
• Explain why reversing an operation needs different preconditions.
• Acknowledge that affected-user counts and remediation totals are not established.

• Did you introduce the original bug?
• What tests would cover repeated or out-of-order callbacks?

Your evidence: V04, V08

• Define starting responsibility and the ownership change you observed.
• Show how feedback, review, and API design helped other engineers work independently.
• Use two hires and three products as scope; avoid inventing productivity lift.

• How did you avoid becoming the permanent reviewer bottleneck?
• What did a teammate contribute that you should credit?

Your evidence: L11, L03