Interview Learning Roadmap: Full Practice and Checklists

🎯 Full Case-Study Practice

These should be solved without looking at the earlier modules.

Case 1 — Customer Support Agent

A large e-commerce company wants an AI customer-support system that can answer questions, check orders and issue refunds.

Cover:

Discovery
→ Requirements
→ Architecture
→ RAG
→ Tools
→ Policy
→ Scale
→ Cost/Latency
→ Evaluation

---

Case 2 — Enterprise Knowledge Assistant

A multinational company wants a ChatGPT-style assistant over millions of internal documents, but employees have different access permissions.

Focus on:

RAG
Permission-aware retrieval
Scale
Latency
Security
Evaluation

---

Case 3 — Logistics Exception Agent

A logistics company wants AI to detect shipment exceptions and automatically resolve routine cases.

Focus on:

Events
Agents
Tools
Policy
HITL
Idempotency
Reliability
Audit

---

Case 4 — SRE Incident Agent

An enterprise wants an AI agent that investigates production incidents and can execute remediation actions.

Focus on:

Tools
Observability
Agent reasoning
Permissions
Policy
HITL
Kill switch
Audit

---

Case 5 — Deep Research Agent

Build an enterprise research agent that searches multiple sources and may run for 10–20 minutes.

Focus on:

Async execution
Queue
Checkpoint
Agent bounds
Cost
Long-running state
Evaluation

---

Case 6 — Multi-Tenant AI Platform

Build a shared AI platform supporting 100 enterprise customers and multiple LLM providers.

Focus on:

API Gateway
Model Gateway
Multi-tenancy
Quotas
Fairness
Model routing
Cost attribution
Observability

---

Phase 1 — Problem Decomposition

Module 1 — Discovery
Module 2 — Functional Requirements
Module 3 — Non-Functional Requirements

Outcome: Understand before designing.

---

Phase 2 — Architecture

Module 4 — Core Components
Module 5 — RAG
Module 6 — Agents
Module 7 — Tools
Module 8 — Policy / HITL

Outcome: Build the right system.

---

Phase 3 — Production Scale

Module 9  — Scaling
Module 10 — Latency
Module 11 — Cost
Module 12 — Reliability

Outcome: Turn the POC into production.

---

Phase 4 — Production Quality

Module 13 — Evaluation
Module 14 — Release
Module 15 — Observability
Module 16 — Security

Outcome: Safely operate the system.

---

Phase 5 — Interview Mastery

Module 17 — Trade-Offs
Module 18 — Full Case Studies

At this stage:

Stop adding terminology. Start solving cases.

---

The objective is not to memorise definitions.

Train yourself to hear a customer/interviewer statement and automatically recognise the architecture concern.

---

                 CUSTOMER
                    ↓
            WHY ARE WE BUILDING?
                    ↓
                DISCOVERY
                    ↓
              REQUIREMENTS
                    ↓
               HAPPY PATH
                    ↓
         ┌──────────┼──────────┐
         ↓          ↓          ↓
        DATA        AI       ACTION
        RAG       Agents      Tools
                              ↓
                       Policy / Human
                    ↓
              PRESSURE TEST
                    ↓
         ┌──────────┼──────────┐
         ↓          ↓          ↓
       Scale      Latency     Cost
         └──────────┼──────────┘
                    ↓
               FAILURES
                    ↓
              EVALUATION
                    ↓
                RELEASE
                    ↓
          OBSERVE + OPERATE
                    ↓
               TRADE-OFFS

---

Before finishing any architecture, mentally ask:

□ Did I understand the BUSINESS problem?

□ Did I understand the CURRENT workflow?

□ Did I define FUNCTIONAL requirements?

□ Did I define measurable NFRs?

□ Is every major architecture box JUSTIFIED?

□ Where does DATA come from?

□ Does AI ANSWER, RECOMMEND or ACT?

□ What requires HUMAN approval?

□ Does it SCALE?

□ What makes it SLOW?

□ What makes it EXPENSIVE?

□ What happens when dependencies FAIL?

□ How is it SECURED?

□ How do I measure AI QUALITY?

□ How do I RELEASE changes safely?

□ How do I OBSERVE it in production?

□ What are my major TRADE-OFFS?

---

Do not memorise architectures.

Memorise:

Customer says X
      ↓
Requirement Y
      ↓
Problem / Constraint Z
      ↓
Component / Pattern A
      ↓
Trade-off B

Example:

"Refunds above $500 are risky."
              ↓
High-risk actions need approval
              ↓
LLM cannot be final authority
              ↓
Policy Engine + HITL
              ↓
Safer execution
but additional latency

Another example:

"We expect 100K users."
          ↓
High concurrency
          ↓
Finite model capacity
          ↓
Rate Limit + Queue
+ Horizontal Scaling
          ↓
Better resilience
but more infrastructure

Interview rule: Don't name a component until you can explain which requirement caused you to introduce it.

---

Start from the customer problem, turn discovery into measurable requirements, build the simplest happy-path architecture, and then pressure-test it across scale, latency, cost, reliability, security, AI quality and operations—adding components only when a requirement justifies them.

---

Sources (checked 27 Sep 2026)

• Google SRE Book - Service Level Objectives — SLI, SLO and SLA definitions
• Google SRE Workbook - Canarying Releases — canary as a partial, time-limited rollout that is evaluated
• AWS Builders' Library - Timeouts, retries and backoff with jitter — retries can amplify an outage; backoff and jitter
• Azure Architecture Center - Circuit Breaker pattern — stop calling a failing dependency for a while
• Amazon SQS Developer Guide - Dead-letter queues — retry, then move to a DLQ
• Stripe API reference - Idempotent requests — idempotency keys prevent a double refund on retry
• Temporal blog - Idempotency and durable execution — at-least-once delivery; checkpoints don't stop duplicate side effects
• OWASP GenAI LLM08:2025 Vector and Embedding Weaknesses — permission-aware retrieval
• OWASP GenAI LLM06:2025 Excessive Agency — least privilege and controlled tools for agents