I bombed my AI Interview
A retrospective on how to take an AI Engineering Code Interview
I failed an AI engineering coding interview ten times so you don’t have to.
One hour. One app. The spec was clear. No database. Keep the data in memory. Tests were not mentioned.
The interviewer handed me the one crate I was meant to deliver.
They were the feature specs.
Light.
The ship could have crossed in fifteen minutes.
I asked a couple of questions:
The interviewer replied:
I glanced through the spec, and some part of me decided the easy version was beneath me.
This is an AI Engineering position.
I should stand myself out from vibe-coding...
Right?
So I poured a real foundation. A proper database underneath. The kind that survives a real team. This was a full stack position, I should show I know databases right?
I made the AI talk it through with me first, the way I’d brief a junior engineer. Just a few questions. I want things done “right” on the first pass. Like how I would have documented implementation well enough that there’d be fewer surprises by the time my junior engineer had a PR ready.
I built it the way I’d want it reviewed, showing that quality matters to me.
Test-driven-development is the way to go...
Right?
As I prompted back and forth with AI, I spoke out loud what I was thinking and why I did the things I did.
Fifteen minutes in, I had not written a single feature. But I had set all my expectations clearly with AI.
It is now time to set sail.
Forty minutes in, I’m starting to reevaluate the loaded crates nobody asked for.
The interviewer and I had our arms crossed, staring at the token usage.
We broke the silence with small talk as AI would occasionally disrupt my flow.
Interviewer: “So… can you explain why you did this and that?”
Me: “Yes, because of these best practices and—”
AI: “WE FINISHED GENERATING A SPEC.MD WOULD YOU LIKE TO PROCEED?”
Me: “Oh… you didn’t begin implementation yet... Yes, proceed now”
Me: “As I was saying, typically I would have—”
AI: “WE FINISHED GENERATING A PLAN.MD WOULD YOU LIKE TO PROCEED?”
Me: “Yes… IMPLEMENT already!”
When the hour ended, the ship dragged across the line half-sunk. I did not need them to tell me how it went. In the hour, I showed them how I do Q&A with AI, how it generates a spec, makes a plan, and implements the work. Besides that, there were awkward silences as we both prayed for the code to be completed.
The code was finally generated and ready to run, but our time was up. The interviewer had to jump to another meeting. Alone, I ran the project and it met the specs. The application even matched the UI mockup from the spec. A silent win for me, but no more time to show it.
My Rumination
I let the craftsman side of me take over. This is nothing new when it comes to a live coding test. Even pre-AI, a mistake any engineer can make is to scope-creep themselves.
“JUST GET IT DONE!”
If I were to do it over, I would have done it like this cool engineer.
Interviewer: Here are the specs.
Cool engineer: Cool, got it. I’ll do the thing…
15 minutes later, a working piece of code would have existed. Now here comes some standard dialog.
There could have been follow up discussions on best practices and time to iteratively improve things.
Crate Inspection
This was my first AI coding session, and I started to obsess over the failure. I then retook the test 9 more times with different approaches. I lied, it was 10. The tenth happened while I was writing this. With no interviewer in the room anymore, I’m going to compete against myself through several time trials.
The same build that ate the full hour the first time came in around fifteen minutes once I stopped loading crates. Here’s what each one was costing me.
“Feature Spec” Crate
Back in the good old days, I treated a product spec like a “version 10,” the full vision. I’d break it down into smaller, iterative deliverables. Splitting the work was the job. So in the interview, out of habit, I fed the AI the spec in pieces.
That’s the reflex AI breaks. It works better when it sees the whole picture at once, and hand-cutting the spec myself just reintroduced the one risk AI removes: me missing a detail. I was doing manual labor to make the tool dumber.
"Breaking the spec into pieces used to be my job.
Now it just keeps the AI from seeing the whole thing."
“Deep Q&A with the AI” Crate
In real AI-native work, I lean on a planning phase. I’ll have the AI break the task down, sometimes hand each piece to a separate agent. It’s a habit that pays off on a real codebase.
In a timed interview, it’s a tax. The spec is small enough to split in my head, and instead I spent roughly ten minutes answering the AI’s questions about a problem that was never that complicated. If you’ve picked up brainstorming “skills” from YouTube, the kind that walk you through a long Q&A, that overhead is the last thing you want eating your hour. Worse, some of those skills are built to generate a spec and a plan for you. It’s a pure waste of time when the interview already handed you specs and the planning should be simple enough to hold in your head.
“Planning deeply is an investment on a real codebase
and a tax in a one-hour test.”
“Production-Ready Habits” Crate
This was the heaviest crate I loaded, and I loaded it on purpose. As a craftsman, I wanted to showcase it all. I didn’t want to come across as “just” a vibe coder. So I got in my head about what counts as real engineering in the AI era, and I started adding.
First was the database. The test asked for a full-stack app with the given features. It did not ask for a real database with migrations, but I added one anyway to show I know my “production-things.”
“Erhh wrong”…
It’s a freakin one-hour interview, not a product. Here’s what I missed in the moment: AI doing the work for you doesn’t make the work free.
”The more infrastructure you prompt,
the more AI tasks you have to wait on”
Every extra piece is another thing AI has to plan and another thing you sit and wait on, while the token count climbs and you make small talk. Meanwhile, saying “in production I’d add a database and migrations” would have cost zero minutes.
I also brought templates. A week before the interview I built full-stack GitHub templates, another “production-ready” habit I was proud of. When I retook the test, I finally used them to see if they’d save time. They didn’t. The template was bloated for a simple test, so AI burned 5 to 9 minutes reading infrastructure I didn’t need.
The last one was Data Contracts. I wired the backend to drive the frontend types, OpenAPI plus codegen, because I like true backend and frontend alignment. The catch: it makes the frontend depend on the backend existing first. The moment I wanted agents building both in parallel, my own pattern got in the way.
”Production habits are for code that has to live.
Interview code is built to be thrown away.”
“TDD” Crate
As a craftsman, I care about quality. Test-driven development is the right way to enforce quality with AI. Write the tests first and you force the model to meet the use cases. Let it write tests afterward and it tends to hand you tests that pass for the sake of passing. I believed that then and I still believe it now.
So I had a TDD skill running on almost every task. It worked. It also quietly ate my clock, one red-green-refactor loop at a time. And nobody asked for it. Tests were not in the spec. I added them because skipping them felt like admitting I was “just” vibe coding.
If I did this over, I’d skip unit tests, get the product working first, and only then, if time was left, add a single e2e test. An interviewer remembers a working app with one test that proves the whole flow, not a pile of unit tests around an app that never finished.
“Testing isn’t the thing I’d cut on a real project.
It’s the first thing I’d cut on a timed one.”
Closure
I retried my test 10 times because I wanted closure on why I failed. What I found is that I didn’t fail because I cared about craft. I failed because I tried to deliver it at the same moment I was supposed to be delivering speed. I once wrote about my fear that AI would make me obsolete, that fifteen years of mastery could be automated overnight. That anxiety is what made me hold so tightly to my craft, and it was the craft that sank my ship.
A one-hour interview is a short trip across the harbor. You pack light, you ship the working thing, and you make it across. The crates I loaded weren’t bad engineering. They were the wrong load for a fifteen-minute trip. The product earns you the conversation. There’s nothing to discuss until there’s something to see. When the interviewer told me he wanted to see both, he was right. I just had the order backwards. Get the ship moving first, then load the craft crates as you go.
I don’t know when the next call comes. When it does, I’m packing lighter.
There’s no such thing as the right load. Only the right load for the trip.
