Skip to main content

Quiz: Architecture & Structure

Covers vertical slices, the shared kernel, and contract-first development. Reference: Architecture · ADR: Vertical Slice Architecture.

Question 1: Why vertical slices​

Senior

Your app organises code by business domain (features/transfers/) instead of by file type (components/, hooks/). What concrete problem does that solve at scale?
Show answer

In file-type organisation, understanding or changing one feature means touching four separate trees: components/, hooks/, types/, tests/. Two engineers on unrelated features collide in the same folders and produce merge conflicts on files that have nothing to do with each other.

Vertical slices co-locate everything one feature owns. The blast radius of a change is one folder. You can read a feature top to bottom without jumping the tree, and you can delete a feature by deleting its directory. It optimises for the thing teams actually do (change one capability at a time) instead of for an alphabetised filing cabinet.

Question 2: The shared kernel rule​

Senior

What's your rule for deciding whether something belongs in shared/ versus inside a feature folder?
Show answer

Something belongs in shared/ only if it's used by three or more slices, or it's a genuine system-wide concern (logging, the HTTP/GraphQL client, error boundaries, formatters). One feature needing a helper? That helper lives in that feature.

The failure mode without the rule: shared/ becomes a junk drawer. Everything drifts there "just in case," coupling unrelated features through a shared utilities blob, which is the file-type problem wearing a different hat.

Question 3: Contract-first​

Staff

You define the GraphQL schema before writing components, then generate types and hooks from it. What does that ordering buy you, and what breaks if you skip it?
Show answer

The schema is the single source of truth. Types and React Query hooks are generated from it, so the client and the contract cannot silently disagree: if the schema changes, the generated types change, and every consumer that's now wrong fails to compile. You find the break at build time, not in production.

Skip it and you hand-write types that mirror the API by memory. They drift the moment the backend changes a field, and nothing tells you, until a undefined shows up in the UI. Contract-first turns "hope the types match" into "the compiler proves the types match," and makes cross-cutting fixes (like typing every hook's error) one config change instead of a manual sweep.

Engineering Stories

Interview Prep

Related decisions