All posts

Interviews · AI workflow · Job hunting

How to explain code you built with AI.

Building the project is no longer the hard part, and everyone in the room knows it. The hard part is the eleven minutes afterwards when somebody asks why line 34 is there. Here is the method, the answers that work, and the drills that make them true instead of rehearsed.

Deric YeeDeric Yee 8 September 2026 9 min read
Two people in a meeting room discussing work on a laptop screen

A portfolio used to be evidence. You built the thing, therefore you could build things, and the project was the argument. That inference is dead and every hiring manager knows it, because they can produce a comparable project over lunch with the same tools you used.

What replaced it is a conversation. The project gets you into the room, and the explanation is the actual assessment. This is not a hurdle invented to catch people out. It is the most efficient signal available now, because explaining a decision requires having made one, and no amount of generated output produces that retroactively.

The good news is that this is a learnable skill with a structure, not a personality trait. Most people who fail it are not lacking understanding, they are lacking a way to organise what they know under pressure. So here is the structure.

The five layers of explaining code

Interviewers work downwards. Almost everyone survives the first two. Layer three is where the conversation usually ends, in both directions.

01What it does"What is this?"

The feature in one sentence a non-developer would follow. Nearly everyone can do this layer, which is why it proves nothing on its own.

Weak version: Reciting the README.

02How it works"Walk me through it."

The path a request takes through your system: what receives it, what it touches, what comes back, where the data lives. Follow one real user action end to end rather than listing files.

Weak version: Naming the technologies instead of describing the flow.

03Why this way"Why did you do it like that?"

The decision and the alternative you did not take. This is where most candidates stop being able to continue, because accepting a generated answer feels identical to choosing one until somebody asks.

Weak version: "That is how the tutorial did it" or "it was what the AI suggested".

04What you rejected"What did you change about the AI output?"

The specific thing that came back wrong and what you did about it. One concrete example here does more for you than an hour of the previous three layers.

Weak version: Claiming the output was fine, which is never true and is heard as "I did not look".

05Where it breaks"What happens at a thousand users?"

The known limits: what you did not handle, what would fall over first, what you would fix given another week. Volunteering this reads as senior. Being caught without it reads as naive.

Weak version: Saying it is production-ready when it plainly is not.

The reason layer three is the wall is worth sitting with, because it explains a lot of otherwise confusing interview outcomes. Accepting a generated answer feels exactly the same as choosing one. You read it, it seemed right, you moved on, and the memory it leaves behind is indistinguishable from the memory of having decided. The difference only surfaces when someone asks for the alternative you did not take, and there is nothing there, because there never was an alternative in your head.

That is not a character flaw and it is not laziness. It is a genuinely new failure mode that the tools created, and the fix is a habit rather than a virtue: decide first, generate second. Write down what you want and why before you ask for it. Then the memory exists, because you made it.

Should you admit you used AI?

Yes, and with no apology in your voice. Stack Overflow’s 2025 survey of more than 49,000 developers found 84% using or planning to use AI tools, with 51% of professionals using them daily. You are not confessing to anything. You are describing Tuesday.

The same survey found 46% of those developers actively distrust the accuracy of AI output, and that number is the actual subtext of the question you are being asked. Your interviewer is not checking whether you used the tool. They are checking whether you are in the 46% who read it sceptically or the group who did not. So the useful answer is never “yes but I understand it all”, which is unverifiable and slightly defensive. The useful answer names something specific you rejected.

The same four questions, answered two ways

The weak answers below are not strawmen. They are close paraphrases of what we hear in mock interviews, and they are the default rather than the exception.

Why did you use this database?

Ends the interview

It was the one in the tutorial and it worked fine.

Continues it

I needed relations between users, orders and items, so I wanted SQL rather than a document store. I picked Postgres through Supabase because it gave me auth in the same place and I did not want to build session handling myself for a first project.

Where did you use AI here?

Ends the interview

Mostly everywhere, but I understand all of it.

Continues it

The form validation and the CSS are almost entirely generated. The data model I did myself because getting it wrong is expensive later. The bit I fought with it about was error handling, it kept swallowing failures silently and I wanted them surfaced.

What is the weakest part of this project?

Ends the interview

I think it is pretty solid, honestly.

Continues it

The order listing does one database query per order inside a loop. It is fine at my test size and it would time out at a few hundred. I know the fix is to fetch them together, I ran out of time before the deadline I set myself.

