Portfolio, resume and interviews

The job post went live on a Monday: Junior AI Engineer, Crumb & Co., Pune. By Thursday there were 212 applications. Priya and Arjun shortlisted 30 by hand (Panel stayed a portfolio project; real candidates got real people), and Arjun took the first pass at their GitHub profiles.

He gave himself two hours. At first he read everything carefully. By the tenth profile he was spending about ninety seconds on each, and he had a sinking feeling. Twenty-two of the thirty had a repository called something like rag-chatbot or langchain-pdf-qa. Most had a README that said “A chatbot that answers questions about PDFs using LangChain and OpenAI” and a single install command. He could not tell them apart.

That evening, Priya asked him for something unrelated: an updated resume and project list, for the paperwork that would make his new title official. He opened his own GitHub and looked at crumb-copilot with fresh eyes. The README read: “AI chatbot for Crumb. Run python app.py.”

He was one of the twenty-two.

Ninety seconds on the other side of the table

The next morning, Arjun told Priya about the twenty-two.

“So what did the eight do differently?” she asked.

He had already looked. Six of the eight were simply different projects, not better ones. But two stood out, and he remembered them without checking. One candidate, Tanvi, had built a RAG assistant over her university’s 300-page examination regulations. Small project. But the first thing in her README was a 40-second video of a student asking “Can I re-sit a practical exam if I was sick?”, the answer with a page citation, and then a question the regulations did not cover, where the bot said so. Under the video was a table: 50 test questions, 86% correct, 9 of 10 unanswerable questions correctly declined, ₹0.7 per question. Then a section titled What didn’t work: retrieval failed on the fee tables, and she showed what she had tried.

“What did that tell you about her?” Priya asked.

“That she measures things. That she knows where it breaks. That she thinks about cost.” He paused. “That she’d do the same here.”

“And the twenty-two?”

“That they can follow a tutorial.”

Priya drew a shop front on the whiteboard. “Our Koregaon Park store gets people walking past for about three seconds. What goes in the window?”

“Not the flour sacks,” said Arjun. “The best cake, with a label and a price.”

“A README is a display window. Most engineers fill it with flour sacks: install commands, a list of libraries. Put the cake in the window: what it does, proof it works, the number that matters. The flour goes further down, for people who come inside.”

The misconception Arjun had held, which most learners hold, is that a portfolio proves you can build. Everyone applying can build a RAG chatbot now; models will even write it for them. What a portfolio must prove is that you can judge: choose a real problem, measure whether your solution works, find where it fails, and make sensible trade-offs. That is the job.

What to build: fewer, deeper, real

Arjun’s reviewing taught him what the evidence of judgement looks like. In order of how much it impressed him:

1. A real problem with real users or real data. Tanvi’s exam regulations. A tool for a parent’s shop. A bot for a college club’s event FAQ. Real data brings real mess (scanned pages, Hinglish, tables), and handling mess is the job.
2. An evaluation. A test set, a number, and how it changed. Even 30 questions is a world away from none. You learned how in Binary pass/fail evaluations.
3. Honest failure analysis. “Retrieval missed answers in tables; I tried X and Y; Y raised accuracy on table questions from 40% to 70%.” This is the most underrated section in any README.
4. Cost and latency numbers. Cost per query and time to first word show you think like someone who will run it in production.
5. Deployment. A link that works. Even a free-tier deployment with a spending cap shows you can finish.
6. Safety thinking. Prompt injection tests, least-privilege tools, a human in the loop where it matters.

From this module’s five projects, two or three done properly beat all five done shallowly. Choose ones that show different skills. A good set: one retrieval project with strong evals (Chat with any document or the search engine), one agent project with safety thinking (the app builder or the interviewer), and Crumb-Copilot-style integration work that is deployed and used by someone.

Show the answer

Portfolio B, clearly. Twelve tutorials show you can follow instructions in twelve areas. Two measured, honest projects show you can take a problem to a working, evaluated solution and understand its limits, which is what the job asks for every week. Breadth has some value, and you can show it in a single line (“also explored: fine-tuning with LoRA, image classification”), but depth gets interviews.

Following one README from flour sacks to display window

Arjun rewrote crumb-copilot that weekend. Here is the structure he landed on, which works for any AI project:

