AI was supposed to make technical interviews easy.
You get a question, prompt the AI, and use its answer. Give it an entire take-home assignment and a few days, and surely you're in an even better position.
A candidate was given exactly that opportunity: build an application, use any AI tool of their choice, and return the solution in five days.
They still failed the interview.
The problem was their technical foundation. They didn't understand what a good application should look like well enough to guide the AI toward building one.
A working application can still be a poor submission
Getting an application to run is a satisfying moment. You enter some data, click a button, and get the result you expected.
But an engineering assessment can ask much more of the work. Can someone else understand the code? Can a feature be changed without breaking unrelated behaviour? Does the application handle errors properly? What happens as the workload grows?
Scalability, maintainability, clean code, and sensible engineering practices all matter. An application can appear to work while being weak in every one of those areas.
AI makes it easier to reach the point where something runs. Knowing whether the application is well built still takes engineering judgement.
You have to know what to ask for
"Build the application and make sure it works" leaves an enormous amount unspecified.
How should the code be organised? Which responsibilities belong together? What needs validation? Which operations might become slow? What should be tested beyond the example in the task?
If you've built and maintained applications before, those questions come more naturally. You've had to change tightly coupled code. You've investigated a slow request. You've dealt with an error that the original implementation never considered.
That experience shapes your prompts. You can ask the AI to separate responsibilities, examine a bottleneck, or test a particular failure because you recognise the issue in the first place.
If you've never done that work, you probably won't know to ask. And when the AI gives you a polished-looking answer, you may have no reason to question it.
"Follow best practices" doesn't fill the gap
You can add "scalable," "maintainable," and "clean code" to a prompt. The AI will give you something it describes using those words.
You still have to judge the result.
More files don't automatically mean better organisation. More abstractions don't automatically make an application easier to change. Adding a queue or a cache doesn't automatically solve a scaling problem.
Good engineering includes knowing which of those choices the application needs and which ones add unnecessary complexity. Without that foundation, it's easy to accept a complicated implementation and assume the complexity means quality.
Five days gives you time to generate more code. It doesn't give you years of experience recognising these problems.
The foundation still matters
If you haven't built an application yourself before, you probably won't know how to prompt AI to build it well. You also won't reliably know when its answer falls short.
Build things. Read the code. Change the requirements. Trace failures and understand why a fix works. That is how you develop the judgement to direct an assistant and review what it produces.
When you practise an AI-assisted interview, hold yourself to that standard. Get the application working, then examine whether you understand how the code works and could maintain it yourself.
The candidate had five days and access to any AI they wanted. What they were missing was the engineering foundation to use that advantage well.
Comments