The polished CV

Many people write a CV like Alex’s, and most of them are not dishonest. They work in places where the CV is a sales document. The advice that they read online says the same: strong verbs, a number on every line, the keywords from the posting. Each small step looks normal. Together, the steps describe a person who does not exist.

Alex has worked for three years at Brightpath Digital, a consultancy. A consultancy sells its people to clients by the day, so it writes their profiles to win projects. Alex learned to describe his work in that language. Now he has less client work, and he wants a product job. The Quillfield posting asks for almost every tool that he has heard of, so his CV matches it.

This page is about what happens when a CV promises more than a person can explain. At the end, we tell the same story honestly, and we see what his real experience was worth.

AM

The candidate

Alex Moreau

AI Engineer, 3 years at a consultancy

• 3 years at Brightpath Digital
• Python
• Montreal
• Applied through the job board

• AI Engineer, Brightpath Digital (3 years). Delivered generative AI solutions for enterprise clients in finance, retail and the public sector.
• Architected multi-agent systems with LangGraph, CrewAI and AutoGen.
• Fine-tuned Llama 70B with LoRA for domain adaptation.
• Built enterprise RAG with 98% accuracy.
• Reduced LLM costs by 70%.
• Expert in prompt engineering, DSPy, guardrails and LLMOps.

What Nadia sees before the call

Nadia reads the CV with the job description open next to it. They match almost word for word. The posting lists three agent frameworks, and so does the CV. The posting asks for LoRA, and the CV has it.

This alone tells her little. Many good candidates copy keywords, because the internet tells them to. So she looks for lines that she can test with one or two specific questions:

• “98% accuracy”. Of what, on how many questions, checked by whom? A percentage without the count behind it is not evidence yet.
• “LangGraph, CrewAI and AutoGen”. A team rarely uses three agent frameworks for one system. Which one did he choose, and why?
• “Fine-tuned Llama 70B”. LoRA on a 70B model is possible, but it needs serious GPUs and good data. What data did he use, on what hardware, and did the result ship?
• “Reduced LLM costs by 70%”. From what, to what, and did quality stay the same?

She will not ask about “expert” in five areas. The other lines will answer that. Her plan is the same as for every candidate. Alex chooses a project, and she follows what he says, one level deeper each time.

Terms on this page

• RAG (retrieval-augmented generation): the system first finds passages in your documents, then the language model answers from them.
• A chunk is one small piece of a document. An embedding is a list of numbers that represents the meaning of a chunk, so the system can find chunks with a similar meaning.
• A guardrail is a check that blocks or fixes an unsafe or wrong answer.
• A hallucination is a statement that the model writes but the source does not support.
• OCR (optical character recognition) turns a scanned page into text.
• PII is personal information that can identify a person, such as a name or an address.

The interview

Minutes 0 to 5: the opening

Nadia(interviewer):

Hi Alex, thanks for your time. I’m Nadia, staff engineer on Claims Intelligence. So, the plan. First I’d like to hear about something you built, and I’ll ask a lot of follow-up questions. That’s normal. Then a problem we have, and then your questions. And like in the invite, this round is without AI assistants. Paper notes are fine. If you want to look something up, just tell me.

Alex(candidate):

Of course, absolutely. Thanks for having me. Claims is such an interesting space for generative AI.

Nadia(interviewer):

Good. Then let’s start with you. Pick one project you’re proud of and walk me through it.

What the interviewer is checking

Nadia says the rule about AI tools to every candidate, at the start, in a neutral voice. She is not trying to catch anyone. She wants everyone to know the rules before the round starts.

Minutes 5 to 18: the project, then deeper

A pause before he answers.

Alex(candidate):

Sure. At Brightpath, I architected an enterprise-grade retrieval-augmented generation platform for a large client’s internal knowledge base. The pipeline had four layers. An ingestion layer with semantic chunking and embedding generation. A hybrid retrieval layer, combining dense vector search with keyword search, followed by a cross-encoder re-ranker. A multi-agent orchestration layer on LangGraph, with a router agent, a retrieval agent and a validator agent. And a guardrails layer to make sure responses were grounded, safe and compliant. We evaluated it with a robust framework and reached 98% accuracy.

What Nadia hears

Every sentence is correct, but nothing in it is personal. There is no document, no user, no number that she can check, and no “I decided”. You do not need to know these words. The point is that none of them is about one real project. So her next questions look for the one project behind it.

Nadia(interviewer):

Okay. Let’s go slower. What were the documents, and who asked the questions?

