How do you identify a good software engineer when the person sitting across from you can use AI to produce working code in minutes? That question has become considerably harder for employers, but not because software engineering suddenly became impossible to assess. The problem is that some of the signals companies used to rely on are becoming less useful.
A candidate can arrive with a polished GitHub profile, a long list of technologies and a coding assessment that looks impressive. They can also use an AI assistant to help produce an answer during the assessment. Meanwhile, somebody with less impressive-looking credentials may have spent years maintaining a difficult production system, investigating bugs nobody else could reproduce and making decisions that kept the software running when things went wrong.
Those two candidates can look surprisingly similar on paper.
The hiring manager therefore has to look somewhere else.
The 2025 Stack Overflow Developer Survey, based on more than 49,000 respondents across 177 countries, found that 84% of developers use or plan to use AI tools in their development process, while 46% distrust the accuracy of AI output. Among experienced developers, trust is particularly low.
That tells employers something important. Knowing how to write code still matters, but knowing how to judge code matters more than it used to.
A Good Software Engineer Is Not the Same as a Fast Coder
A developer can produce a solution quickly and still make a terrible engineering decision.
Perhaps the code works, but it creates unnecessary complexity. Perhaps it solves today’s problem while making the next six months of development harder. Maybe the candidate chooses a technology because it is familiar rather than because it fits the problem.
Those decisions rarely show up in a timed coding challenge.
Software engineering involves making choices with incomplete information. The engineer has to understand what the product needs, what the existing system can support, what the team can maintain and what risks the company is willing to accept.
That is why speed should not become the main measure of technical ability.
A strong engineer may actually spend more time asking questions before writing anything.
What is the expected traffic? What happens when the service fails? Who uses this feature? What data does it handle? Does the existing architecture already solve part of the problem?
Those questions can feel slower at the beginning.
They can save weeks later.
Look at the Problems They Have Already Solved
One of the better ways to evaluate an engineer is to move the conversation away from technologies and towards decisions.
Instead of asking whether someone knows Kubernetes, ask them about a system they had to keep reliable.
Instead of asking whether they know PostgreSQL, ask about a database problem they had to diagnose.
Instead of asking whether they know React, ask about a frontend decision that became difficult six months after implementation.
The technology is still relevant, but the story behind it tells you much more.
A useful candidate should be able to explain what the original problem was, what options they considered, why they chose one approach and what happened afterwards. They should also be comfortable admitting that something did not work.
That last part matters.
Real engineering contains failed approaches, unexpected behaviour, technical debt and compromises. A candidate who describes every project as a clean success story may simply have learned how to interview well.
The Best Engineers Know What They Don’t Know
Software changes too quickly for anyone to know everything.
Stack Overflow’s 2025 survey found that 69% of developers had spent time during the previous year learning new coding techniques or a new programming language, while more than 36% had learned AI-enabled tools for work or career development.
That tells us something useful about seniority.
A good engineer is not necessarily the person who knows the largest number of frameworks. It may be the person who can enter an unfamiliar codebase, understand the important parts quickly, identify what they do not know and work out how to close the gap.
During an interview, give candidates something unfamiliar.
It could be a small piece of code written in a language they do not normally use. Ask them to explain what they think it does and where they would investigate first if it started producing the wrong result.
You are not really testing whether they know the language.
You are watching how they reason when the answer is not immediately available.
AI Makes This Test Even More Important
AI has made it easier to generate code.
It has not made generated code automatically correct.
The 2025 Stack Overflow survey found that 66% of developers’ biggest frustration with AI was receiving solutions that were almost right but not quite, while 45% said debugging AI-generated code can take more time.
That creates a useful distinction between a developer who uses AI and one who depends on it.
A strong engineer can ask an AI tool to generate a solution, inspect what it produced, test the assumptions and recognise when the result does not belong in production.
A weaker engineer may simply see working-looking code and assume the problem is solved.
This is why employers should not treat AI use as a red flag during technical recruitment. It is becoming part of normal development work. The more useful test is whether the candidate can verify what the tool produces.
Give them an AI-generated solution with a subtle problem in it.
Ask what they would check before approving it.
The answer can tell you far more than whether they can produce another function from scratch.
Ask What Happened in Production
A coding challenge tells you what someone can do in a controlled environment.
Production tells you what happens when the environment stops being controlled.
Ask candidates about a production incident they were involved in. What broke? How did they find it? What did they check first? How did they know they had fixed the problem? What did the team change afterwards?
The strongest answers usually contain details that are difficult to manufacture.
Perhaps a monitoring alert was misleading. Maybe a database query behaved differently at scale. A deployment introduced an unexpected dependency. A seemingly minor change caused a much larger problem.
These experiences matter because good engineering is partly about dealing with consequences.
A developer who has only worked on isolated features may write excellent code. An engineer who has had to support that code at two in the morning develops a different understanding of what “good” means.
Also read: Why Romania Leads IT Recruitment in Europe
Architecture Questions Reveal How People Think
Senior engineers should be able to explain more than individual pieces of code.
Give them a problem that resembles the work they would actually do.
A company needs to build an API that will serve millions of requests. A product needs to process large amounts of data. A service needs to remain available when one component fails.
Then listen.
Do they immediately jump to a favourite technology?
Or do they start asking about requirements?
Good architecture depends on constraints. Traffic, latency, cost, reliability, security, data consistency and team capability all influence the decision.
There is rarely one universally correct architecture.
That is why an interview answer that contains a long list of technologies can be less impressive than a candidate who spends five minutes establishing what the system actually needs.
Communication Is Part of the Engineering Job
Software engineers do not work alone.
They explain technical decisions to product managers. They negotiate trade-offs with designers. They review other engineers’ code. They sometimes have to tell management that a requested deadline carries technical risks.
Stack Overflow’s 2025 survey ranked autonomy and trust to manage one’s own tasks as the most important factor in developer job satisfaction, followed by competitive pay and benefits and solving real-world problems. Collaboration and team support also ranked among the factors developers considered important.
That matters for employers because the strongest engineer in the world will struggle inside a team where nobody can communicate effectively.
Ask candidates to explain a technical decision to someone without a technical background.
If they cannot simplify the explanation without becoming vague, that tells you something.
The goal is not to turn engineers into salespeople.
It is to find people who can make complicated decisions understandable to the people who have to work with them.
Also read: Where Can Companies Find Production Workers in Europe?
Don’t Confuse Seniority With Years of Experience
Someone with ten years of experience has not necessarily accumulated ten years of engineering growth.
They may have spent most of that period doing the same type of work in the same environment.
Another engineer may have six years of experience across several products, architectures and increasingly complex responsibilities.
The better question is what changed during those years.
Did the engineer take ownership of larger systems? Did they start making architectural decisions? Did they mentor others? Did they become responsible for reliability or security? Did they learn from failures?
A CV that says “Senior Software Engineer — 8 years” does not answer those questions.
The interview should.
Final Thoughts
A good software engineer should be able to write code, but that is only the entry point.
They should understand the problem before choosing the solution. They should know how to work inside an existing system rather than assuming everything needs to be rebuilt. They should recognise trade-offs and explain them. They should be comfortable investigating unfamiliar problems, learning new technologies and challenging their own assumptions.
They should also know when their solution is not good enough.
That becomes particularly important as AI takes over more of the mechanical parts of software development. The European Commission’s 2026 State of the Digital Decade report says 46.7% of EU enterprises were using cloud computing in 2026, 39.9% used data analytics and nearly 20% deployed AI, with AI adoption having increased sharply in 2025. At the same time, ICT specialists represented only 5% of EU employment in 2025, half of the EU’s 2030 target of 10%.
Companies therefore need engineers who can do more than produce code.
They need people who can turn business requirements into sound technical decisions, work with increasingly automated development tools and still take responsibility for the result.
That is the part a coding test cannot fully measure.
The better recruitment process is not about making the technical assessment harder. It is about making it more representative of the work.
Look at how the candidate thinks. Look at what they have built. Ask what went wrong. Give them unfamiliar problems. Test whether they can challenge an AI-generated answer instead of accepting it. Find out how they communicate decisions to the rest of the team.
The code matters. But the engineer behind the code matters more.
