Cracking the AI Code Interview

I have been thinking a lot about what the engineering interview is supposed to look like now. For a long time, I still believed some kind of coding portion belonged in the interview. Honestly, I think I still do.

Engineers should not let their basic coding skills atrophy. Plenty of companies are going to keep asking people to write code on a whiteboard, in a shared editor, or in some stripped-down environment long after the job itself has changed.

So yes, you should still be able to code.

But I run a smaller agency. I get to decide what matters here. And the more I think about it, the more obvious it becomes that the old interview format is increasingly testing the wrong thing.

We dropped LeetCode-style interviews years ago because they were not especially relevant to the actual work we do. If someone was great at LeetCode but failed every other part of the process, they were not someone we were going to hire anyway.

The job was never really “solve an abstract algorithm problem under artificial pressure.”

The job was: can you understand a messy client problem, ask good questions, make sound technical decisions, communicate clearly, protect the quality of the product, and ship something useful?

AI has only made that more true.

I Expect Engineers to Use AI

At this point, pretending engineers are not going to use AI is absurd.

My customers expect us to use AI. My company expects us to use AI. We are an AI-forward agency. I cannot seriously tell clients that we use the best modern tools to move faster and then design an interview process around pretending those tools do not exist.

The whole hourly billing model is already under pressure. The idea that someone is going to come in, hand-code all day, and compete with what customers now expect is not realistic. The interview should not be built around catching someone without their tools. It should be built around understanding how they use their tools, when they trust them, when they do not, and how they know the difference.

How Do You Experiment?

A friend of mine, Scott Werner, made a point recently that stuck with me: all of these tools are still new. We are all still learning them, even the senior people.

The best engineers I know are still changing their process every few months. They are trying new workflows. They are testing new models. They are figuring out when agents help and when they create chaos. They are learning where AI accelerates the work and where it just gives you a higher-velocity path into a ditch.

So one of the first things I would want to understand in an AI-era engineering interview is not just:

“What is your current process?”

It is:

“How are you evolving your process?”

What are you experimenting with right now? How do you decide whether a new technique is better than the old one? When a new tool or method comes out, how do you evaluate it? What did you try that failed? What did you stop using? What still works?

If someone tried a big agent loop, I want to know how they decided when it was useful. When did it break down? What kinds of tasks was it good for? What kinds of tasks did it make worse?

Not every technique works for every problem. The way I use AI for product development and design is different from how I use it for data migrations. That is different from how I use it to evaluate a codebase. That is different from how I use it for code review. I want to know how an engineer chooses their technique based on the shape of the problem. That, to me, is one of the hallmarks of a good AI-era engineer.

Curiosity, Not Dogma

This was true before AI, but it is even more true now: dogmatic engineers are dangerous.

There is a type of engineer who gets very attached to a method, a stack, a workflow, or a philosophy. Sometimes that can look like discipline. Sometimes it can look like confidence. We have to be open-minded about new methods. We also have to be suspicious of them. Both things have to be true at the same time.

I would be deeply suspicious of someone who told me the only effective way to build software now is to spin up a thousand-agent swarm and let it run wild in some recursive loop until a product appears. I would also be suspicious of someone who said, “I just use GitHub Copilot for tab complete and otherwise nothing has really changed.”

Those are opposite ends of the same problem. One person has confused novelty for wisdom. The other has confused caution for professionalism.

What I want is the person in the middle. Curious, but not gullible. Experimental, but not reckless. Skeptical, but not frozen. Someone who can say, “I tried this. It worked here. It failed there. Here is how I know.”

That is the engineer I want to talk to.

Speed Is Not the Product

Yes, moving fast matters but not at the expense of quality and security. Clients want speed, of course. Everyone wants speed. But the kind of clients we want also care deeply about quality. In the age of vibe coding, plenty of people can build their own stuff fast. When they come to my team, it is usually because they do not know how to get the quality back.

When someone buys premium software, they do not want random bugs, sloppy UX, weird friction, or a product that feels like it was assembled by five interns and a chatbot during a long weekend. They want sharp, pointy tools that work under pressure.

That means another major part of the interview has to be about quality. How do you ensure code quality when the tools let you move faster than ever? How do you review AI-generated code? How do you decide when to slow down? How do you know when speed is becoming the problem?

AI makes you feel productive. It makes the screen move. It makes the branch grow. It makes the diff look impressive. But a bigger diff is not the same as better software. If we want to charge premium rates, we need to produce a level of quality clients cannot get everywhere else. Quality has to be part of the process, not something we try to sprinkle on at the end. So how do you as an engineer ensure quality with these tools?

The Coding Interview Becomes a Problem-Solving Interview

