Blog
Interviewing

Fewer coders, more builders

AS
Anton Shkel
October 13, 2026
5
min read

In early 2024, a study had experienced engineers complete technical interviews while secretly using ChatGPT for every answer. On questions taken straight from LeetCode, they passed 73% of the time, and not one interviewer flagged them[1]. By 2025, 81% of big-tech interviewers said they had suspected a candidate of using AI during an interview, and almost a third had caught one[2]. Models have gotten much faster and better since then.

Cheating is the visible problem. The bigger problem is that a coding round tests a skill that matters less every month. In 2026, more than 80% of developers said they use AI tools, and most of those using coding assistants use them every day[3]. The job is now mostly reading, steering and fixing code. Yet the standard interview still asks questions an AI tool can solve in seconds[4].

What the job is now

Writing code was never the hard part of software engineering. Deciding what to build and how was. Someone has to pick the architecture, decide which tradeoff the business can live with, and set up systems that keep working when nobody's watching, usually under time pressure and with half the information. That has always been the work of tech leads and engineering managers. Now that the code underneath is cheap, it's the work of every engineer, including the ones fresh out of school.

The hiring data already reflects this. Across about 100,000 companies in 41 countries, the ones that adopted AI grew their senior headcount by 6.7%, while juniors became a smaller part of their workforce[5]. In the US, employment for 22 to 25 year olds in the jobs most exposed to AI is 19% below where it would have been, and experienced workers in the same jobs show no drop. It isn't layoffs. Companies are just hiring fewer juniors[6]. The explanation is that AI can do what's in a textbook, but not what you only learn by doing the work.

For new grads, that doesn't mean that it's impossible to get a job without experience. But it does mean that what gets you hired is evidence of judgment and agency. I've worked with two kinds of entry-level engineers. The first kind uses AI to deliver work at more than 2x the speed and quality of the juniors who came before them. They take ownership of their code and hold it to a bar they'd be proud of. The second kind offloads their thinking to the model and leaves the real work to whoever has to review their PRs. I'd expect the second kind to have a hard time in this job market, but the first kind is in high demand.

To be the first kind, ship a few complete things that real people use. Write a one-page design doc before you build anything. Review AI-generated code the way you'd review a teammate's pull request, until you have real opinions about what good looks like. Build a small coding agent yourself, so you learn where models break. If your work doesn't carry judgment beyond what an agent could produce on its own, you aren't adding much.

Interview for building

LeetCode-style interviews caught on because they were cheap to run and easy to grade. They were always a rough proxy, since nobody implements a sorting algorithm by hand on the job, but they worked well enough until AI broke them. Now the weakest candidates can cheat their way to a perfect answer, while strong builders who rarely write code by hand anymore can stumble. It no longer makes sense to test whether someone can code. The useful question is whether they can build.

We already know how to run that kind of interview, because it's how companies have always hired tech leads and engineering managers. Give them a complex system to design, with real constraints and tradeoffs, and push for detail. What breaks at scale? What drives latency? Where would you optimize first? Good candidates ask questions first, work top down from the main components and how they interact, and do the math out loud. Weak candidates stall, give generic answers, or get lost in implementation details before they've worked out how the system fits together. Pick a problem from your own team's work so nobody has seen it, plan your pivots, and write the rubric before the first candidate. How someone handles a new constraint tells you far more than their first answer.

The second signal is whether a candidate can get results. Give them a task that takes three or four hours with AI allowed, the way they'd work on the job, and leave them alone while they do it. People think worse with someone watching. In one study, students who solved a problem in front of an interviewer scored less than half as well as those who worked alone[7]. Make integration the hard part. A small API, a worker and a datastore that have to cooperate show you more than any single function. Models write single pieces well, but deciding how they fit together when the requirements are fuzzy still takes human judgment.

Then have them walk you through it, in person if you can. Ask why a line is there, change a requirement, or hand them an AI-written diff with one real bug. Someone who had a model or a friend do the work can't explain the choices. This is also your coding test, at the level that matters now: reading code, questioning it and changing it. The candidates who stumble here can usually write code fine. What they lack is the judgment to steer the tool and catch its mistakes[4].

For a hiring manager, it comes down to four changes:

Where the jobs are

It's easy to read all of this as AI killing the software job. The data says otherwise. Total employment at the AI-adopting companies in the Stanford study didn't fall[5]. US government projections draw the line more sharply. Jobs for computer programmers, whose work is turning other people's designs into code, are projected to shrink 7% over the next decade as AI automates routine programming (probably massively underestimated). Jobs for software developers, who design the systems and decide how the pieces fit together, are projected to grow 10%, more than three times the average for all occupations, as software moves into AI, robotics, connected devices and electric vehicles[8].

Fewer people will be paid just to type code. More will be paid to build something useful, because AI lets a small team build what used to take a large one. That's good news for new grads. Directing a team of agents is a skill you can start building today, and the strong juniors I've worked with already do it from day one. The next generation of interviews should be designed to find them.

At Pairwise we help hiring teams find the engineers worth interviewing, then guide them on what to ask so the interview gives real signal.

Notes

[1] How Hard Is It to Cheat in Technical Interviews with ChatGPT? We Ran an Experiment. Mroczka, interviewing.io, January 2024

[2] The Pulse #146. The Pragmatic Engineer, 2025, reporting an interviewing.io survey of 63 interviewers

[3] The results of the 2026 Developer Survey are here. Stack Overflow, October 2026

[4] Yes, You Can Use AI in Our Interviews. In Fact, We Insist. Newton, Canva Engineering, June 2025

[5] How Does AI Change Labor Demand? Evidence from 41 Countries. Chandar, Klein Teeselink, Stanford Digital Economy Lab, September 2026

[6] Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence. Brynjolfsson, Chandar, Chen, Stanford Digital Economy Lab, updated August 2026

[7] Does Stress Impact Technical Interview Performance? Behroozi, Shirolkar, Barik, Parnin, ESEC/FSE 2020

[8] Occupational Outlook Handbook, Software Developers, Quality Assurance Analysts, and Testers and Computer Programmers. U.S. Bureau of Labor Statistics, 2025 to 2035 projections, updated August 2026

Want to see what signals your applicant pool already has?
Request a demo
Back to all posts
All systems operational
© 2026 Pairwise Technologies LLC
Terms
Privacy