Before you draw anything: what constraints would change the design?

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 join a three-person team building an analytics dashboard for an internal sales team. The tech lead shows you a diagram with a stream processor, a columnar warehouse and a caching layer, and asks you to "review the architecture". Nobody has told you how many users, how much data or how soon.

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

Proposed architecture — internal sales dashboard (illustrative)

  [CRM] --> [event collector] --> [stream processor] --> [columnar warehouse]
                                                              |
                                                     [cache layer] --> [dashboard]

  Team: 3 engineers (Postgres, Python; nobody has operated a stream processor)
  Users: "the sales team"          (count not stated)
  Data: "all the sales data"       (volume, growth and freshness not stated)
  Deadline: "soon"
  Legal: not discussed

What it is really testing

Whether the candidate asks for constraints before evaluating structure. An architecture without time, users, data volume, known technology, budget and legal constraints cannot be reviewed; it can only be admired.

Where the move is taught

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