Capstone Build

"Walk me through an AI project you built. What architectural decisions did you make, and how did you make it production-ready?"

The capstone question — where everything from Sessions 1-10 gets tested at once. Cover all five beats in 90 seconds, or the interviewer's next question is the beat you skipped.

Miss one and they probe.

1. Problem — what the system does, who uses it, what success looks like, in one sentence
2. Architecture — the five-layer stack, what each layer does, the tools at each
3. Trade-offs — what you optimized for and what you gave up, not just what you built
4. Reliability — retry/timeout config and the one eval test that caught a real bug
5. Security — your STRIDE top-3 risks and the controls actually implemented in code

"I built a Researcher Agent — a tool-using AI system that takes a research question and returns a sourced summary, for a developer or analyst who needs fast synthesis. I optimized for answer quality over latency: Sonnet-class for synthesis, Haiku for simple lookups, accepting a 3-5 second latency target instead of sub-second. The system has five layers — a FastAPI gateway for input validation, an orchestration layer running the agent loop, a provider module wrapping the Anthropic API, a Redis cache, and a Langfuse observability layer — each one Python file, each only importing from the layer below. Every LLM call is wrapped in retry with exponential backoff, three attempts, and I run an eval harness against 10 test inputs before every merge. My top STRIDE risk was prompt injection at the gateway — I implemented input sanitisation in the Pydantic validator, stripping HTML and capping length at 2,000 characters."

Notice: every beat names something concrete and implemented — never "we plan to add that."

• "Walk me through a project you built" — asked in nearly every applied AI/ML interview, usually first
• "What would you do differently?" — tests whether you understand your own trade-offs, not just recite them
• "How is this tested?" — a runnable system with zero tests reads as a demo, not engineering
• A candidate who can point to one specific implemented security control beats one who lists security buzzwords

• A "working" system that only runs on the original author's machine → missing config module, missing README setup steps
• Swapping LLM providers requires touching a dozen files → provider abstraction never got its own module
• Tests only pass with the real API, never in CI → dependencies were instantiated instead of injected
• A JSON response occasionally breaks a downstream parser → missing output validation at a layer boundary

Sessions 5 through 10 built six separate working artifacts — an agent loop, a multi-agent pattern, guardrails and evals, a model-routing strategy, a production design doc, and a security threat model. Integration means connecting these at their interfaces, without rewriting what already works.

The goal of this session is not new code — it's fixing the seams between code you've already built.

A project becomes portfolio-worthy with five things: a README that runs in under 5 minutes, a runnable system, a design doc that matches the actual code, eval results with at least 3 scored test inputs, and one architectural decision you can explain — trade-off and all — including what you'd change.

This is the single biggest anchor of the whole session: a demo proves it runs once; a portfolio project proves you understand why it runs the way it does.

Connecting separately working components so they function as one system, without rewriting the components — fixing the interface, not the parts.

Like connecting prebuilt plumbing sections — you're fitting joints together, not re-forging the pipes.

The interface between two adjacent layers in the five-layer stack, defined by a Pydantic model or dataclass — never a raw string — so boundary errors are caught immediately.

Like a shipping manifest at a border crossing — a structured form catches a problem at the checkpoint, instead of it surfacing three towns later.

Passing a dependency (like LLMClient) into a function as an argument, rather than creating it inside — so tests can substitute a mock without touching the code under test.

Like a stunt double stepping in for a scene — the script doesn't change, only who's actually performing the role.

A single module wrapping all LLM API calls — orchestration and service code never import the SDK directly, only the provider module does. Swapping providers becomes a one-file change.

Like a universal power adapter — everything downstream keeps working the same way regardless of what's plugged in upstream.

The single file (using pydantic-settings) that reads every environment variable — no other file calls os.environ.get() on secrets.

Like one reception desk that checks every visitor's badge — not a dozen unlocked side doors, each trusting whoever walks through.

A test exercising the boundary between two real layers — e.g. gateway validation followed by the orchestrator with a mock provider — distinct from a unit test, which tests one function in isolation.

A unit test checks one gear turns correctly; an integration test checks two gears actually mesh together.

Mapping each row in your Session 10 STRIDE top-3 risk list to a specific function in a specific layer. A STRIDE entry that can't be assigned to a layer and a function is too vague to implement.

Like turning a New Year's resolution into a calendar appointment — vague intent becomes a real, schedulable action.

A project backed by five items: a README (runs in under 5 min), a runnable system, a filled-in design doc, eval results (3+ scored test inputs), and one architectural decision you can explain with its trade-off and what you'd change.

The difference between a science-fair volcano (impressive once, in the room) and a lab report (reproducible, defensible, and honest about what didn't work).

Self-assessment, not graded. Answer before checking your notes.

1. In software engineering, "integration" means:

• Rewriting individual components so they fit together better
• Connecting separately working components so they function as one system, without rewriting them

2. Which file is the single source of truth for all environment variables (API keys, model names, Redis URL)?

• Any file that needs the variable — just call os.environ.get() directly
• The dedicated config module (e.g. core/config.py)

Self-assessment, not graded.

3. In the five-layer architecture, the agent loop (Session 5's ReAct pattern) belongs in which layer?

• Layer 1 — Gateway
• Layer 2 — Orchestration

4. Why does the LLM provider abstraction live in its own module rather than inside the orchestrator?

• It's a Python convention required by the SDK
• It allows swapping the underlying LLM provider without changing the agent loop or service code

Self-assessment, not graded.

5. A spike of 429 errors from the LLM provider is observed in production. Which layer owns the retry logic?

• Layer 3 — LLM Provider, because the 429 comes from there
• Layer 2 — Orchestration, because it owns retry policy for the agent step

6. When implementing security controls from your STRIDE mitigation table, which artifact determines what to implement first?

• The full six-category STRIDE table, all entries equally prioritised
• The top-3 risk list with one-sentence justifications

Self-assessment, not graded.

7. Which best describes a "portfolio-worthy" AI project for an applied engineer interview?

• A project using at least three AI/ML frameworks integrated with a cloud provider
• A project where the candidate can explain one architectural decision, its trade-off, and what they'd change — backed by a runnable system and eval results

8. Interview-style: in 2-3 sentences, why does "dependencies flow down only" matter for testability, using the LLMClient example?

≈45 min · makes the five-layer architecture real, not just diagrammed

Goal: stand up a runnable project skeleton before writing any real logic.

Create the folder structure: a config module (single source of truth for env vars, using pydantic-settings), a health.py connectivity check, and a minimal pyproject.toml. If you don't have an API key yet, mock the health check's response so you can still verify the skeleton runs.

Write down: your folder structure, and the exact command + expected output that proves the skeleton runs.

≈90 min · minimum viable versions are fine, correctness over completeness

Goal: wire the five layers together into one real, running request.

Implement minimum-viable versions of all five layers: gateway (input validation via a Pydantic model), orchestrator (the agent loop with dependency-injected client), provider (LLM API wrapper), storage (a simple in-memory cache), observability (basic logging). Write at least one integration test for the gateway → orchestrator seam.

Write down: the command that runs your system end to end and its real output, plus confirmation your integration test passes.