0% completed
The Five Step Method and the 45 Minute Budget
On This Page
- Count the time available for design
- Step 1: agree on requirements
- Step 2: define the API and data model
- Step 3: explain the client architecture
- Step 4: examine the important mechanism
- Step 5: complete recovery, testing, and release details
- Adjust when time becomes short
- Practice with two time limits
Practice questions
Takeaway
A mobile design interview has limited time. A simple structure helps you explain a complete design without spending the whole session on one topic.
This course uses five steps: requirements; API and data model; client architecture; detailed discussion; and failure, offline behavior, and releases. The fourth step is also called a deep dive. It means explaining an important technical problem in more detail.
These steps are a practice method. You can return to an earlier step when new information changes the design. Failure handling should influence the answer throughout, not only at the end.
1. Count the time available for design
A 45-minute meeting does not always mean 45 minutes of design. If introductions take five minutes and your questions take another five minutes, 35 minutes remain for design.
Confirm the schedule. The following table provides sample practice plans, measured from the start of discussing the design question.
| Step | 45-minute plan | 35-minute plan | 30-minute plan |
|---|---|---|---|
| Requirements | 5 | 4 | 3 |
| API and data model | 8 | 6 | 5 |
| Client architecture | 10 | 8 | 7 |
| Detailed discussion | 17 | 12 | 11 |
| Failure, releases, and summary | 5 | 5 | 4 |
| Total | 45 | 35 | 30 |
The numbers are minutes, not fixed interview rules. A library question may need more interface detail. Follow the interviewer when the discussion changes.
2. Step 1: agree on requirements
45-minute practice plan: minutes 0–5.
Clarify whether the task includes the client, the API, or the backend too. Then agree on the main user actions.
For a photo feed, you might include reading posts and changing likes while excluding uploads and comments.
Ask about the conditions that affect the design:
- Must saved posts remain readable after restarting offline?
- Can a like be recorded offline and sent later?
- Are images guaranteed offline, or only available if still cached?
- How fresh must the displayed information be?
“Works offline” is not precise enough. Reading saved text and keeping every image available require different storage rules.
End this step with a short summary:
“We will show saved post information offline and preserve pending likes after a restart. Images are available only when cached. The backend exists, so I will clarify its paging and retry rules.”
3. Step 2: define the API and data model
Minutes 5–13.
An API contract defines communication rules. A data model describes the records and fields the system needs.
For this feed, explain:
- How the app requests the first and next pages.
- Which fields identify a post and its current like state.
- How the app sends a like change.
- How the server recognizes a repeated operation.
- Which local records must survive a restart.
If the API exists, clarify its behavior. Do not silently replace it with a different design.
Keep confirmed server state separate from a pending local change. Otherwise, a refresh could remove the user's pending like before it is sent.
Also separate replaceable data from user work. A downloaded thumbnail can usually be downloaded again. An unsent action may have no other copy.
Use calculations only when they help a decision. For example, image dimensions can explain a memory limit. A server-capacity estimate may not help a client-only question.
4. Step 3: explain the client architecture
Minutes 13–23.
Draw only the components needed for the main behavior. Describe their responsibilities, not just their names.
For example:
- The screen displays items and loading or error states.
- A state holder prepares the screen's data and handles user events.
- A repository coordinates local reads and network updates.
- A local database saves posts and pending actions.
- An image loader handles image downloads and memory use.
Follow one action through these parts. If the user taps Like, what is saved first? What does the screen show? Which component sends the request? How does the response update the saved state?
If a pending change and its send record must agree, save them in one transaction. A transaction makes related database changes succeed or fail together. Otherwise, the app could stop after saving the visible change but before saving the work needed to send it.
Explain what happens if local storage fails too. Do not show an action as safely recorded when the app could not save it.
5. Step 4: examine the important mechanism
Minutes 23–40.
Choose a problem that matters to the requirements. State why you are examining it.
“The important failure case is losing the reply to a like request. I will explain how the saved operation allows the app to recover without applying the change twice.”
Then answer five questions:
- What identifies this action?
- Which component can change its state?
- What happens if work overlaps or responses arrive in an unexpected order?
- What remains after the app stops?
- How is the result checked, and how would you test it?
A timeout may leave the result unknown. A safe retry needs server support, such as recognizing the same operation ID. Creating a retry queue does not establish that guarantee by itself.
Other useful topics include:
| Feature | Possible detailed discussion |
|---|---|
| Feed | Pagination and refresh while requests are running. |
| Chat | Saved sends, acknowledgments, and ordering. |
| Upload | Saved progress and resuming incomplete transfers. |
| Location | Update frequency, old data, and battery use. |
| Library | Cancellation and several callers sharing work. |
Explain one substantial topic before adding another. If the interviewer requests a different area, adjust the plan. Do not repeat an explanation later just because the schedule originally placed it there.
6. Step 5: complete recovery, testing, and release details
Minutes 40–45.
Use the final portion to check what remains unclear. Failure behavior discussed earlier already counts; you do not need to repeat it word for word.
For the feed example, test:
- The app stops after saving a pending like.
- The server applies the like but its response is lost.
- A refresh arrives while the like is pending.
- Local storage cannot save the action.
Choose measurements related to the risks. Time to useful content and the age of pending actions may help here. Explain what each measurement includes rather than only naming a dashboard.
Describe a suitable release plan. A limited initial release can help detect problems before more users are affected. A feature flag can disable prepared behavior, but it cannot repair every crash or instantly update offline devices.
Finish with the main result, cost, and unresolved assumption:
“The design keeps saved content and pending likes after a restart. It adds storage and recovery logic. Before implementation, I would confirm how long the service remembers operation IDs and how older pending work is handled.”
7. Adjust when time becomes short
For the 45-minute plan, the planned transition times are 5, 13, 23, and 40 minutes. Use them to check progress, not to stop in the middle of an important explanation.
If you are behind, reduce secondary features or endpoint details. Complete one main flow and its most important failure case before improving diagram appearance or adding more components.
Suppose ten minutes remain and you have not explained the architecture. One possible plan is:
Use two minutes to explain the main flow, five minutes for its important technical problem, and three minutes for remaining recovery, tests, and summary.
Tell the interviewer what you are shortening. Do not speak much faster or omit an unresolved correctness problem just to deliver a release checklist.
8. Practice with two time limits
Try the same question with 45 minutes and then 30 minutes. Keep the requirements, main flow, important mechanism, and recovery explanation in both attempts.
Compare where you repeated information or described details that did not affect a decision. Shorten those parts first.
Use the seven signals introduced earlier in this chapter to identify unclear explanations. If you cannot explain a mechanism at either time limit, study it before repeating the exercise.
Practice questions
1. A 45-minute meeting includes five minutes of introductions and five minutes for your questions. How much design time remains?
<details> <summary>Show answer</summary>35 minutes. The sample allocation is 4 minutes for requirements, 6 for API and data, 8 for architecture, 12 for detail, and 5 for the closing review.
</details>2. Should you postpone a failure question until the final step?
<details> <summary>Show answer</summary>No. Address it when it matters. It may change the API, data model, or architecture. Adjust the remaining plan instead of following the timing rigidly.
</details>3. Why save a pending like and its send record together?
<details> <summary>Show answer</summary>If the app stops between separate writes, it could retain the displayed change but lose the work needed to send it. A transaction, or an equivalent recovery design, keeps the related state consistent.
</details>Takeaway
Use the five steps to cover the important parts of the answer. Adapt the timing, explain failure throughout, and reduce secondary detail when necessary.
Reading Progress
0%
On This Page
- Count the time available for design
- Step 1: agree on requirements
- Step 2: define the API and data model
- Step 3: explain the client architecture
- Step 4: examine the important mechanism
- Step 5: complete recovery, testing, and release details
- Adjust when time becomes short
- Practice with two time limits
Practice questions
Takeaway