Alex(candidate):

The corpus was the client’s internal knowledge base. Policies, procedures. Mostly HR, actually. Leave, benefits, travel.

Nadia(interviewer):

Okay, HR policies. You said 98% accuracy. 98% of what?

Alex(candidate):

We used a combination of automated and human evaluation. On the automated side, RAGAS metrics, so faithfulness and answer relevancy, and on top of that human review to validate the results. The 98% was the share of answers that met the quality bar.

Nadia(interviewer):

Mm-hm. How many answers was that?

Alex(candidate):

It was… around fifty questions. For the final evaluation.

Nadia(interviewer):

Fifty. So 48 right… no, sorry, 49 right, one not. Who decided that an answer was right?

Alex(candidate):

The client’s HR team reviewed them with us.

Nadia(interviewer):

And the one that failed, do you remember it?

Alex(candidate):

It was an edge case. An ambiguous query, where retrieval brought back a related but not quite relevant policy. We mitigated it with query rewriting.

How the interviewer goes deeper

Nadia never says “I don’t believe you”. She asks for the next detail: what, how many, who, which one. The person who did the work remembers these details. For anyone else, each question is harder than the one before.

How one number goes deeper

1. 1

   “Walk me through the project.”

   A complete, general architecture. Correct words, nothing to check.

2. 2

   “98% of what?”

   Metric names first. Then: about fifty questions, so 49 out of 50 in one test.

3. 3

   “Who decided an answer was right?”

   The client's HR team. So the number was 49 of 50 answers accepted by HR in one demo. That is a real but small check, not the 'enterprise accuracy' the CV suggests.

4. 4

   “Which one failed?”

   A general answer. A person who ran the test usually remembers the real question.

Nadia(interviewer):

Your CV says LangGraph, CrewAI and AutoGen. Which one did you use for the HR assistant? And why that one, and not the other two?

Alex(candidate):

Each framework has its strengths. LangGraph gives you fine-grained control through a graph-based state machine, ideal for production workflows. CrewAI offers a higher-level, role-based abstraction for fast prototyping. And AutoGen excels at conversational patterns between agents. So it depends on the use case.

Nadia(interviewer):

That’s a fair general comparison. But I mean your system.

Alex(candidate):

LangGraph. For the control. When the validator rejected an answer, it went back to retrieval with a new query, up to a maximum number of retries.

Nadia(interviewer):

What was the maximum?

Alex(candidate):

It was configurable. I’d have to check, honestly.

What the interviewer is checking

“Which one, and why not the others?” asks for a decision, not a definition. Alex answers with a comparison that fits any project. When the questions become specific, his answers become short. Nadia notices this change more than any single answer.

Nadia(interviewer):

That’s fine. Different question. What was the worst bug on this project? One day when something broke and you had to find out why.

Alex(candidate):

The biggest challenge was hallucination, which we addressed through grounding, citations and output guardrails.

Nadia(interviewer):

That’s a type of problem. I mean one bug. Anything you remember.

Alex(candidate):

Um. Okay, there was one. The vacation policy had a table. Days of leave by years of service. And the bot kept giving the wrong number. Someone with six years got the number for two years.

Nadia(interviewer):

How did you find the cause?

Alex(candidate):

I saw three leave questions wrong in the same way. So I opened the chunks it retrieved, and the numbers were all on one line, no headers. The PDF parser flattened the table. Felix, a colleague, fixed the parsing. But I found it.

Nadia(interviewer):

That’s a good catch, and a very common problem with tables. So what was your role on the team, day to day?

The one answer that sounds real

This answer has a document, a wrong number, a colleague, and the steps he took to find the cause. It is also smaller: Alex found the problem, and someone else fixed it. This is what Nadia was looking for.

Alex(candidate):

I owned the end-to-end delivery. I led the architecture decisions, the evaluation strategy and the client communication, and I worked across the stack.

Where this goes wrong

For a moment, Alex talked about his own work. Then he went back to the CV. Now the large claims make the small, true story harder to believe.

Nadia asks two short questions about the other lines. On fine-tuning, she asks what data he used and how he measured the change. Alex says it was “an exploration” that did not go to production. When you read “fine-tuned for domain adaptation”, you expect training data and a measured result. Neither existed.

LoRA

LoRA (low-rank adaptation) is a cheap way to fine-tune a model. The original weights do not change, and you train a small number of extra weights. It is real and common.

On the 70% cost reduction, she asks, “From what, to what?” First Alex gives a general answer. Then he says it was mostly one feature, moved to a smaller model.