# Crumb Copilot
One assistant for bakery staff that answers from company documents, searches the web,
and remembers each user. Built for a 6-store bakery chain; used daily by 41 staff.

![Demo: a handbook question with a page citation, then memory across chats](demo.gif)

## Results
| Metric | Value |
|---|---|
| Eval set (20 real staff questions) | 18 / 20 pass |
| Cost per question | about ₹2.4 (was ₹37 in v1) |
| Time to first word | 2.7 s (was 9 s in v1) |

## How it works
(the architecture diagram, and one sentence per box)

## Design decisions
- Retrieval instead of pasting the whole handbook: v1 sent 104k tokens per message.
- Tool results are not stored in history: saves ~1,100 tokens on every later turn.
- user_id is set by code, never by the model: one prompt can't read another user's memories.

## What didn't work
- Summaries dropped order numbers until the prompt named them explicitly.
- Web pages tried to plant "memories"; now only user-stated facts are saved.

## Run it
uv sync && cp .env.example .env && uv run streamlit run app.py

## What I'd do next
Hybrid search for product codes; prompt caching for the system prompt.

Trace what a reviewer sees in ninety seconds, top to bottom:

• 0 to 10 seconds: the title and two sentences. They know what it is, who it is for, and that real people use it.
• 10 to 40 seconds: the GIF. They see it work, including a citation, which signals trust.
• 40 to 60 seconds: the results table. Three numbers, and two of them show improvement, which tells a story of iteration.
• 60 to 90 seconds: design decisions. Each one names a trade-off with a number. This is where a reviewer decides you think like an engineer.

Everything below that (how to run it, next steps) is for the reviewer who is already interested.

Arjun noticed that writing “What didn’t work” was uncomfortable. It felt like admitting weakness. Priya disagreed. “Every project has failures. Hiding them suggests you didn’t notice them. Showing them proves you did.”

The demo: ninety seconds, five beats

A demo is not a tour of features. It is a short story with a hard moment in it. Arjun used the same five beats for every project:

1. The problem (10 s). “Kavya answers 40 support emails a shift and used to open four tools for each.”
2. The happy path (30 s). One real question, answered, with the source visible.
3. The hard case (30 s). The thing most demos hide: an abstention, a blocked prompt injection, a caught error. This is what reviewers remember.
4. The numbers (10 s). “18 of 20 on the eval; ₹2.4 a question.”
5. The close (10 s). What you learned, in one sentence.

Record it with any screen recorder, at normal speed, with your voice. Cut every pause. Put it at the top of the README and in your LinkedIn post.

Resume bullets that carry numbers

Arjun’s first draft of a resume bullet was:

Worked on AI chatbot using LangChain, ChromaDB, OpenAI, Claude, FastAPI, Streamlit, Docker.

It lists seven tools and says nothing about what happened. A strong bullet has four parts: an action verb, what you built, the key technique, and a measured result.

Built a retrieval-augmented staff assistant over a 200-page operations handbook with page-level citations; cut cost per answer from ₹37 to ₹2.4 and first-word latency from 9 s to 2.7 s, passing 18 of 20 eval questions.

Two more, from the other projects:

Designed a chat-with-PDF tool that verifies every quoted citation against its source page in code; reached 94% page accuracy and 92% correct abstention on 60 test questions across three contracts and papers.

Built a structured AI interview prototype with rubric-based Pydantic scoring, quote verification and counterfactual bias tests (name, grammar, confidence variants; mean score shift under 0.2 points).

Rules for bullets:

• Real numbers only. Interviewers ask about every number. If you cannot explain how you measured it, delete it.
• Label personal projects honestly. “Personal project” or “course capstone” is fine. Implying a hobby project served a million users is not, and it unravels in one question.
• Tools go in a skills line, not in every bullet.

What AI engineering interviews actually ask

In the following weeks, Arjun sat in on all six final interviews. Across them, and in Priya’s experience at her previous company, the questions clustered into six areas. Each one maps to parts of this course.

