0% completed
Capstone: Grading Three Answers
On This Page
- Use evidence when reviewing
- The shared question
The API rules for this exercise
- Answer A
- Answer B
- Answer C
- Review before opening the answers
- Worked review
- Follow the retry sequence
- Improve one answer
Practice questions
Takeaway
This lesson asks you to review three answers to the same mobile design question. Your task is to identify what each answer explains, find incorrect claims, and choose a useful follow-up question.
Do not assign a job level from a short answer. A missing explanation does not prove that the person cannot explain the topic. However, an explicit claim that conflicts with the requirements is a technical problem that needs correction.
1. Use evidence when reviewing
Use the seven signals from this chapter:
| Signal | What to check |
|---|---|
| Scoping | Does the answer respect the agreed features and exclusions? |
| Architectural clarity | Can you follow a read or write through the system? |
| Modular thinking | Are responsibilities and state ownership clear? |
| Trade-off reasoning | Does the answer explain a choice and its cost? |
| Platform depth | Does it explain relevant device behavior and limits? |
| Failure awareness | Does it explain saved state, visible outcomes, and recovery? |
| Communication | Are assumptions and decisions understandable? |
Mark each signal clear, partial, or missing, and write your reason. Also record contradictions separately. A contradiction is a statement that conflicts with a requirement, the supplied API, or another part of the answer.
For example, “I will keep pending work in memory” contradicts a requirement to preserve that work after the app process ends.
2. The shared question
“Design a mobile photo feed. Users can read posts and change their like state. The backend already exists. Saved post information must remain readable offline after an app restart. A like change made offline must also survive a restart and be sent later.”
All three answers receive the same clarifications:
- Uploads, comments, ranking, and changes from other devices are excluded.
- Images are available offline only if they remain in the cache. Complete offline image downloads are not required.
- A new installation with no saved posts may show an empty offline state.
- Further like changes to a post may be disabled while an earlier change is unresolved.
- The app may update the heart before confirmation, but it must show that the change is pending.
- A permanent rejection must be explained and the display corrected.
The excerpts summarize selected parts of a practice answer. They are not full interview transcripts.
The API rules for this exercise
| Request | Server behavior |
|---|---|
| Read a feed page | Returns post IDs, image URLs, captions, confirmed like state, count, and a next-page cursor. Pages may contain repeated posts, so the app combines them by ID. |
| Toggle a like | Accepts a post ID and operation ID. Each new accepted operation changes the post from liked to not liked, or from not liked to liked, once. |
| Repeat an operation | The same operation ID and request data return the recorded result without changing the state again. A new ID is a new operation. |
| Permanent rejection | Explicitly means the change was not applied. A timeout alone does not tell the app whether it was applied. |
A toggle reverses the current state. The server remembers operation IDs for the retry period used in this exercise. This is an exercise assumption, not a guarantee about all services.
Review the answers against this existing API. You may suggest another API afterward, but do not silently replace these rules while grading.
3. Answer A
“I will include reading posts and changing likes, and leave out uploads and comments. The screen shows one state containing posts, loading status, and errors. A repository requests pages and combines repeated posts by ID. Refreshing keeps the current list visible.
To simplify the first version, I will keep posts and pending likes in memory. After a restart, the app downloads the feed again. Images use an existing loader with limited caching and suitable image sizes.
A like tap creates one operation ID and shows a pending heart. Further changes to that post remain disabled while waiting. If the reply is lost, I retry with the same ID. A permanent rejection restores the confirmed heart and shows an error.
I would test a failed first load, a failed refresh with saved content, and a lost like response.”
4. Answer B
“I will create shared feed, image, network, and synchronization modules. The screen reads from a local database. A shared queue handles all writes in the app.
A like tap saves the pending heart and send record in one database transaction. A worker sends it and waits longer between retries. Every retry uses a new operation ID to prevent duplicate processing. It retries every error. If it reaches the retry limit, I show the operation as rejected.
Disk caching makes every feed image available offline. I will load ten extra pages in advance to make scrolling fast.
I will release the feature to a small group first and watch crashes and feed loading time. One team will maintain the shared modules.”
5. Answer C
“I will save post information and pending likes in persistent storage. Images are available only when cached. A new installation can show that no saved posts are available offline.
The screen reads saved posts together with pending changes. The repository combines repeated posts by ID. Confirmed server state remains separate from the pending heart, so a refresh does not remove the user's unfinished change. The count stays at its last confirmed value until the write result arrives.
A tap creates one operation ID. I save the pending change and send record together before showing that the action is recorded. If storage fails, I keep the confirmed display and explain that the action could not be saved. Further changes to that post remain disabled while waiting.
A sender reads saved pending work. A timeout keeps the result unknown. Retries reuse the same ID. A matching success saves the confirmed result and removes that pending record in one transaction. A permanent rejection removes the pending change and explains why. A response must not clear a different operation.
On restart, the app restores unresolved work. This design adds storage and recovery logic, but those are needed for the offline requirements. I would test app termination, lost replies, and refresh during a pending like. I would also check loading time, pending-action age, and failures on different device types.”
6. Review before opening the answers
Copy this table and record a mark with a reason in each cell:
| Signal | A | B | C |
|---|---|---|---|
| Scoping | |||
| Architectural clarity | |||
| Modular thinking | |||
| Trade-off reasoning | |||
| Platform depth | |||
| Failure awareness | |||
| Communication |
For each answer, also write one strength, one incorrect or missing detail, and one follow-up question.
Do not assume that more modules or a release plan make an answer correct. Check the behavior described by the answer.
7. Worked review
<details> <summary>Review Answer A</summary>What works: the answer explains the feature boundary and read flow. It keeps current content visible during refresh, combines repeated posts by ID, and correctly reuses the operation ID after a lost response.
What is wrong: memory-only storage fails the restart requirements. After the process ends, both saved posts and pending operation IDs disappear. Downloading again does not work while offline.
Ask next: “The app stops while offline after the user taps Like. What saved data lets it restore the posts and pending action?”
Improve it: persist the required records and define what happens if saving fails. Keep the correct retry-ID reasoning. Choosing simplicity does not justify removing required behavior without agreement.
</details> <details> <summary>Review Answer B</summary>What works: the answer includes persistent storage, a transaction for related local changes, increasing delays between retries, and a limited initial release.
What is wrong: a new operation ID causes a new toggle under this API. If the first request succeeded but its reply was lost, the retry changes the state again. The claimed duplicate prevention is incorrect.
Retrying every error also ignores permanent rejection. Reaching a retry limit does not establish the server's outcome. Disk caching cannot guarantee every image is available; an image may never have been downloaded or may have been removed.
What needs justification: ten-page preloading has no memory or network budget. One queue policy for all app writes ignores differences in expiry, ordering, and user intent.
Ask next: “The first toggle succeeds, but its reply is lost. What does your retry with a new ID do?”
Improve it: fix operation identity and outcome handling first. Then limit preloading and explain which queue behavior can safely be shared. The release plan does not correct these technical problems.
</details> <details> <summary>Review Answer C</summary>What works: the answer connects persistent storage to the requirements. It separates confirmed data from pending intent, handles storage failure, reuses operation IDs, and describes matching responses and restart recovery.
What remains unclear: it does not explain the exact background-execution mechanism or what happens if two senders select the same pending record. It also needs more detail on authentication recovery and work older than the assumed retry period.
Ask next: “A foreground sender and a background worker both select the same pending record. How do you prevent conflicting updates?”
Possible next detail: use one coordinated sender or a safe database-based work-claiming mechanism. Match completion to the operation ID, and explain recovery if the process ends while work is claimed. Server deduplication provides another safeguard, but the client must still update local state correctly.
This answer gives the strongest evidence for the stated problem. It is not a complete production design or proof of a hiring level.
</details> <details> <summary>Compare example marks</summary>| Signal | A | B | C |
|---|---|---|---|
| Scoping | Clear | Partial: unnecessarily includes every app write | Clear |
| Architectural clarity | Partial: required durable state is absent | Partial: write flow has incorrect recovery | Clear |
| Modular thinking | Partial: limited interface detail | Partial: shared policies are not justified | Clear: data and sender responsibilities are described |
| Trade-off reasoning | Partial: simplicity removes required behavior | Partial: benefits are named without costs | Clear: storage complexity is justified |
| Platform depth | Partial: some image handling | Missing: execution limits are not explained | Partial: device testing is mentioned, scheduling needs detail |
| Failure awareness | Partial: correct retry identity, incorrect restart behavior | Partial: useful durability ideas, incorrect outcome rules | Clear for several important failures |
| Communication | Clear, including the incorrect choice | Partial: important claims lack support | Clear |
Record A's restart contradiction and B's retry and offline-image contradictions separately. A “partial” mark must not hide an incorrect claim. Other marks can be reasonable if you support them with evidence.
</details>8. Follow the retry sequence
Start with a post that is not liked. Operation X changes it to liked, but the reply is lost.
Repeating X returns its recorded result without another change. Sending a new operation Y performs another toggle and changes it back to not liked.
This failure can occur even though both server requests succeeded. The client treated a new operation as if it were a retry of the old one.
This example uses the supplied toggle API. An API that sets an explicit desired state has different behavior. Always inspect the actual rules rather than assuming all write endpoints work alike.
9. Improve one answer
Choose A or B and rewrite its weakest paragraph. Preserve the useful reasoning, correct the requirement or API violation, and name the cost of the repair.
For A, persistent records add storage management and recovery work. For B, correct retries require stable identity, different handling for rejection and uncertainty, and careful completion updates.
Then explain the revised flow aloud. Test it by stopping the app or losing a response at an inconvenient point. Use the five-step method to check whether any important part remains unexplained.
Practice questions
1. Why is Answer A's memory-only choice a contradiction?
<details> <summary>Show answer</summary>The requirements explicitly say that post information and pending likes must remain after a restart while offline. Process memory cannot provide that behavior.
</details>2. Does reaching a retry limit prove rejection?
<details> <summary>Show answer</summary>No. It proves only that the app stopped automatic attempts. A lost reply can leave a successful server operation unknown to the app. Preserve the unresolved state and use the available recovery path.
</details>3. Should Answer C receive full marks for platform knowledge because other parts are strong?
<details> <summary>Show answer</summary>No. Review the evidence for each area separately. Ask about background execution, resource limits, and recovery where the excerpt does not provide enough detail.
</details>Takeaway
Review an answer against the actual requirements and API. Separate useful reasoning, missing detail, and incorrect claims. Use follow-up questions to investigate the design rather than assign a level from its wording.
Reading Progress
0%
On This Page
- Use evidence when reviewing
- The shared question
The API rules for this exercise
- Answer A
- Answer B
- Answer C
- Review before opening the answers
- Worked review
- Follow the retry sequence
- Improve one answer
Practice questions
Takeaway