Here is a candidate's decomposition of a chat app. React to it.

Answer it out loud before you open anything. The value of the flags below is in comparing them to what you actually said — including whether you asked who uses it before naming what you would build it with.

The situation behind the question

You are on an interview panel. A previous interviewer asked the candidate to decompose "build a chat app" and pinned the result to the shared doc. You have ten minutes to assess it and decide what to ask next.

React to this

Say what you would question, what you would keep, and what you would need to know first.

The decomposition, the proposal, or the transcript as it stands

Candidate's decomposition — "Build a chat app" (illustrative):

  Build a chat app
  ├── Frontend
  │   ├── React app
  │   ├── Chat window component
  │   └── Login page
  ├── Backend
  │   ├── REST API
  │   ├── WebSocket server
  │   └── Auth service
  ├── Database
  │   ├── Users table
  │   └── Messages table
  └── DevOps
      ├── Docker
      ├── CI pipeline
      └── Kubernetes

What it is really testing

Whether the candidate can tell a decomposition of the problem from a decomposition of the technology, and can name what makes a subproblem good: independently understandable, testable, with a clear input and output.

Where the move is taught

Problem Decomposition lessons →Stuck because X → do Y →Where to start →Practice challenges →