0% completed
Mid, Senior, and Staff Answers
On This Page
- What changes as responsibility increases?
- One question, three examples
Example A: explain the feature
Example B: explain the mechanism and its cost
Example C: consider the wider change
- Explain one late-result problem
- Choose detail based on the main risk
- Explain adoption and recovery when they matter
- Respond to questions with reasons
- Find the kind of improvement you need
Practice questions
Takeaway
Two people can draw similar components but explain the design at very different levels of detail. One may explain how a feature works. Another may also explain difficult failure cases and the costs of the solution. A third may examine how a change affects other parts of the product and the teams maintaining it.
This lesson uses mid, senior, and staff to discuss these differences. They are practice categories, not exact rules for every employer. Companies define roles in their own context. For example, GitLab publishes a development career framework for its organization. GitLab career framework
Correctness, security, and suitable failure handling matter at every level. A mid-level answer should not assume that requests always succeed. A staff-level answer still needs to explain how the technical solution works.
1. What changes as responsibility increases?
| Practice focus | Main question | Useful evidence |
|---|---|---|
| Mid: a defined feature | Can you design the agreed feature correctly? | Clear components, saved state, errors, and tests. |
| Senior: important technical decisions | Can you explain why the design works under difficult conditions? | Alternatives, costs, simultaneous work, and recovery details. |
| Staff: wider effects | Can you choose a useful direction for the surrounding system? | Compatibility, adoption, ownership, and measurable benefits. |
These categories overlap. A mid-level engineer can explain strong trade-offs. A staff engineer may focus on one complex domain rather than many teams. Use the comparison to improve your reasoning, not to limit which ideas you discuss.
2. One question, three examples
The question is:
“Design image loading for a scrolling photo feed. Images should appear quickly, scrolling should remain responsive, and memory use should stay within a reasonable limit.”
Assume the service provides image IDs and URLs for suitable image sizes. Clarify expected device types, display dimensions, and whether offline images are required.
Example A: explain the feature
“Each visible row requests an image for its current item and display size. I will use the app's existing image-loading library. The row shows a temporary placeholder while loading and an error state if loading fails. I will limit the image cache and cancel work the row no longer needs. Before displaying a result, I will check that the row still expects that image. I would test fast scrolling and failed downloads.”
This explains useful behavior. It covers loading, failure, and a common problem: a result arrives after a row has been reused for another item.
It still leaves questions about memory limits, repeated requests, and how the library is configured. Those are useful follow-up topics, not proof that the person cannot answer them.
Example B: explain the mechanism and its cost
“I will decode images near their required display dimensions and limit simultaneous downloads and decoding. The memory cache will have a byte limit because image sizes differ. If two rows request the same image version and size, they can share the download. Canceling one row's request should not stop a download another row still needs. This reduces repeated work but adds coordination and cache-management complexity. I would measure memory use and time to visible images on representative devices.”
Decoding means turning an image file into displayable pixels. Simultaneous work means tasks that overlap in time. The implementation must coordinate shared work so that one caller does not incorrectly cancel another caller's request.
This example provides more technical detail. The speaker should be able to explain how completion, cancellation, and shared state interact.
Example C: consider the wider change
“Before building another image loader, I will check whether the existing library can meet the requirement. If several screens use different loaders, I will measure whether that causes inconsistent behavior or unnecessary resource use. Shared configuration may solve the problem. If a common implementation is justified, I will define its interface, assign maintenance responsibility, and test it on one screen first. I will expand its use only after checking the results.”
This example adds a decision about whether new infrastructure is worth building. It does not replace the need to understand image loading.
A staff-oriented answer does not need to propose more components. Sometimes the useful decision is to reuse an existing tool or avoid an expensive migration.
3. Explain one late-result problem
Suppose a row first displays photo A. Its image download starts. The user scrolls, and the same row is reused for photo B. The result for A then arrives.
If the callback simply sets the row's image, the user sees the wrong photo.
Associate each request with the item and image version or size it expects. Before displaying the result, compare it with the row's current request. Ignore it if they no longer match.
Cancellation reduces unnecessary work, but it is not the correctness check. Completion may already be in progress when cancellation occurs. Shared work may also continue because another caller needs it.
This short sequence shows more understanding than saying only “we support cancellation.”
4. Choose detail based on the main risk
| Concern | What to explain in more detail |
|---|---|
| Wrong images after scrolling | Request identity, row reuse, and late results. |
| Too much memory | Image dimensions, cache limits, active images, and simultaneous decoding. |
| Images appear slowly | Network time, disk access, decoding, and request priority. |
| Different behavior across screens | Shared interfaces, configuration, and maintenance responsibility. |
Be precise about limits. A 40 MB memory-cache limit does not mean the whole loader uses at most 40 MB. Displayed images, temporary decoding buffers, and other resources may use memory outside that cache.
Also define measurements. A cache-hit rate does not by itself tell you how quickly users see images. A disk-cache hit may still need file access and decoding.
Explain one important problem well before adding more topics. Adjust when the interviewer asks for a different area.
5. Explain adoption and recovery when they matter
If you propose a loader shared by several screens, explain the change plan:
- Measure the current problem, such as blank images or memory-related failures.
- Define how callers request, cancel, and receive images.
- Assign responsibility for maintenance and investigating failures.
- Test the new implementation on one screen or a limited group of users.
- Compare the results before expanding its use.
Check that old and new implementations do not both download and retain the same images during the transition.
Agree on conditions that stop expansion. For example, improved average loading time is not enough if failures increase on lower-memory devices. A fallback is useful only if it remains compatible and available.
Keep this discussion proportional to the question. A small isolated feature may not need a multi-team migration plan.
6. Respond to questions with reasons
Suppose the interviewer asks, “Why store images on disk?”
A useful answer is:
“Disk storage can reduce downloads when users return to the same images. It uses storage and needs cleanup and freshness rules. If reuse is low or the content is sensitive, I would reconsider the policy. Images explicitly saved for offline use need a separate retention rule so normal cache cleanup does not remove them.”
You can change your decision when a better alternative or new requirement appears. State what changes and why.
7. Find the kind of improvement you need
- If you understand the mechanism but cannot explain it clearly, practice the sequence aloud.
- If you cannot explain what happens inside a component, study or test that behavior.
- If you list options without choosing, compare them against a specific requirement.
- If you propose a broad change without an adoption plan, explain one realistic migration and failure case.
Do not infer a job level from one phrase or one missing detail. Ask which responsibilities apply to your target role and use practice to develop relevant evidence.
Practice questions
1. Does saying “I will cache images” identify a candidate's level?
<details> <summary>Show answer</summary>No. It names a technique. Ask about image identity, memory limits, cleanup, failure behavior, and the reason for the choice.
</details>2. Why check the current row request after canceling an old request?
<details> <summary>Show answer</summary>The old result may still arrive. Checking identity prevents it from replacing the image for the row's new item.
</details>3. Must a staff-oriented answer propose a new shared component?
<details> <summary>Show answer</summary>No. First establish whether there is a problem that shared code would solve. Configuration or an existing library may provide the required benefit at lower cost.
</details>Takeaway
Broader responsibility means explaining more of the consequences of a design, not using more complex language. Start with correct feature behavior, explain difficult mechanisms, and discuss wider changes when the problem requires them.
Reading Progress
0%
On This Page
- What changes as responsibility increases?
- One question, three examples
Example A: explain the feature
Example B: explain the mechanism and its cost
Example C: consider the wider change
- Explain one late-result problem
- Choose detail based on the main risk
- Explain adoption and recovery when they matter
- Respond to questions with reasons
- Find the kind of improvement you need
Practice questions
Takeaway