Minutes 18 to 25: the whiteboard

Nadia(interviewer):

Could you draw the HR assistant on the shared whiteboard? Boxes and arrows are fine.

Alex(candidate):

Sure. So… user, router agent, retrieval agent, vector database, the LLM, then the validator, guardrails, and back to the user.

Nadia(interviewer):

Thanks. Which vector database was it? And when a policy changed, how did the new version get in, and the old one out?

Alex(candidate):

Sorry, the old one out? You mean deleting the old documents?

Nadia(interviewer):

Yes. Say the travel policy gets a new version. How does the assistant stop using the old one?

Alex(candidate):

Right. We evaluated several databases. Pinecone, Weaviate… In the end I believe it was the client’s Azure AI Search. The updates weren’t in the scope of the proof of concept. It was a demo for the client’s leadership.

Nadia(interviewer):

Ah, so it didn’t go live with employees?

Alex(candidate):

Not yet. The client is still deciding on the next phase.

What the interviewer is checking

Every box in a drawing invites a question. Alex draws the general picture from his first answer. The real facts come out one at a time: HR policies, fifty questions, one demo, not live.

Nadia(interviewer):

Thanks, that’s helpful. I have a good picture of this project, so I’ll move on to our problem now.

How Nadia handles it

Nadia stays calm and polite. She does not point out the contradictions, and she does not ask “Are you reading this?” She cannot know, and an accusation would help nobody. Pauses and glances mean nothing on their own. People pause for many reasons: a second screen, notes, nerves, or thinking in a second language. She asks about facts, writes short notes, and says clearly when she moves on.

Minutes 25 to 48: the Quillfield problem

Nadia(interviewer):

Here’s a real problem on our side. A claim packet comes in: 20 to 60 pages, scanned forms, the adjuster’s notes, emails, photos, a contractor’s estimate. Adjusters tell us they spend about 40 minutes reading a packet before they can act. We want to give them a one-page draft summary: the key facts, the open questions, and what’s missing. How would you approach it?

Alex(candidate):

Great problem. I’d architect a multi-agent pipeline. An ingestion agent with OCR and layout analysis for the scanned documents. A summarisation agent with a carefully engineered prompt, possibly optimised with DSPy. A critic agent that checks the summary against the source for hallucinations. An LLMOps layer for tracing, cost tracking and continuous evaluation. And guardrails for PII redaction, to stay compliant with GDPR.

Where this goes wrong

Alex designs a solution before he asks one question about the problem. He also names GDPR, the European privacy law. But Quillfield’s insurers are in Canada and the US, where PIPEDA and other laws apply. It is a small slip. Still, it shows that the answer is general, not about this problem.

Nadia(interviewer):

Okay. Let’s take one case. The contractor’s estimate says the roof was replaced in 2019. The adjuster’s note says 2021. That matters for the claim. What should the summary do? And how would you know, before release, that it does it?

Alex(candidate):

The critic agent would detect the inconsistency and flag it. To validate, I’d use an LLM-as-judge approach with faithfulness and completeness scores, tracked in a dashboard.

Nadia(interviewer):

And who checks the judge?

LLM-as-judge

LLM-as-judge means that a second language model scores the output of the first one. It is fast and cheap, but the judge can be wrong too. So a team first compares the judge’s scores with human labels. Nadia’s short question checks if Alex knows this.

Alex starts to speak, stops, and starts again.

Alex(candidate):

Honestly… on our project there was no judge in the end. The HR people went through the fifty answers in a spreadsheet. Right, wrong, or partly right, and a comment. We fixed things, and then they went through it again.

Nadia(interviewer):

That’s actually much closer to what we’d do. We have two former adjusters who label data. About four hours a week between the two of them, in total, and most of it goes to the weekly intake sample. If you had a few of those hours, what would you ask them to do first?

Alex(candidate):

Hmm. Maybe… give them twenty real packets, and they write down the facts that must be in the summary. Then you check if the summary has them.

Nadia(interviewer):

Okay. And the roof case?

Alex(candidate):

Contradictions like the roof, you’d want some examples of those on purpose.

A stronger answer, from the start

Alex had a good answer the whole time, because he lived it. Said at the start, it could sound like this:

