How to read this. I wrote both answers below for the same prompt. They are examples, not recordings of real people or real rounds. The strong answer uses the send path from the chat app case study. The weak answer uses the mistakes that the case study lists.
1. The prompt
"Design the chat feature for our app. People message one to one and in small groups."
I look at one part only: the user taps send. The case study calls this the send path. It is minutes 22 to 33 of the round.
2. The weak answer
"The user taps send. The ViewModel starts a coroutine and calls the send API. When the server answers, I add the message to the list. If it fails, I show an error and the user taps again. I would use WorkManager for retries."
This is not a silly answer. It is how many people first think about it. Here is what it skips.
- No first idea that fails. The candidate gives one design and does not test it.
- No failure table. The answer covers the normal case. It does not say what the user sees when the app stops or the signal drops.
- No decision with a cost. The candidate names WorkManager but not why. The case study lists this as a weak pattern: naming a tool without saying what breaks without it.
- No safe retry. A lost reply makes the retry send the message twice.
The case study names three problems with the coroutine idea:
- The bubble waits for a round trip.
- If the user leaves the screen or the process stops, the call is cancelled.
- A plain retry after a lost response sends the message twice.
3. The strong answer
"A send is a row before it is a request. In one transaction, I insert the row as PENDING with a new clientId, so the bubble shows. A WorkManager worker sends it, one chain per conversation. Success fills in serverId and seq. Temporary failures retry with backoff. A permanent failure marks the row FAILED, and the user taps to retry."
The words come from the case study. Now I walk through what the strong answer does.
The first idea, and why it fails
The strong candidate says the weak design out loud first. Then the candidate says why it fails. This matches the "first idea, and why it fails" beat in the case. It shows that the final design comes from a reason and not from memory.
The failure table
The strong candidate walks the failure table. Each row has a clear end:
| Failure | What the user sees | What fixes it |
|---|---|---|
| Process dies mid-write | The bubble was already there and it finishes sending | The worker resumes from the PENDING row |
| Lost acknowledgement | One bubble | The same clientId is retried, and the server returns the original answer |
| Permanent rejection | "Tap to retry" | The row is marked FAILED |
The guide on idempotency keys explains the lost acknowledgement in more detail.
The decision with its cost
The candidate does not stop at the design. The candidate says what it costs and how to undo it:
- The new send path goes behind a remote flag. The case calls it the kill switch.
- A schema migration cannot be flagged off, so it ships one release early.
- Old app versions stay installed for months, so the server keeps accepting the old request.
The candidate also says what to watch after release: tap-to-ack time, failed sends, duplicate rows and reconnects.
4. Side by side
| Part | Weak answer | Strong answer |
|---|---|---|
| First idea | One design, not tested | Says the first design and why it fails |
| Retry | "Use WorkManager" | A clientId makes the retry safe |
| Failures | The normal case only | A table: what fails, what the user sees, how it ends |
| Decision | No cost named | The flag, the migration and the old versions |
| Watch list | None | Four numbers to watch |
5. How to use this
Say your own answer for the send path aloud. Then ask three questions:
- Did I say my first idea and why it fails?
- Did I say what the user sees when it fails?
- Did I say what the choice costs and how to undo it?
If any answer is no, read the send path again. Then fill in the score sheet. The mock interview script has the follow-up questions.
More in the practice kit
Words on this page (9)
- Acknowledgement
- A short reply that says the server got a message. If this reply is lost, the app does not know, so it sends the message again.
- Coroutine
- A light background task in Kotlin. It can pause and continue later without blocking a thread.
- Exponential backoff
- Waiting longer after each failure. For example, wait 1 second, then 2, then 4.
- Kill switch
- A remote flag that turns a feature off at once. It is the one rollback that reaches apps that are already installed.
- Remote flag
- A setting that the server can change. It can turn a feature on or off without a new release.
- Schema migration
- A change to the layout of a database. It must run safely when the user updates the app.
- Sequence number
- A number that grows by one with each message. It shows the order, and it shows a gap when a number is missing.
- ViewModel
- A class that holds the state of one screen. It survives a screen rotation.
- WorkManager
- Android's tool for background work that must run later. The work survives when the app closes or the phone restarts.
Written by Manuel Lorenzo. The site is drafted with AI assistance and edited and reviewed by him.