← All items

Design Exercises

Open-ended design challenges — smart parking, AI hospital, self-improving web agent. Practice surfaces for translating intent into agent architecture.

5 items 2 Foundational 1 Intermediate 2 Advanced

Design exercises are how you stop being a passive reader and start being someone who can architect an agent under constraints. Each writeup poses a real-feeling scenario — a smart parking system that needs to become proactive, a hospital that wants AI-assisted diagnosis, a web agent that needs to keep getting better — and walks through the design decisions you'd defend on a whiteboard.

The writeups don't give you a single right answer. They give you the constraints, the decisions you'd need to make, the trade-offs you'd discuss, and a rubric for whether your answer is plausible. Use them as practice problems.

Key concepts

  • Design exercises are about decisions, not implementations — the value is in the trade-offs, not the diagram
  • Constraints matter more than capability — what you can't change shapes what you can do
  • Safety-critical exercises (AI hospital) demand a different design vocabulary than convenience exercises (smart parking)
  • Evaluation criteria should be part of the design, not bolted on at the end
  • An exercise without an interviewer is still useful — defend your design out loud, then re-read your own argument

Reference template 

// Working through an exercise
## Scenario    — restate it in your own words; confirm scope
## Constraints — what's fixed, what's variable, what's wishful
## Approach    — the high-level shape; what kind of agent system
## Design decisions — the 3–5 choices that drive the architecture
## Trade-offs to discuss — what you'd defend in an interview
## Evaluation criteria — how you'd know the design is working
## Related exercises

Adapt to your problem; the structure is the load-bearing part.

Common pitfalls

  • Jumping to the architecture before clarifying the scope — half the points are in the requirements clarification
  • Ignoring the failure modes — every interviewer asks 'what could go wrong?'
  • Over-engineering for hypothetical scale — pick the boring solution unless the problem demands otherwise
  • Forgetting the eval — 'how would you measure success' is a guaranteed follow-up

Related topics

Fundamentals Patterns Case Studies

Items (5)

Search ESC

Keyboard shortcuts

Shortcuts are disabled while typing in inputs.