Mock Interview & Portfolio Narrative

"Walk me through an AI project you've built. What problem did it solve, how did you design it, and what would you change?"

The single most common opener in every AI/Applied Engineer phone screen. This session is entirely about answering it — practice out loud, not just in your head, until it comes out in 60-90 seconds unprompted.

Miss one and the follow-up lands exactly where you went silent.

1. Problem — a named constraint, not just what the output does
2. Architecture — deliberate layer design with named roles
3. Trade-offs — alternatives compared, the decision quantified
4. Reliability — a named mechanism for what happens when something breaks
5. Security — a named threat and a named control

"I built a Researcher Agent — a system that answers multi-step research questions using a 5-layer architecture: gateway, orchestrator, LLM provider, cache, and observability. The constraint I was solving for was cost-and-reliability: a single LLM call is cheap but unreliable for complex questions, so I implemented a ReAct loop capped at 5 steps with retry on every call. I benchmarked two model options and chose the mid-tier one — 40% quality improvement justified a 3x cost increase for this use case. My eval harness gives me a 7/10 accuracy score across 3 test inputs; the known failure mode is ambiguous temporal queries — 'what happened recently' with no date anchor. The main thing I'd change is adding streaming output from the start — the synchronous loop takes 5-8 seconds and that's a UX problem. On security: my STRIDE model flagged prompt injection as the top risk, so I implemented query length and pattern validation in the gateway."

Every sentence names a number, a layer, or a mechanism — nothing here is a vague gesture at "good engineering practice."

• "Walk me through a project you built" is in nearly every AI/Applied Engineer phone screen — usually the opening question
• "What would you change?" tests reflective honesty, not just competence
• "How do you know it works?" — evidence (a score + a failure mode) beats a feeling every time
• The same 5-beat structure works on the job too — your team lead's first-week "tell me about the AI systems you've worked on" is the identical question

• A strong project undersold in an interview because the story wasn't rehearsed → practice the 5 beats out loud, not just in your head
• "I chose X because it seemed best" as a design justification → that's a default, not a trade-off; needs a comparison and a number
• A README that only explains how to run the code → missing the problem statement, evals, and known limitations a recruiter actually needs
• Hiding a project's weaknesses instead of naming them → a Known Limitations section is a credibility signal, not an admission of failure

A portfolio narrative is the structured story behind a project — the problem it solved, how you designed it, what trade-offs you made, and what evidence you have that it works. A project summary lists facts; a narrative explains why each decision was made.

This is the difference between "I built a Researcher Agent with 5 layers" and being able to defend why each layer exists and what you'd change about it.

A toy demo has one or two things going for it. A portfolio-worthy project has all four at once: a named constraint, a deliberate layered design, a measured eval score with a named failure mode, and at least one named threat with a named control.

This is the single biggest anchor of this whole course: the bar was never complexity — it was always explainability and evidence.

The structured story behind a project — problem, design, trade-offs, and evidence it works — distinct from a project summary, which lists facts without reasoning.

Like the difference between a résumé bullet and the story you'd actually tell at dinner about why you built the thing that way.

The template for "walk me through your project" in 60-90 seconds: Problem, Architecture, Trade-offs, Reliability, Security, in that order. Missing any beat signals a gap.

Like a five-course tasting menu — skip a course and the guest notices exactly where the meal went quiet.

The specific technical or business limitation that shaped your design choices. "It needs to answer questions" is not a constraint; "multi-step reasoning is expensive and unreliable without retry logic" is.

Like the difference between "build me a bridge" and "build me a bridge that survives a 7.0 earthquake" — only the second one explains your design choices.

A quality measurement with both a number (7/10) and the specific condition that causes failures — not "it works most of the time."

Like a nutrition label, not a marketing slogan — reproducible and specific, not a vibe.

A decision between alternatives with a documented reason: "I chose X over Y because Z," where Z is a specific constraint or outcome — not just a default.

