Defend every line — your portfolio is the interview

This lesson is about a specific kind of job interview round. At many AI-focused companies, instead of (or on top of) the usual whiteboard puzzle, they ask you to screen-share a project you built and talk through it for 45–60 minutes. "Portfolio" here just means the apps you've shipped — your own code, your deployed site, your design notes. The point of the round is to confirm you genuinely built and understand your work, rather than having copied it from a tutorial. So they ask "why" relentlessly: why this database, why this library, what breaks if the AI goes down, what would you change. The lesson's core advice: don't memorize a script of answers — instead, anticipate every "why this and not that?" question, and make sure you know your real reasons cold.

An everyday analogy: imagine you cooked a dish and a chef tastes it, then quizzes you — "Why butter instead of oil? What if you'd used less salt? Which step went wrong the first time?" If you actually cooked it, every answer comes instantly and you can even discuss the version you'd make next time. If you reheated something store-bought, you stall and hand-wave. The interview works exactly the same way: fluent, specific, tradeoff-aware answers prove authorship; vague ones expose that you don't really own the work.

A key term to define: a counterfactual is a "what if you'd done it differently?" question — e.g. "if you started over, what would you change?" Interviewers love these because they test taste (judgment about good vs. bad design), not just whether you can make something run. Another term: tradeoff means every choice gives up one thing to gain another (e.g. a cache makes reads fast but adds the risk of serving stale data). They want to hear that you weighed those, not that you picked at random.

How to prepare, in plain steps:

• Sketch the whole system from memory in under 90 seconds. If you can't draw the boxes and arrows without notes, you don't know it well enough yet.
• Open a random file and explain it cold — every function, every imported library — with no "I'd have to check."
• For each tool you used, have one sentence on why, plus two alternatives you rejected and the reason ("I considered X and Y; chose this because Z").
• Keep one specific bug story — the real error message and how you tracked it down — and one honest "thing I'd redo."
• Practice a live edit like "add a rate limit to this endpoint" on your own repo until it's muscle memory, and have the right file already open before the call.
• Memorize a 30-second pitch per project and a few hard numbers ("$0.18 per 10-min session" beats "cheap"). Numbers read as proof; adjectives read as fluff.

Why this approach works: you can't predict every question, so scripting answers is brittle — one off-script probe and you freeze. But the set of questions ("why this tool, what breaks, what would you change") is predictable. If you rehearse asking yourself those and you know the honest answers, you can respond to anything in the family. "I don't know" once signals humility; the third time in ten minutes signals you don't actually own the system — so the real goal is fluency, and the win is the interviewer leaving convinced you made this.