How would you add a search feature?

Ends the interview

I would probably ask Claude how to do it.

Continues it

For this size, a SQL LIKE query against the title column, added at the same layer the existing filters live in. If it needed to be fuzzy or fast at scale I would move to Postgres full-text search rather than reaching for a search service, because that is a lot of infrastructure for one field.

Read the third pair again, because it is the counterintuitive one. The strong answer is an admission that the code has a performance bug in it. That answer is better than claiming the project is solid, and it is better for a reason worth internalising: knowing precisely where your work is weak is the clearest possible evidence that you understand it. Nobody expects a portfolio project to be production-hardened. Everybody expects a developer to know what they shipped.

A worked example

Here is a login endpoint of the kind an assistant will produce for you in about four seconds. It is a good piece of code. Read it, then read the five layers underneath it.

app/api/login/route.ts
export async function POST(req: Request) {
  const { email, password } = await req.json()

  const user = await db.user.findUnique({ where: { email } })
  if (!user) return Response.json({ error: 'Invalid' }, { status: 401 })

  const ok = await bcrypt.compare(password, user.passwordHash)
  if (!ok) return Response.json({ error: 'Invalid' }, { status: 401 })

  const token = await signSession({ userId: user.id })
  return Response.json({ ok: true }, {
    headers: { 'Set-Cookie': serialiseCookie(token) },
  })
}

01 · What it does

It logs a user in. It takes an email and password, checks them, and gives the browser a cookie that keeps them signed in.

02 · How it works

The request arrives with an email and a password. We look up the user by email. We never store the password itself, only a hash, so we compare the submitted password against that hash rather than against a stored password. If it matches we sign a session token and set it as a cookie, which the browser sends back on every subsequent request.

03 · Why this way

Both failure paths return the same generic message and the same 401. That is deliberate. If a missing user returned “no such account” and a wrong password returned “wrong password”, anyone could use the login form to discover which email addresses have accounts. A cookie rather than returning the token in the response body, because a cookie can be marked HttpOnly and is then unreadable to any JavaScript running on the page.

04 · What I rejected

The first version returned the token in the JSON body and I was storing it in local storage on the client, which is what most tutorials show. I moved it to an HttpOnly cookie once I understood that any injected script on the page can read local storage and cannot read that cookie. The generated version was not wrong exactly, it was the convenient default.

05 · Where it breaks

There is no rate limiting, so nothing stops somebody trying thousands of passwords. That is the first thing I would add. It also does not handle the timing difference between a missing user and a wrong password, which is a subtler version of the same leak I closed above.

Notice what the explanation above is actually made of. Almost none of it is syntax. It is a series of small decisions with reasons attached, and one honest limit at the end. That is the whole shape of a strong technical conversation, and it is available to somebody who has been coding for four months, provided they were paying attention to why rather than only to whether it ran.

Notice too that the person giving that answer did not write most of those lines. They chose them. In 2026 that is the distinction the entire hiring process is built to detect, and it is the same distinction we drew in what AI-native actually means for a junior.

Four drills that make it true rather than rehearsed

You cannot revise for this the night before, because the thing being tested is whether the decisions happened at the time. These build the memory as you go.

01

Read your own diff

Before every commit, read the changes line by line as though a stranger wrote them. This is the single habit that separates the two postures, it costs about ninety seconds, and almost nobody learning alone does it.

02

Write commit messages that say why

"Fix bug" teaches you nothing. "Fetch items in one query, the per-order loop timed out at 300 records" forces you to have had a reason. Six weeks later this is also the only record of what you were thinking.

03

The deletion test

Delete one file you did not write by hand and rebuild it from your memory of the decisions, not the syntax. Look up whatever syntax you need. If you cannot reconstruct the reasoning, you did not own that file.

04

The two-minute explanation

Record yourself explaining the project to someone non-technical. Listen back. Count how many times you say "basically" or "it just". Each one marks a spot where you are gesturing at something you have not understood yet.

What to do about the code you already cannot explain

If you are reading this with a portfolio that has holes in it, you have two honest options and one dishonest one. The dishonest one is to hope the question does not come. It comes.

Option one: understand it. Open the file with the assistant in tutor mode and ask it to explain the code line by line, then interrogate the explanation rather than accepting it. Ask what would happen if you removed a line. Then remove the line and find out whether the answer was right. An hour of this per file is usually enough, and the interrogation is the part that makes it stick.