"I picked the cheaper flight because the time difference didn't matter" is a trade-off. "I picked it because it seemed fine" is a shrug wearing a trade-off's clothes.

Naming what you'd change if you rebuilt the project, and why — a senior engineering signal that shows you've thought past MVP.

"I'd add streaming because the synchronous loop adds 5-8 seconds of UX wait time" names a cause and a consequence — miles more credible than a vague "I'd clean it up."

A README section naming 1-2 things your system doesn't handle well. Counterintuitively strengthens a portfolio — it proves you measured your own work instead of pretending everything works.

Like a restaurant menu noting an allergen — trust goes up, not down, because it shows the chef actually checked.

A structured "tell me about yourself": (1) where you came from, one sentence, (2) the specific reason you transitioned — a diagnosis, not generic passion, (3) what you can do now — a named capability.

The difference between "I love AI" and "I saw LLMs shipped without eval harnesses, and now I can design, build, and defend a production AI agent" — the second one is a hire-able claim.

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

1. An answer covers architecture, model choice, and retry logic, but nothing about what problem it solves or what threats it addresses. Which two beats are missing?

• Problem and Security
• Trade-offs and Reliability

2. An eval harness scores 6/10 with failure mode "ambiguous temporal queries." What's the strongest response to "how do you know it works?"

• "I manually tested about 20 questions and it seemed accurate"
• "My eval harness scored 6/10 across 3 input types; the failure mode is ambiguous temporal queries with no date anchor"

Self-assessment, not graded.

3. "Why did you choose that model over the alternatives?" Which answer signals the strongest engineering judgment?

• "It's the most capable model available and I wanted the best results"
• "I benchmarked two models on 10 test queries — 40% better quality for a 3x cost increase, acceptable for this use case"

4. What's the difference between a toy demo and a portfolio-worthy project?

• Portfolio-worthy uses more advanced techniques and a larger model
• Portfolio-worthy has a named constraint, deliberate layer design, measured eval results, and a named failure mode

Self-assessment, not graded.

5. A student answers "what would you change?" with "I'd add streaming — the synchronous loop takes 5-8 seconds and that's a UX problem." What signal does this send?

• The student hasn't completed the project properly
• The student has thought past MVP, understands the UX implications of their choices, and reflects honestly — a senior signal

6. A recruiter asks "where does the caching layer live in your agent?" What's the best answer?

• "It's in the middle somewhere, between the LLM and the output"
• "Layer 4, the storage module — it sits between the orchestrator and the LLM provider; the orchestrator checks it before making a new call"

Self-assessment, not graded.

7. What's the primary purpose of a "Known Limitations" section in a portfolio README?

• To warn recruiters the project isn't production-ready
• To demonstrate intellectual honesty — you measured your own work and scoped its gaps deliberately

8. Interview-style: in 2-3 sentences, give your own 3-part "tell me about yourself" answer — where you came from, why AI specifically, and what you can do now.

≈1 hr · this is what you actually send with a job application

Goal: make your project understandable to a recruiter, hiring manager, and technical interviewer within the first screen of content.

Extend your project's README with four sections: Problem Statement (3 sentences: what problem, what constraint made it interesting, who's the user), Design (each layer named with its one job), Evals (a real score, a table of test inputs, a named failure mode), and Known Limitations (1-2 things your system doesn't handle well, briefly explained).

Write down: your problem statement in 3 sentences, and your one named known limitation with a one-sentence explanation of why it happens.

≈45 min · your primary send-with-application deliverable, alongside the README

Goal: prove the system runs and that you can narrate your own architecture live, not just on paper.

Screen-record yourself running your project's main command, talking through the output as it appears (naming which layer produced it), and briefly showing your eval results. Target 60-90 seconds — practice the narration once before recording so it doesn't read from a script.

Write down: the exact command you ran on camera, and the one layer name you made sure to say out loud while narrating.