Views expressed here are my own and do not represent those of my employer or any organization I'm affiliated with.
I recently interviewed for a generative AI role and spent 45 minutes working through three LeetCode-style problems. I was explicitly told that it did not matter whether my code compiled, how well it was written, or whether it was efficient as the amount of data grew, which engineers call Big O. The goal was simply to see whether I could solve the algorithms
I left wondering what, exactly, the interview had measured
It tested whether I could recognize an abstract pattern and produce a solution under pressure. Those are real skills. But it revealed almost nothing about how I design systems, evaluate tradeoffs, work with a team, use AI responsibly, or make something customers actually want to use
The generative AI role made that mismatch obvious, but this is not only an AI hiring problem. It is a problem with how we define a good engineer
Three problems test the test
I do not think LeetCode is stupid. One focused problem can establish a useful baseline. It can show whether a candidate can reason through code, choose a sensible data structure, and explain their thinking
Three problems in 45 minutes measure something narrower. Before introductions and questions, that is at most 15 minutes each. The format rewards rapid pattern recognition and familiarity with the test. It leaves little room for testing assumptions, improving the code, or responding to feedback
In my interview, the code did not need to run. Its quality and efficiency did not matter. That removes most of the signals a coding exercise might provide. What remains is the ability to recognize and talk through a particular category of puzzle
LeetCode can still be valuable for early-career candidates who have limited production experience. It also makes sense when algorithmic performance is central to the role. But performance is heavily influenced by preparation. Someone who has practiced a hundred variations can recognize the expected pattern immediately. A strong engineer who spends their time leading migrations or debugging distributed systems may need longer to recall it
That does not make the practiced candidate less capable. It means the interview increasingly measures familiarity with the interview
Senior engineers do not work from blank editors
When I say most senior engineers are no longer writing code "by hand," I do not mean they cannot code. I mean they rarely work the way a coding interview asks them to work: in a blank editor, from memory, without a compiler, documentation, an existing codebase, tests, code review, or increasingly an AI assistant
The people with the most recent practice solving isolated problems this way are often college students, new graduates, and candidates training for interviews. Senior engineers spend more time reading unfamiliar code, reviewing changes, tracing failures across services, negotiating requirements, and deciding what should be built in the first place
They can spot a syntax error, find a broken assumption, explain why a design will fail at scale, and guide the implementation. Recreating a textbook algorithm at speed may feel rough because it is no longer their daily workflow
This is not only my impression. A study of 46,115 practitioner comments found repeated concerns that technical interviews lacked real-world relevance and favored junior candidates who had recently solved homework-style problems. For senior developers, the researchers recommend scenarios resembling the actual work. They even note that recognizing a package-dependency problem as depth-first search may be enough without writing the algorithm
A great engineer is not a human compiler. A great engineer understands how a decision in one part of a system becomes a consequence somewhere else
Taste is an engineering skill
I think taste will take engineers further in this industry than raw code-output speed
By taste, I do not mean liking expensive products or forcing a personal visual style onto everyone else. I mean the judgment to notice friction, understand what a customer is trying to accomplish, and choose the best option among several technically correct ones. Taste is knowing what to include, what to remove, and what deserves another round of refinement
I work with a lot of user experience and interface design. There are people who understand design systems and can produce a technically correct interface, yet still struggle to make something that resonates with customers. The feature works. The components are consistent. Every ticket is closed. Somehow, the product still feels confusing, indifferent, or cheap
That gap matters. Customers do not experience our component architecture. They experience whether the product anticipates their needs, explains itself clearly, recovers gracefully, and makes them feel confident
People clown on Apple all the time, sometimes fairly. But Apple usually understands this better than most. Its own design principles emphasize purpose, familiarity, simplicity, craft, and delight. That is why its best experiences feel comfortable and premium. The effect does not come from decoration added at the end. It comes from hundreds of decisions that make the product coherent
LeetCode cannot reveal much of that judgment. It usually offers one correct destination. Taste becomes visible when several solutions work and the engineer must decide which one will serve people best
AI makes judgment more valuable
AI can generate a routine function, explain a library, produce tests, or suggest an algorithm in seconds. That does not make engineering easy. Generated code can be insecure, subtly wrong, or completely inappropriate for the system around it
What changed is the cost of producing a plausible first draft. Code is becoming cheaper to write. Knowing what should be written, whether it is correct, and whether it will solve the customer’s problem is not becoming cheaper at the same rate
The 2025 Stack Overflow Developer Survey found that 51 percent of professional developers use AI tools daily. Experienced developers were also the most cautious about trusting their accuracy. That combination is the point. Using generated code does not remove engineering judgment. It makes judgment more important
An early 2026 longitudinal preprint found that 82 percent of participants reported spending less time writing code. The researchers describe work shifting from creation toward directing, evaluating, and correcting AI output. This is self-reported evidence, not a final verdict on the profession, but it reflects what many engineers are already experiencing
Two signals that software work is changing
These are separate self-reported measures from the 2025 Stack Overflow Developer Survey and a 2026 longitudinal preprint. Their samples and questions differ, so each bar should be read as its own signal rather than a direct comparison.
View chart data
| Measure | Share of respondents (%) |
|---|---|
| Daily AI use | 51 |
| Less time coding | 82 |
For a generative AI role, I would rather learn whether a candidate can identify a weak model response, design an evaluation, control cost and latency, protect sensitive data, and plan for failure. Asking for a memorized tree traversal does not tell me that
Interview the work
Theo@theoon X, opens in a new tab puts the principle well
“The goal of the interview is to set the interviewee up for success.”
His proposed process lets candidates choose an algorithm problem, a realistic task in the relevant technology, or a paired session on an actual project
Prime@ThePrimeagenon X, opens in a new tab is similarly pragmatic
“I don’t think coding interviews are the best way to validate a candidate’s ability.”
He still calls basic data structures the industry’s “secret handshake,” but argues that hiring should combine relevant technical questions with live work and collaboration
That is a better model. Give a candidate a small, imperfect system and ask them to improve it. Let them clarify requirements, inspect existing code, use documentation, and explain their choices. Introduce a failure or a new constraint and see whether they adapt
For an AI-focused role, let them use AI. The goal should not be watching a chatbot solve the same old question. Ask the candidate to design the workflow around it:
- isolate changes with worktrees;
- provide reusable instructions and skills;
- connect approved tools and data through Model Context Protocol (MCP);
- build review, test, and retry loops;
- define benchmarks and evaluations; and
- set permissions and human escalation for risky actions
A non-technical interviewer does not need to know every term. The larger point is that useful AI is a system, not a clever prompt. The interview should reveal whether the candidate can make that system dependable
The same principle applies beyond AI. Give a senior engineer a realistic problem with more than one defensible answer. Ask what they would build, what they would deliberately leave out, where it could fail, and how the experience should feel to the customer. That reveals coding ability, systems judgment, communication, and taste in one conversation
Keep one coding problem
I am not arguing for easier interviews or the death of coding questions. For an experienced engineering role, one relevant problem is reasonable. It confirms that the candidate can reason about code without turning the entire process into a test of interview preparation
The rest of the interview should examine the skills that separate someone who can produce a function from someone who can build the right product. A new graduate, an application engineer, a distributed-systems specialist, and an AI platform lead should not all face the same process because algorithm questions are easy to standardize
One coding problem can show that I know how to code. Three in 45 minutes mostly show how well I prepared to solve three coding problems in 45 minutes
That is not enough to find a great engineer. Great engineers understand messy problems, direct people and tools toward sound solutions, make products feel considered, and take responsibility for what happens in the real world