I like real-world, problem-solving interviews. I am less interested in watching someone perform syntax under pressure and much more interested in watching how they think through an unfamiliar domain. I like to pick a problem from a real client situation. Something not quite clear and ideally with a subtle human behavior problem underneath the technical one. Something where there isn’t just one right answer or even a clear answer at all.

Then I want to see what happens.

Do they ask questions? Do they try to understand the business context? Do they jump into solutions too quickly? Do they assume software is always the answer? Do they know how to separate symptoms from causes?

This matters especially in consulting and forward-deployed engineering. We work with nontechnical founders all the time. We also work with technical people who may be skeptical of newer AI-driven workflows or simply behind on what is now possible. So I need engineers who can work with both groups.

Can you explain your process to a nontechnical founder without making them feel stupid? Can you bring a skeptical technical stakeholder along for the ride? Can you show your work in a way that builds trust? This is not soft-skill fluff. This is difficult stuff to cultivate but this is now the job.

Writing Is an Engineering Skill Now

I would also pay a lot more attention to writing.

Can you write clearly? Can you explain the problem? Can you document your assumptions? Can you produce a plan another human can understand? Prompting is fundamentally writing. Specifications are writing. Technical plans are writing. Client updates are writing. Code review is writing. Product thinking is writing. Exceptional technical communication skills have always been important for team communication, but now they are essential to the work itself.

If your written communication is muddy, your AI workflow is probably muddy too.

This does not mean everyone needs to write like a novelist. But clarity matters. Precision matters. The ability to describe what you want, what you tried, what changed, and what you learned matters more than ever. The engineer who can write clearly has leverage. The engineer who cannot is going to struggle in a world where the interface to increasingly powerful tools is language.

The Token Bill Is the New Clock

There is another piece of this that I do not think enough people are talking about: cost. AI has created a strange new version of an old consulting problem. In the hourly world, the bad behavior was milking the clock. Running up the hours. Making a project take longer than it needed to because the billing model rewarded waste.

In the AI world, the new version is token maxing.

There are people and organizations operating as though there are no budget constraints at all. Some venture-backed AI labs can burn enormous amounts of money on tokens because experimentation is the entire point and cash is plentiful. That is not my world. It is not the reality for the vast majority of businesses either.

In a consulting business, especially one serving small and mid-market companies, the token cost matters. The cost of the solution matters. The AI bill matters. The cost of implementation and maintenance matters. If someone is using a $100 or $200 a month coding plan to get better output, great. That is an easy conversation.

If someone is running up an $8,000-a-day token bill on top of their own salary, there had better be a very strong reason. Not vibes. Not “it feels faster.” A real reason. A business reason. A reason that connects to money, quality, speed, or some measurable advantage.

I love engineers who understand ROI. I want to know whether you monitor your usage. I want to know whether you think about cost. I want to know whether you can decide when the expensive tool is worth it and when the cheaper workflow is good enough. Because “no budget” is not a real strategy. It is a fantasy you only get to live inside very specific organizations for very specific windows of time.

Everyone else has to do the math.

Sometimes the Best Code Is No Code

Another part of the interview I would love to include is a problem where writing software is not the right answer. That tells you a lot about a person. Some engineers see every problem as a reason to deploy code. But we are not in the business of selling people work they do not need. We are not here to create software for the sake of creating software.

We are here to be a trusted source.

Sometimes the answer is a process change. Sometimes it is a spreadsheet. Sometimes it is better training. Sometimes it is deleting a feature. Sometimes it is telling the client, “You do not need to build that yet.” That kind of judgment matters more now because AI has challenged the old notion of there’s always too much software to build and too little time and money to do it. Just because something is easier to build does not mean it is worth building.

A good engineer needs to be comfortable saying, “I do not think code is the answer here.” That is not a lack of ambition. That is professionalism. That’s how you build trust, which is really what we sell our customers at every interaction.

The AI-Era Interview Has Two Halves

If I had to summarize the engineering interview I am interested in now, it has two major halves.

The first half is about process.

How are you working through this new experimental phase? What tools are you using? How are you evaluating them? How often are you changing your mind? Where are you skeptical? Where are you excited? How do you protect quality while moving faster?

I expect the answer to be unfinished because this new world is unfinished. We’re all still learning and we should have the humility to say that. Anyone who claims to have this all figured out is probably not paying close enough attention.

The second half is about business sense.

Do you understand the product? Do you understand the customer? Do you understand cost? Do you understand ROI? Can you explain your work? Can you work with nontechnical stakeholders? Can you tell when software is not the solution? Can you make the business better, not just the codebase bigger?

These are not bonus traits anymore.

They are becoming the job.

The AI-era engineer is not just someone who can produce code faster. The AI-era engineer is someone who can decide what should be built, how it should be built, what tools should be used, how much it should cost, how quality will be protected, and how to explain the whole thing to the humans paying for it.

That is the interview I want to run.

Not because coding does not matter.

Because coding alone is no longer enough.