“I haven’t built evaluation at this size. On my last project it was fifty questions, and the client’s HR team checked every answer in a spreadsheet. It was small, but I learned something from it. The people who know the documents must decide what ‘right’ means. So here I’d start the same way. I’d ask your claims experts to list the facts that must be in the summary, for twenty or thirty real packets, with some contradictions on purpose. Then I’d count three things: missing facts, wrong facts, and statements with no source in the packet. Only after that would I add an LLM judge, and I’d check it against their labels first.”

Nadia(interviewer):

That’s a reasonable start. One more thing. Say we summarise each packet when it arrives. Two days later, a new document comes in for the same claim. What happens?

Alex(candidate):

Then… you’d generate it again, I guess. To be honest, I haven’t really worked with documents that change.

The edge

Here Alex reaches the edge of what he knows: documents that keep changing. He says so, and that is good. But after the CV claims, Nadia also asks herself: what else was bigger than the real work?

Nadia also asks about scanned pages and the health information in injury claims. Alex offers “PII redaction” for both. He does not ask who may see that information.

Minutes 48 to 57: Alex's questions

Alex(candidate):

Do you use LangGraph in production, or another framework?

Nadia(interviewer):

Neither, at the moment. The extraction is plain Python steps in a FastAPI service. We’d need a reason to add a framework. The list in the posting is longer than what we use. That’s our mistake.

Where this goes wrong

Alex’s questions are polite but general. He does not ask about the real work: who is on call, how the experts’ hours are used, or when a feature is ready. See An interview is a conversation in both directions.

Minutes 57 to 60: the close

Nadia(interviewer):

Thanks, Alex. I’ll write my notes today, and the team discusses all candidates together. Hannah will get back to you by the end of next week, with a yes or a no.

Alex(candidate):

Thank you. Can I ask how you think it went?

Nadia(interviewer):

I’d rather not give a result before the team talks. But I can say this: the vacation table and the spreadsheet were the most useful parts for me.

Why this works

Nadia does not give a decision alone. But she gives Alex one honest sentence, and it tells him what to do next time.

After the call: Nadia’s notes

Nadia writes her notes within the hour. She scores only what she heard and could check.

Candidate: Alex Moreau. Round: technical deep dive. Interviewer: Nadia Rahman.

Strong evidence: none in this round.

Some evidence:

• RAG: one of four people on a proof of concept (HR policies, ~50 test questions, demo only). The table-parsing bug was specific and first-hand.
• Evaluation: reviewed answers by hand with the client’s HR team. Small, but the right instinct.

No evidence:

• LLM systems in production. The project did not go live.
• Agent frameworks. Could not say why LangGraph, or what the retry limit was.
• Fine-tuning. “An exploration”; could not describe the data or a result.
• Changing documents, scale, failure handling.

Concern: several CV claims did not survive follow-up. “98% accuracy” was 49 of 50 answers in one demo. “Reduced LLM costs by 70%” was one feature moved to a smaller model. Answers were long and general, then short and different when questions became specific. My decision rests on the claims that I could not verify.

Recommendation: no hire. Trust problem: I can’t tell which parts of the CV are true, so I can’t rely on any of them. The honest parts were promising, but for a more junior role.

What happened next

In the debrief, Marcus asks about the junior role next quarter. Nadia says the true parts are a reasonable start. But the team must trust what a person says about their own work, and after this interview it cannot. They agree not to continue.

Hannah sends Alex a polite rejection eight days later. He asks for feedback, and Quillfield sends two sentences: “The interviewer found it hard to connect the claims on your CV to specific work that you did. The most useful part of the conversation was your description of the evaluation with the HR team and the table bug.”

The same person, told honestly

Now we tell the story again. Same person, same three years, same project. The only change is that the CV says what he really did.

AM

The candidate

Alex Moreau

Consultant, Data and AI, 3 years, moving into AI engineering

• 3 years at Brightpath Digital
• Python and SQL
• Montreal

• Consultant, Data and AI, Brightpath Digital (3 years). Two years of Python data pipelines and dashboards for four clients; the last year on generative AI projects.
• One of four engineers on a RAG proof of concept that answered HR policy questions (about 400 documents). Wrote the 50 test questions with the client’s HR team and ran the answer review. 49 of 50 answers rated acceptable in the final demo. Not deployed.
• Found why leave answers were wrong: the PDF parser flattened tables, so chunks mixed up rows. Helped a colleague fix it (each table row kept with its headers).
• Moved one feature (sorting documents by type) to a smaller model after the team compared outputs on 100 examples. Cost for that feature down about 70%.
• Learning: ran a LoRA fine-tuning tutorial on a small open model. No fine-tuning in production.