Option two: delete it. This feels like going backwards and it is not. Three projects you can defend completely beat six with holes in them, because the first hole a hiring manager finds retroactively devalues everything else you showed them. A smaller, honest portfolio is a stronger artefact. We went into what actually belongs in one in portfolio projects that get interviews.

Why this is so hard to learn alone

There is a structural reason self-taught learners struggle specifically with this skill, and it is not effort. Explaining is a two-person activity, and learning alone gives you one. An AI assistant will accept your explanation, because it accepts the framing you gave it. What you actually needed was somebody to say “that is not why, that is what” and make you go again.

Our own enrolment data suggests people sense this even when they do not act on it. Among students rating what they need to learn well, 87% named mentor feedback and 97% said they learn through hands-on projects (n=62). Yet 55% of the same cohort bought the part-time or self-paced format, and only 9% chose full-time in person (n=520 of 553). People know they need the second person in the room and then buy the option that does not have one, usually for entirely reasonable reasons involving a job and a mortgage. We wrote the whole finding up, sample sizes and all, in our research on 553 enrolled students.

If you are learning alone, the workaround is to manufacture the second person. Post your code where strangers will critique it. Pair with someone at your level and take turns interrogating each other’s decisions. Explain a project to a friend who does not code and watch where their face goes blank. It is worse than a real reviewer and it is enormously better than nothing.

And if you would rather have the real thing, that is precisely what a cohort buys you: your work read by somebody who has done this longer than you, often enough that your judgement calibrates against theirs. Every project in our published curriculum ends in that conversation rather than in a green tick, and you can sit in a live session for free on the free trial to see what being asked “why did you do it that way” actually feels like.

The broader point holds regardless of where you learn. The fundamentals under this skill, being able to read code, reason about data, and articulate a trade-off, are the same fundamentals that hold their value whichever direction you go afterwards: frontend, backend, data, AI engineering, or building your own thing. Nothing in this article expires when the current tools do.

FAQ

  • Should I tell an interviewer I used AI to build my project?

    Yes, without hedging. Practically every professional developer uses these tools now, so the disclosure carries no stigma, and hiding it fails the moment you cannot explain a line. What interviewers are actually listening for is what you did with the output: what you rejected, what you changed, what you tested. An answer like "I had Claude draft the auth flow, then rewrote the session handling because its version kept the token in local storage" is a stronger signal than claiming you wrote everything by hand, because it demonstrates judgement rather than typing.

  • How do I explain code I do not fully understand?

    You do not. That is the honest answer, and trying is how interviews end badly. If there is code in your portfolio you cannot explain, you have two options before the interview: understand it, or delete it. Understanding it usually takes an hour with the assistant in tutor mode, asking it to explain the code line by line and then testing yourself by breaking it deliberately and predicting what fails. Deleting it costs nothing, because a smaller project you can defend completely beats a larger one with holes in it.

  • What do interviewers ask about AI-generated code?

    Four questions, usually in this order. Walk me through this project. Why did you structure it this way rather than the obvious alternative. Where did you use AI and what did you change about what it gave you. Here is a requirement change, how would you approach it. None of them can be answered from memory of the code, which is deliberate. They are cheap to ask, impossible to fake, and they separate someone who made the decisions from someone who accepted them.

  • How can I practise explaining my code before an interview?

    Three drills. Record two minutes explaining the project to a non-developer and listen back for the places you say "basically". Read your own diff before committing and write a commit message that says why rather than what, which forces you to have a reason. Then delete one file and try to rebuild it from memory of the decisions, not the syntax. If you can rebuild the reasoning, you own the code, and the syntax was never the part being tested.

  • Does using AI make my portfolio look worse to employers?

    Only if the portfolio is all you present. Employers assume AI was involved, so a project no longer proves you can build. What proves it is the conversation attached to the project: the write-up explaining your decisions, the demo where you change something live, the answer to "what would break if this got a thousand users". Add that layer and AI-assisted work becomes stronger evidence than hand-typed work was, because you shipped more and can still account for all of it.

Back to all postsJunior interview questions →

Build things you can defend.
Every project ends in a review, not a green tick.

The AI-Native Software Development Programme is 12 weeks of shipping real products with AI in the workflow and a mentor reading every decision you make. The explanation is trained alongside the code, because that is what gets tested.

Apply for the next cohortTry it free first