How To Hire Engineers When AI Makes Everyone’s Code Look Good

Three years ago, there was a limit to how much harm a weak engineer could cause. It depended on how fast he could type, how much code he could produce in a day, and how confident he felt pushing it. Bad decisions shipped at human speed, and that gave reviewers and tests a chance to catch them.

That limit is gone. Every engineer now has tools that turn ideas into convincing code in minutes.

At Remgu, we vet senior engineers across Europe and Latin America and place them with US companies. This shift has changed how we screen.

The industry mostly describes AI as a productivity gain that makes everyone faster. In practice, it is a multiplier. A skilled engineer with these tools produces more value, but a weak one can cause far more damage than before.

All the engineers at a company have access to the same model. What comes out of it is not the same. A strong engineer steers it toward what matters and ignores what doesn’t. A weak one doesn’t know which parts to trust. But both outputs arrive with the same finish: idiomatic, well-commented, confident, tests passing.

That is the problem for hiring. The difference between an engineer who directs the tools and one who just accepts their output is real, but you can’t see it in the code they hand you. Take-home projects and portfolio repositories don’t tell you what they used to. Anyone can produce something polished.

The question is no longer just whether someone can get something working. AI can help with that. The question is whether the engineer understands why it works, why he built it that way, and why that was the best option among the ones he considered. An engineer who understands the why can explain his trade-offs and recognize the moment a solution stops being right because the requirements changed.

In practice it looks like this. Ask AI for almost anything and it comes back with edge cases and suggestions: there is no rate limiting, the security policy doesn’t cover this case, this should probably be async. A weak engineer who doesn’t understand the context can’t tell which of those matter, and no task description can specify all of it. So he escalates them, to the project manager, sometimes to the client. Because the AI generated them, they look serious and convincing. Non-technical people can’t easily judge them, and the project slows down. A strong engineer looks at the same list and knows: this is an internal API used by a small team, it doesn’t need rate limiting; this service isn’t exposed outside the organization, this level of security is enough. Those decisions are the judgment that matters, and they get made dozens of times a day.

Many of the engineers we place say they haven’t written code by hand in months. Their attention goes to the specification, the implementation plan, and the tests that verify the work. The code itself gets a faster review, mostly for signs that the output is degrading. That is not carelessness. It is judgment moving upstream, to where it has more leverage. It only works because the judgment is sound. The same workflow in the hands of someone who doesn’t understand the system produces a confident, well-tested implementation of the wrong thing.

Deep technical knowledge matters more now, not less, because nobody can fix what they don’t understand. “This will melt under our load pattern.” “This query does a full scan as soon as the table grows.” “This retry logic will double-charge someone.” Every one of those observations depends on someone who understands the why.

A vetting process can fail in two ways. The first is letting an unqualified engineer through. That is the one everyone tries to prevent, usually by adding more steps. The second is quieter but just as costly: losing a strong engineer who won’t sit through five coding tests to prove what he already knows.

So the goal is more useful information in less time. We keep the conversations few and focused. The screeners also say the quiet part out loud at the start: no tricks, the coding isn’t the point, we want to see how you think.

Candidates write code without AI, but the solution is just the starting point. The screener takes it and starts changing things. Remove a safeguard. Introduce a subtle misuse. Add a call that shouldn’t be there. What’s wrong now? Then constraints get added until the design has to change. The questions that reveal the most often have a tempting wrong answer, or a safer option that doesn’t work everywhere, so the candidate has to explain why you wouldn’t always use it.

Another way is to ask the candidate to explain the most complex project he has worked on as if you know nothing about it. If he can walk you through the problem, the important details, and the solution, he has the whole picture in his head. Most people who only executed tickets can’t.

Underneath all of it is one question, asked a dozen different ways: why? Why this approach over the alternatives? What trade-offs did you consider? What is actually happening under the hood? What would you change with more time? Anyone can get something working now. What matters is whether they would recognize it if it wasn’t right.

The tools aren’t going away, and they shouldn’t. Every engineer we place uses them daily; refusing the tools is as disqualifying as misusing them. Screening will keep changing as writing code becomes a smaller part of the job. Deciding what belongs in the system, and how to verify it works, won’t. The hiring question has changed. It is no longer “can this engineer produce code?” It is “can this engineer tell a good solution from a bad one, and explain why?” That is the part worth identifying, and scenario questions are one way to find it.