This CV is smaller. In an interview it is much stronger, because Alex can explain every line. Here is the same project question, answered honestly.

Minutes 5 to 15, told honestly

Alex(candidate):

So, first: it’s a proof of concept, not a production system. Four of us built an assistant that answered questions about a client’s HR policies. About 400 documents. My part was mostly the evaluation. I wrote fifty test questions with two people from their HR team. Then we checked every answer in a spreadsheet. Right, wrong or partly right, with a comment. In the final demo, HR said 49 of the 50 were acceptable.

Nadia(interviewer):

Okay. Anything you found along the way?

Alex(candidate):

Yes, a bug with a table of leave days. The parser flattened it, so the answers took the wrong row. I think that was the most useful thing I found.

Nadia(interviewer):

Nice. How did you and HR agree on what “acceptable” meant?

Alex(candidate):

We had three rules. The right policy, the right number if there is one, and a link to the right section. The two HR people disagreed on… maybe five answers at first? Something like that.

Nadia(interviewer):

What kind of answers?

Alex(candidate):

Mostly answers that were correct but left out an exception. We decided that a missing exception counts as wrong.

Nadia(interviewer):

Why that decision?

Alex(candidate):

Because an employee acts on the answer. If it says you get fifteen days, and it forgets that part-time staff get fewer, that’s a real problem for someone.

Nadia(interviewer):

That’s exactly our problem with claim summaries. What’s left out matters as much as what’s wrong. What would you change about that evaluation now?

Alex(candidate):

Fifty is too few. And people who know the documents well wrote all of them. Real employees ask in a messier way. So I’d collect real questions from a pilot group. And I’d keep the old fifty as a regression test, so a change doesn’t break what already worked.

Nadia(interviewer):

Good. You haven’t run anything in production. How do you think about that gap?

Alex(candidate):

It’s my biggest gap. It’s also why I want a product job. I wrote data pipelines that ran every night for clients, so I know some basics, like logging and reruns. But I haven’t been on call for a live AI feature. I’d want to learn that next to someone who has.

Why this works

Every answer gives Nadia something to follow, and every follow-up gets a real answer. Alex reaches his edge (production) and names it himself. Now Nadia can judge his real level, and it is a level that she can work with. See Build real skills, and learn to explain them.

In this version, Nadia’s notes have no concern about trust. Production gets “no evidence”, and Alex said that himself. She recommends the system design round. She adds that he may fit the lower end of the band, or the junior role next quarter. Nothing is certain: Owen’s round will test exactly the production gap that Alex named. But Alex is still in the process.

Honest Alex is not more skilled. He is the same person. The difference is that Nadia can trust what he says, so his real experience counts.

What to take from this

• A small claim that you can explain is better than a large one that you cannot. “49 of 50 answers, checked by HR, in one demo” is modest, and it starts a good conversation. “98% accuracy” stops the conversation when it breaks.
• When one claim breaks, the others break with it. Nadia did not reject Alex for too little experience. She rejected him because she could no longer tell which parts were true. So the true parts were lost with the rest.
• Outside help gives you words, not your experience. A tool can write a perfect general answer. It cannot tell you the retry limit in your own system, or which question failed in your own test. See Do not use AI or other help to cheat.
• “I haven’t done that” is a good answer. Alex’s best moments were the honest ones. They showed Nadia his real level.

If your profile is like Alex’s

If your CV has grown bigger than your experience, you can fix it before your next interview. It takes a few evenings.

1. Test each line out loud. For each line, answer four questions. What exactly did I do? How many, measured how? What went wrong? What would I change? If you cannot answer, rewrite the line until you can. Evidence over self-ratings helps you separate what you did from what happened near you.
2. Say what you did, and give the count behind every number. Write “One of four engineers; I wrote the test set” and “49 of 50 test questions, checked by HR”, not “98% accuracy”.
3. Remove tools that you only read about. If you ran a tutorial, write “tutorial”.
4. Practise one project walkthrough. Use the structure in Explain decisions: the problem, the options, your choice, the result in numbers, the limits. Record yourself once. Then listen for sentences that could describe any project.
5. Close one real gap with a project. Alex’s gap is production. Deploy a small RAG project that other people use. Add a test set and logging, then change the documents and see what breaks. Portfolio anatomy shows what to include. The Docker and CI/CD courses help with deployment. Then use Prepare for applications to choose the level that you apply for.

If you work at a consultancy, its sales language is not your fault. But in an interview, you speak only for yourself. Describe your work the way you would to a colleague who was there.