Area	Typical question	Where you learned it
Fundamentals	“Why does a model ‘forget’ earlier messages? What is a token?”	Context windows, Tokens
Retrieval	“Your RAG bot gives wrong answers. How do you find out why?”	RAG pipeline, Hybrid search
Evaluation	“How would you know a prompt change made things better?”	Evaluations, LLM-as-judge
Agents and tools	“When would you not use an agent?”	Workflow patterns, Function calling
Production	“Cut this feature’s cost by half without hurting quality.”	Prompt caching, Fallbacks
Safety	“A user pastes ‘ignore your instructions’. What’s your defence?”	OWASP Top 10, Defence in depth

Plus two formats that cut across all of them: the system design interview and the behavioural interview.

The system design interview, followed end to end

A system design interview gives you an open problem (“design X”) and watches how you reason for 45 minutes. There is no single right answer. What is scored is your process: clarifying, estimating, designing, then probing your own design for weaknesses. Here is the one Arjun watched Priya run, with the strongest candidate’s answers.

The prompt: “Design an AI assistant that handles customer support for an online grocery company: 10,000 support conversations a day.”

Step 1: clarify (5 minutes). The candidate asked before drawing anything. Which channels? (Chat and email.) Languages? (English and Hindi.) What may the assistant do: answer only, or also issue refunds and change orders? (Refunds up to ₹500.) What happens today? (60 human agents; median first reply 4 hours.) Budget? (Not fixed; “show me the cost”.)

Step 2: estimate (5 minutes). Out loud, with round numbers:

• 10,000 conversations × about 4 turns = 40,000 model calls a day.
• Each call: about 3,000 input tokens (system prompt, policy excerpts, order data, history) and 200 output tokens.
• Input: 40,000 × 3,000 = 120 million tokens a day. Output: 8 million.
• At an assumed $4and$20 per million: $480+$160 = about $640 a day, roughly ₹56,000.
• “The system prompt and policies are about 2,000 of those 3,000 tokens and identical every time, so prompt caching could cut the input bill substantially. And most questions (‘where is my order?’) could go to a smaller, cheaper model, with a router sending hard ones to a large model.”

Even if the numbers are rough, doing the arithmetic out loud shows you think about cost before it becomes a surprise.

Step 3: sketch the architecture (10 minutes). A router that classifies each message; a retrieval system over policies and FAQs; tools for order lookup (read-only) and refunds (write, limited); a human handoff path; logging and tracing for every call.

Step 4: deep dive where it is risky (15 minutes). Refunds. The candidate proposed: the refund tool checks the amount and the order in code, not in the prompt; refunds over ₹500 or on accounts flagged for abuse go to a human; every refund uses an idempotency key so a retried request cannot refund twice (Idempotency keys); and every action is written to an audit log.

Step 5: evaluation and failure modes (10 minutes). An eval set built from 500 real past conversations; offline evals before any prompt change; online, track resolution rate, handoff rate, refund amounts per day and customer satisfaction; and an alarm if refunds per hour jump, which is how you would notice a prompt injection being exploited.

Show the answer

A question, not a yes or a no: “What is the cost of a wrong refund compared with the cost of a slow one?” Then lay out the trade-off with numbers. Automatic refunds speed up honest customers but turn any prompt injection or abusive user into direct financial loss. Propose a middle path: automatic up to a threshold, with per-account and per-hour limits in code, a human above it, and monitoring that pauses automation if refund volume spikes. Interviewers are testing whether you can push back with reasons, not whether you obey.

The behavioural interview: stories with a shape

Behavioural questions (“Tell me about a time you made a mistake”) test how you work with people and handle setbacks. The standard structure is the STAR method: Situation, Task, Action, Result. Arjun practised with the worst bug of his year:

• Situation: “Our contract Q&A app told our founder a delivery partner’s failed-delivery fee was ₹40. It was ₹60, and only after two attempts.”
• Task: “I had to find why, before she relied on it in a negotiation.”
• Action: “I traced the retrieval and found chunks from last year’s contract with another company mixing in, because I had no document filter. I added the filter, then made the model quote its sources and wrote code to verify every quote against the page.”
• Result: “Page accuracy went to 94% on 60 test questions, and in the negotiation, the app correctly told her a clause wasn’t in the contract. I now add a filter test to every multi-document system.”

Notice the shape: a real mistake, owned plainly, a specific fix, a number, and a lesson that changed how he works. Prepare five such stories from your projects: a bug, a trade-off, a disagreement, a time you said no, and something you learned fast.

