AI is shifting software engineer hiring criteria from production to verification. Companies now screen for code review judgment, specification clarity, and debugging under unfamiliar conditions rather than typing speed or algorithm recall. Interview formats are being rebuilt at major employers to match.
The clearest evidence is not in survey data. It is in what large engineering organisations have actually changed about their interview loops in the past 18 months, and why.
Companies do not rewrite hiring processes casually. When several rebuild the same stage in the same direction within a year, the underlying job has changed. Rise92 tracks these shifts while sourcing for global engineering teams.
What changed in the work itself
One dataset illustrates the shift better than any general claim.
Coinbase published figures in July 2026 showing AI-generated code at 5.7% of everything merged into its codebase in the first quarter of 2025. By the fourth quarter of that year, it had passed 50%. Human engineers still reviewed all of it, essentially.
What that does to the job: Engineers spend less time writing code from scratch and more time authoring specifications, directing tools, reviewing generated pull requests, and catching architectural mistakes that arrive looking confident and correct. As the cost of building falls, deciding what to build and validating it become the constraints.
The trajectory: Gartner projects that 75% of enterprise software engineers will use AI coding assistants by 2028.
What this does not mean: It is not a story about fewer engineers. It is a story about a different distribution of engineering time, which changes what makes someone good at the job and therefore what employers screen for.
The assessment problem this created
Hiring processes did not update alongside the work, and the gap is now measurable.
A Karat survey of 400 engineering leaders across the US, India, and China found 71% saying AI has made it harder to assess technical skills. Karat’s leadership puts the prior figure in the 20% to 30% range, so the jump happened in roughly two years.
The diagnosis worth noting: The common assumption is that this is a cheating problem. Karat’s position is that it is not. The fundamental job changed while technical interviews stayed the same, which means interviewers need retraining and questions need rewriting.
The cheating problem is real too, but secondary. Reported figures put around 38.5% of interviews flagged for suspected AI use, and Google has moved some rounds back in person in response.
Why the distinction matters: A company that treats this purely as cheating responds with proctoring and returns to algorithm puzzles. A company that treats it as an assessment design problem rebuilds what it measures. Only the second approach produces better hires.
Five shifts in software engineer hiring criteria
| Previously screened for | Now screened for |
| Can produce a working solution quickly | Can identify what is wrong with a plausible one |
| Framework and stack familiarity | Transferable reasoning across unfamiliar code |
| Algorithm recall under time pressure | Architectural judgment and tradeoff reasoning |
| Years of experience and credentials | Specific production failures owned and fixed |
| Individual output volume | Specification clarity and written communication |
The single sentence version: The value moved from producing code to deciding what should exist and verifying what was produced.
The corollary most teams have not absorbed: Every screening mechanism calibrated to the left column now selects against the right one. An algorithm-heavy loop actively favours recent graduates who have drilled the format over senior engineers who have been running production systems.
The interview is being rebuilt, publicly
This is the concrete part. Several large employers have changed format explicitly, and their reasoning is documented.
| Company | Change | What it evaluates |
| Canva | Expects candidates to use Copilot, Cursor, or Claude in technical interviews, announced June 2025 | Prompting quality, code review, debugging, explanation |
| Meta | Added an AI-enabled coding round to the onsite loop, October 2025, for mid-level and senior roles, expanding through 2026 | Using AI to write, review, and debug, plus explaining trade-offs in what it produced |
| Shopify | AI tools incorporated directly into the interview process | Realistic task performance |
| Rippling | Permits AI use in technical assessment | Practical working method |
Canva’s stated reason was simply that the way they work has changed, and their interviews should reflect that.
Meta’s design is the more instructive one. The AI-enabled round is paired with at least one traditional AI-free session, so the loop measures both. The format uses multi-file projects requiring integration and debugging rather than isolated algorithmic problems, and the tools may introduce subtle errors that the person is expected to catch. Meta calls this critical verification. Producing the right output is not sufficient, because interviewers probe the reasoning behind implementation choices.
The scale of adoption: IEEE-USA reports slightly more than 25% of employers now permit AI use in technical interviews, with expectations that this reaches 50%.
Why the ban position became untenable: companies that ship products built on AI, and whose engineers use these tools daily, were asking people to demonstrate ability in a simulation that did not resemble the work. That is a validity problem, not a fairness problem.
What engineering job descriptions now say
The change is visible in postings before it is visible in process.
What is being added:
- Experience with AI-assisted development workflows, framed as context rather than as a qualification
- Explicit emphasis on code review and verification responsibilities
- Written communication and specification authoring as stated requirements
- Systems and architecture reasoning at levels where it was previously implied
What is being removed or downgraded:
- Exhaustive framework lists, which were always weak signals and now filter out transferable capability
- Years-of-experience thresholds, as skills-based criteria displace title-based ones
- Narrow stack requirements, since a strong engineer becomes productive in a new framework within weeks
The structural shift underneath: hiring is moving from job-title-based to skills-based. An engineer who works effectively with AI tooling is evaluated differently from one who relies entirely on traditional workflows, and that difference is now stated rather than assumed.
A practical warning about the other side of this. AI-generated applications have made surface-level screening substantially less reliable. Resumes are increasingly optimised by the same tooling used to evaluate them, which means human judgment at the assessment stage matters more, not less. Companies that respond by adding more automated screening are moving in the wrong direction.
The entry-level problem nobody has solved
This is the most consequential change and the least addressed.
What happened: much of the routine work that junior engineers used to do has been automated, and competition for entry-level engineering roles has intensified accordingly. The expectation has also risen, with juniors now expected to produce output comparable to a mid-level engineer from several years ago because of what the tooling enables.
The finding that should worry hiring leaders: PwC’s 2026 research indicates that AI-exposed entry-level roles are seven times more likely to require traditionally senior skills such as judgement and leadership.
The compounding risk: senior judgment has historically been built through years of supervised practice on exactly the work that has been automated. If entry-level engineering roles no longer provide that practice, and fewer juniors are hired in the first place, the pipeline producing senior engineers weakens while demand for senior judgment rises.
What companies doing this well are doing:
- Continuing to hire juniors deliberately rather than defaulting to senior-only
- Asking juniors to explain generated solutions rather than accept them
- Requiring periods of work without assistance to build foundational understanding
- Treating mentorship capacity as a hiring criterion for senior roles
The honest position: nobody has solved this. Companies that keep developing juniors will have a scarce resource in five years, but that is a bet with a long payback and most organisations will not make it.
What this means for how you screen
Practical adjustments, in order of impact.
Rewrite the questions before retraining the interviewers. Both are needed, and the sequence matters because interviewer training against outdated questions entrenches the problem.
Decide your AI position explicitly and state it. Three defensible options:
| Position | Suits |
| AI-enabled round plus one AI-free round | Most companies, mirrors Meta’s approach |
| AI expected throughout, scored on usage quality | Companies whose work is fully AI-assisted |
| AI-free, in person | Roles where unassisted depth genuinely matters |
Whatever you choose, tell people in advance. Ambiguity produces inconsistent conditions across the same loop, which destroys comparability.
Use multi-file, integration-heavy problems rather than isolated algorithmic ones, because the failures that survive into production now come from components interacting wrongly rather than from any single function.
Introduce plausible errors deliberately and score whether they are caught. This is the closest available proxy for the verification judgment that now defines the role.
Score explanation, not just output. If someone cannot articulate why the implementation is correct, they cannot review anyone else’s work, which is now most of the job.
The access point worth naming: engineers with strong verification judgment are employed, well compensated, and not applying anywhere, which makes reach the binding constraint once your process is sound. That is the case for off-market sourcing through closed networks rather than broader advertising.
What this costs
The premium for AI-relevant capability is measurable and rising. PwC’s 2026 AI Jobs Barometer puts the wage premium for AI skills within the same occupation at 62%, up from 57% the previous year. Lightcast’s methodology produces a more conservative 28%, roughly $18,000 annually, rising to 43% where two or more AI skills are present.
The average conceals wide sector variation, ranging from around 118% in consumer markets to 16% in government and public sector, so treat the headline figure carefully.
Two budgeting implications:
First, the premium attaches to demonstrated application rather than familiarity. Paying it for someone who has used the tools without shipping and maintaining anything buys nothing.
Second, these capabilities are distributed globally rather than concentrated in high-cost markets, which changes team composition economics if the sourcing reaches genuine senior depth and the employment structure is compliant. The comparison sits in transparent pricing.
Frequently asked questions
Verification judgment first, meaning the ability to identify what is wrong with plausible-looking code, followed by architectural reasoning and specification clarity. Production speed has declined in relative value because tooling handles more of it. Screen for whether someone can find the error, explain the tradeoff, and write a specification that would fail a wrong implementation.
Slightly more than a quarter of employers now permit it, with expectations of reaching half, and the reasoning is validity rather than generosity. If engineers use these tools daily on the job, an AI-free interview measures a scenario that does not occur at work. The strongest current design pairs one AI-enabled round with one traditional round and states the rules in advance.
Reframe the problem, because roughly 38.5% of interviews being flagged suggests detection is not scaling. Assessment that permits the tooling and scores the reasoning behind choices is harder to game than assessment that forbids it, since explanation cannot be outsourced convincingly. Some companies have returned to in-person rounds for specific stages, which works but costs speed.
Emphasise code review and verification responsibilities, written communication and specification authoring, and architectural reasoning. Reduce exhaustive framework lists and years-of-experience thresholds, both of which filter out transferable capability. Treat AI-assisted development experience as useful context rather than as the qualification itself.
What to take from this
The choice is narrower than the marketing suggests. Establish whether the person is an employee or a genuine contractor, establish whether you own a local entity, and five of the six options usually eliminate themselves.
Then model total cost per country rather than comparing provider fees, because statutory variation dwarfs fee variation.
And keep the sourcing decision separate from the employment decision, because conflating them is how companies end up paying an ongoing percentage for something a one-time arrangement would have covered.
To work through which structure fits your situation, get in touch.
The short version
The job changed faster than the hiring process, and the gap is now wide enough that 71% of engineering leaders report difficulty assessing technical skill at all.
The companies responding well have done two things: permitted the tooling that engineers actually use, and moved what they measure from output to reasoning. The companies responding badly have added proctoring and kept measuring a version of the job that no longer exists.
The underlying criterion is simple to state and hard to test: can this person tell whether something is right when a confident machine says it is.
If your process measures that and you still cannot hire, the constraint is access rather than assessment. To work through which one you are facing, get in touch.
