Interview Signals and Eight Common Mistakes

A good design answer makes your reasoning clear. The listener should understand what you are building, why its parts are needed, and how it behaves when something fails.

In this course, a signal means evidence of a skill in your explanation. For example, explaining how an unsent message survives an app restart shows that you considered failure recovery.

The seven signals below are a practice framework. Companies can use different evaluation methods. There is no universal scoring system or sentence that guarantees a job offer.

1. Seven ways to review your answer

These signals overlap. One well-explained storage decision can provide evidence of several skills. Do not count keywords as points. Check whether the explanation is correct.

2. Explain an important decision in four parts

For a major choice, state the requirement, your choice, its cost, and when you would reconsider it.

For example:

“Users must read saved articles after restarting the app while offline. I will save their text and metadata on the device. Memory alone cannot meet this requirement. Persistent storage requires cleanup rules and a plan for updating saved data. If articles only need to remain during one session, I would reconsider that storage choice.”

Metadata means information about an item, such as its ID and title. Persistent storage means saved data that remains after the app process ends.

3. Eight common mistakes

Mistake 1: Designing before clarifying the question

You hear “design a chat app” and immediately choose classes or a database.

The problem is that text chat, group chat, and video messages need different designs. Offline sending also changes what must be saved.

Improve it: agree on the main behavior first.

“I will cover one-to-one text messages and conversation history. I will leave out group chat and media for now. Must an unsent message remain after the app restarts?”

Ask questions that affect the design. You do not need to ask the interviewer to choose every small detail.

Mistake 2: Drawing component names without explaining behavior

A diagram with Screen, ViewModel, Repository, and Database does not explain how this feature works.

Improve it: follow one action through the components. For a feed refresh, explain who starts the request, who saves the result, and how the screen receives updated items.

A state holder, such as a view model, prepares the information the screen displays and handles user actions. A repository coordinates access to data. These names are useful only when their responsibilities are clear.

Mistake 3: Putting unexplained work in one large component

A component called SyncManager may appear to handle networking, storage, retries, sign-in, and screen updates. If you never explain these responsibilities, the listener cannot evaluate the difficult parts.

Improve it: describe which part saves pending work, which part sends requests, and which rules decide whether to retry. Explain who may change shared state.

You do not need a separate module for every function. A component named Manager is acceptable when its behavior is clear. Changing its name does not solve unclear ownership.

Mistake 4: Naming a technique without explaining why

“I will use caching and pagination” names techniques but does not justify them.

Improve it: connect the technique to a requirement and a cost.

“The list can contain thousands of posts, so I will load it in pages. This reduces the first download, but the app must track the next page and handle page-loading errors.”

A useful trade-off may involve memory, speed, storage, battery, privacy, complexity, or user control. Explain the ones that matter to your choice.

Mistake 5: Promising platform behavior you cannot support

Saying “the background job runs immediately” may make the design depend on behavior the operating system does not guarantee.

Improve it: explain the needed behavior and its limits.

“This upload can wait. I will save its progress and use a suitable background-transfer API. The app must recover if execution is delayed. I would verify the exact rules for the supported operating-system versions.”

Be clear about what you know and what you need to verify. You may discuss an API you have studied without claiming production experience with it.

Mistake 6: Retrying every error in the same way

A failed refresh, an unknown write result, and a confirmed rejection are different situations.

Improve it: state what the app knows before choosing recovery.

A retry limit controls automatic attempts. Reaching that limit does not prove the server rejected the action.

Mistake 7: Never identifying the important technical problem

You answer individual questions but do not explain which part of the design needs the most attention.

Improve it: after the main flow, suggest a relevant detailed discussion.

“The read flow is now clear. Next, I would like to explain how a pending message survives a restart without being sent twice.”

Follow the interviewer if they choose a different topic. Some interviews are intentionally guided. The goal is a useful discussion, not control of the conversation.

Mistake 8: Listing options without choosing one

Repeatedly saying “either option could work” leaves the design incomplete.

Improve it: state an assumption, choose an approach, and explain when it would change.

“Because offline reading is required, I will use persistent local storage. If that requirement is removed, a memory-only design may be simpler.”

Ask for clarification when the answer would significantly change the design. Make ordinary implementation choices yourself and explain them.

4. Correct mistakes clearly

If you notice an incorrect assumption, say what changed and update the affected design.

“I described that timeout as a rejection. The server may have accepted the action before the reply was lost. I will keep the result as unknown and add a status-checking step.”

Then update the saved state, API assumptions, or diagram as needed. A correction is not only a change in wording.

Also examine suggestions before accepting them. If a suggestion conflicts with a requirement, explain the conflict and discuss an alternative.

5. Review with evidence after practice

Mark each signal clear, partial, or missing. Write the sentence or diagram detail that supports the mark.

• Clear: you explained the mechanism and its important limits.
• Partial: you mentioned the topic but left a relevant question unanswered.
• Missing: the answer did not provide evidence about the topic.

Record incorrect claims separately. An incorrect retry rule is not just missing detail.

Choose one explanation to improve and one technical question to verify. If you understand a topic but explained it poorly, practice saying it more clearly. If you do not understand the mechanism, study or test it before practicing again.

Practice questions

1. What makes a diagram with Screen, Repository, and Database useful?

<details> <summary>Show answer</summary>

Explain what each part does, what data moves between them, and how one user action changes the displayed state. Component names alone do not provide this information.

</details>

2. Why should a timeout and a permanent rejection have different states?

<details> <summary>Show answer</summary>

A timeout may leave the outcome unknown. A documented permanent rejection confirms the action was not accepted. They need different messages and recovery steps.

</details>

3. Can better wording fix an incorrect technical assumption?

<details> <summary>Show answer</summary>

No. Verify the behavior and repair the design first. Clear language helps explain correct reasoning; it does not replace it.

</details>

Takeaway

Explain the behavior behind each component and the reason behind each important choice. Use the seven signals to find specific improvements, not to predict a hiring result.