Where candidates trip up

In the six final interviews, Arjun saw the same stumbles repeatedly:

• Naming tools instead of reasons. “I’d use LangChain and Pinecone” is not a design. “I need metadata filtering by customer and fast updates, so…” is.
• Never estimating. Candidates who skipped the arithmetic could not defend their designs when asked about cost.
• Defending every choice. The strongest candidate said “that’s a weakness in my design” twice, then proposed fixes. Interviewers trust people who see their own blind spots.
• Bluffing. Saying “I haven’t used that, but here is how I’d reason about it” beats a confident wrong answer every time. (You have spent this whole course building systems that abstain. Do the same.)

Try it yourself

Do these four things this week. Together they take about six hours.

1. Rewrite one README using the display-window structure above: two-sentence pitch, demo GIF, results table, design decisions, what didn’t work, run instructions.
2. Write three resume bullets with the four parts (verb, what, technique, measured result). Check that you can explain how you measured every number.
3. Record a 90-second demo with the five beats, including one hard case.
4. Answer three practice questions out loud, recording yourself, two minutes each. Pick from this list:
   • Explain to a non-engineer why a chatbot “forgets” earlier messages.
   • Your RAG system’s answers got worse after you changed the chunk size. How do you investigate?
   • When would you fine-tune instead of using RAG?
   • How would you stop a tool-using agent from deleting data?
   • Design a system that drafts replies to 600 Google reviews a month. Estimate its cost.
   • What is prompt injection, and why can’t you just tell the model to ignore it?
   • How would you evaluate an LLM-as-judge before trusting it?
   • Tell me about a bug in an AI system you built. (STAR)

Expected result: a README a stranger understands in ninety seconds, three bullets with numbers you can defend, a demo link, and three recordings where you can hear yourself improving from the first to the third.

Show a model answer for "why does a chatbot forget?"

“A language model doesn’t keep any memory between requests. Each time you send a message, the app sends the conversation so far along with it, and the model reads all of it fresh. But there’s a limit to how much it can read at once, called the context window, and every word costs money and time. So long conversations have to be trimmed or summarised, and when something is trimmed, the model genuinely never saw it. At my company, we keep the last few exchanges word for word and fold older ones into a summary, which is why it still remembers an order number from twenty messages ago.” Under two minutes, an analogy-free explanation, and a concrete example from real work.

Common mistakes

• Many shallow projects. Two or three deep ones, with evals and failure analysis, beat a dozen tutorials.
• README as install manual. Put the problem, the demo and the numbers first. Instructions last.
• Hiding failures. A “What didn’t work” section is evidence of judgement, not weakness.
• Unexplainable numbers. Every number on your resume is an interview question. Only claim what you measured.
• Learning answers instead of reasoning. Interviewers change one detail and watch. Practise thinking out loud with estimates, not memorising scripts.

Recap

• A portfolio must prove judgement, not just the ability to build: a real problem, an eval, honest failures, cost and latency.
• A README is a display window: pitch, demo, results table and design decisions in the first ninety seconds.
• A demo has five beats, and the hard case is the one people remember.
• Resume bullets need a verb, what you built, the key technique and a measured result you can defend.
• AI engineering interviews cover fundamentals, retrieval, evals, agents, production and safety, plus system design (clarify, estimate, design, probe) and STAR stories.
• Say “I don’t know, but here’s how I’d reason about it”. It is the abstention you have been building into systems all along.

Crumb hired Tanvi. On her first day, Arjun handed her his own laptop sticker, a small crumb with a cursor, and a printed copy of the operations handbook. “You’ll read this once,” he said. “After that, ask Copilot.”

That evening, Arjun stood in front of the bathroom mirror practising for the next morning, the first time he would present Crumb Copilot to Meera and all six store managers together. He did not know yet that the next morning would also bring a new model release, and with it, a very different kind of test.

Go deeper

• Building effective agents, a good model for how to write about design decisions clearly.
• Hugging Face LLM course, useful for brushing up fundamentals before interviews.
• Revisit What an AI engineer actually does and notice how much more of it you can now explain.
• Deploying your AI app to the cloud, so your portfolio links actually work.