AI Changed How to Interview a Software Engineer. Here’s How in 2026

I’ve hired a lot of engineers over the last 20 years, at Full Scale and at the companies I built before it. I’ve sat on both sides of the table more times than I can count. For most of that time, the technical interview had one job that everybody quietly knew it wasn’t doing well: A tighter process pays off most in the 2026 developer hiring market, where senior candidates field competing offers fast. It applies stack by stack, including what to require in a senior Java developer job description. The same rethink applies to a senior iOS developer job description.

It measured how well someone prepared for technical interviews, not whether they could do the work.

That gap was always there. AI blew it wide open. The whiteboard puzzle, the timed algorithm, the “reverse this linked list on a video call” round, those test the exact thing AI now does for free, in seconds, better than the candidate can. So if you’re still running the 2019 interview in 2026, you’re grading people on a skill the job no longer needs and missing the skills it now needs more than ever. The fix is stack-specific too: our iOS developer interview questions show what to ask Apple-platform hires instead. For browser work, the same method drives what to ask front-end developers. The same rethink applies to a senior Node.js developer job description.

So when people ask me how to interview a software engineer today, my answer has changed. You stop testing what AI can do, and you start interviewing for the things AI can’t. Let me walk through what broke, and exactly what I’d ask instead. The same rethink applies stack by stack, including what to require in a senior .NET developer job description.

AI can already pass your technical interview

Here’s the uncomfortable part. The classic technical interview was built around problems with known answers: data structures, sorting algorithms, the kind of self-contained puzzle you can grade on the spot. Those are precisely the problems large language models are best at. A candidate with a second screen can sail through your LeetCode round, and plenty do. You’re not measuring their engineering. You’re measuring their ability to relay an AI’s answer without you noticing. The same shift hits every stack, so our PHP developer interview questions show what to ask once AI can answer the trivia.

The job changed underneath the interview, too. Google’s CEO, Sundar Pichai, has said about 75% of the company’s new code is now AI-generated, and every line of it is still reviewed and approved by an engineer. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools in their work. The engineers who stand out now aren’t the ones who can recite a sorting algorithm from memory. They’re the ones who know what to build, can tell when the AI is wrong, and own the result.

So an interview that bans the tools, isolates the candidate, and rewards memorization is testing a version of the job that barely exists anymore. Raw coding speed stopped being the differentiator. Judgment became it.

The whiteboard never looked like the job anyway

AI exposed the problem, but the format was always a poor match for the work. Nobody on your team writes code the way a whiteboard demands. On a normal day, a real engineer reads the docs, asks a teammate, leans on AI tools, and works in their own editor with version control. They test, refactor, and come back to a problem over hours and days, not minutes. And before they decide how to build something, the good ones ask why they’re building it at all.

There’s a second problem the industry doesn’t like to say out loud. A technical interview asks two people, neither of whom is good at this, to make a big decision under artificial pressure in under an hour. Most engineers and tech leads were never trained to interview anyone, and a lot of excellent engineers are not at their best talking through a problem out loud while someone grades them in real time. You end up with two uncomfortable communicators trying to make an expensive call in 45 minutes. The process was built to produce doubt, not clarity, long before AI showed up.

A lot of teams react to all this by trying to hire the cheapest body that can pass the puzzle. That’s the mistake I call cheapshoring, and it backfires for the same reason the whiteboard does. You optimized for the wrong signal.

An AI-proof interview tests what AI can’t do

Once you accept that AI can handle the puzzle, the job of the interview gets clearer. You stop quizzing for things a model answers instantly, and you start digging into the things it can’t fake on a candidate’s behalf in a live conversation. That list is the actual job:

• How they think. Can they reason through a messy, underspecified problem out loud, or do they only function when the problem is already defined?
• How they solve problems. Not the answer, the approach. What do they try first, how do they narrow it down, what do they do when stuck?
• How they’ve worked before. Real stories from real projects, with specifics. AI can write a perfect generic answer; it can’t invent a candidate’s actual history under follow-up questions.
• How they work on a team. Do they communicate, ask clarifying questions, and handle disagreement, or do they go quiet and guess?
• How they lead. When they owned a project, how did they make calls, manage tradeoffs, and bring people along?
• How they spot problems. The best engineers find the issue before it ships. Do they think about edge cases, failure modes, and what could go wrong?
• How they tie work to the customer. Do they connect what they build to a real outcome for a real user, or do they just close tickets?
• Whether they understand the whole lifecycle. Requirements, design, testing, deployment, support, the parts of software that aren’t typing code.
• Whether they know what AI can’t do. This one is new and it matters. A strong engineer in 2026 knows where AI helps, where it’s confidently wrong, and why a human still has to own the result.

None of that shows up in a timed algorithm puzzle. All of it shows up when you ask open-ended questions and actually listen to how someone answers.

The open-ended questions that actually reveal an engineer

The format that works is a conversation, not an exam. You ask open-ended questions, you let them talk, and then you follow up on the specifics. The follow-up is where the truth lives, because a rehearsed or AI-assisted answer falls apart the moment you ask “why did you do it that way?” or “what would you do differently now?”

Here are the questions I’d actually use, grouped by what they’re really measuring.

What you want to learn	A question that gets at it	What a strong answer sounds like
How they think	“Walk me through a hard problem you solved recently. Where did you start?”	They reason out loud, name their assumptions, and show how they narrowed it down, not just the final answer.
Problem-solving under uncertainty	“Tell me about a time the requirements were unclear. What did you do?”	They asked questions, made the ambiguity smaller, and didn’t just start coding on a guess.
Past experience (the real version)	“What’s a project you’re proud of, and what was your specific part in it?”	Concrete details only they would know, and an honest line between what they did and what the team did.
Teamwork	“Tell me about a disagreement with a teammate over a technical decision. How did it end?”	They listened, made their case, and could live with the outcome. No villains in the story.
Leadership	“Describe a project you led. What was the hardest call you had to make?”	They owned a tradeoff, explain why, and can say what they’d change.
Spotting problems early	“When you pick up a new feature, how do you figure out what could go wrong?”	They think about edge cases, failure modes, and the unhappy path before they write code.
Customer value	“How do you know the thing you built actually helped someone?”	They tie their work to a user or a business outcome, not just a closed ticket.
Full lifecycle understanding	“What happens to your code after you write it?”	They talk about testing, review, deployment, monitoring, and support, not just the commit.
Knowing AI’s limits	“Where does AI help you, and where do you not trust it?”	They use it daily and can name exactly where it’s confidently wrong and why a human still has to own the result.

The trick with every one of these is to keep pulling the thread. Ask for the specific project, the specific decision, the specific thing that broke. Generic answers are easy to fake. Specifics are not. When you ask someone to go three layers deep on a real story from their own career, you find out fast whether they lived it or rehearsed it.

You’ll also notice none of these have a single right answer, which is the point. You’re not checking whether they match a key. You’re watching how a mind works when there’s no clean solution waiting at the end.

The best interview is still watching someone work

Open-ended questions get you most of the way. But the strongest signal of all isn’t a question at all. It’s real work.

Instead of asking “can you solve this puzzle while I watch,” you get to answer the only question that actually matters:

Can this person contribute to our work?

That’s why, when we can, we skip the formal technical round entirely and replace it with a week of real work. We call it the 40-hour interview. Here’s the difference between the two approaches, side by side:

A 45-minute technical interview measures	A week of real work measures
How well someone prepared for interviews	Whether they can do the actual job
Solving a puzzle alone, against the clock	How they communicate with a team across time zones
Recall of algorithms with the tools taken away	How they work in their own editor, with the tools they’d really use
A snapshot under artificial pressure	Ownership, judgment, and follow-through over several days

One week of real work tells you more than a dozen interviews ever could. You find out how someone communicates with a team that isn’t all in the same room, and whether they ask clarifying questions when the task is fuzzy or just start guessing. You watch them write code in context, respond to feedback, and either take ownership or wait around to be told the next step. Most telling of all, you learn whether they ask why before they ask how.

Those are the same things your open-ended questions were probing for. The difference is you’re seeing them happen instead of hearing about them.

Trust the screening, then trust the work

There’s a catch with both approaches, and it’s the same catch with hiring tech talent in general: finding good people to even try out is slow and expensive. The best engineers usually aren’t applying anywhere. They already have jobs and they’re not browsing listings. The people who flood your job post have often applied to a hundred roles in six months and landed none of them.

This is the part an agency is actually built to solve, and it’s why I think going through one beats hiring direct for most teams. At Full Scale, the model is staff augmentation: we have full-time recruiters whose whole job is to pull passive candidates, the ones who aren’t looking, away from their current employers, plus referrals from a team of 350+ engineers. By the time we put someone in front of a client, they’ve already passed a technical screening plus checks for communication, English, work ethic, and fit with the way we work. Fewer than 3% of applicants make it through. We don’t send anyone we wouldn’t stand behind.

Our clients see it in the work, not in a pitch. Dustin Johnson, Co-Founder and CTO of SOTA Cloud, put it this way: “Having a pre-vetted list of people that have already been pre-qualified, it saves everybody time, it saves us expense, and it helps the hiring process move more quickly.” At AMC Theatres, CIO Derrick Leggett treats the engineers we staff as full members of his team, not contractors behind a wall. As he says, “It’s a fully integrated team. It’s just some of the people happen to be living in the Philippines.”

The track record is the proof that the screening holds up. Our developer retention runs over 93%, we’ve made the Inc. 5000 four years in a row, and we’re Great Place to Work Certified in the Philippines, where 95% of our people say it’s a great place to work versus 65% at a typical company. Low turnover isn’t a vanity number. It means the team stays together, and a team that stays together delivers more consistently for the client.

If it doesn’t work out, you don’t pay

No screening is perfect, including ours. Even with a hard vetting process and careful matching, sometimes a placement isn’t the right fit. I’d rather just say that plainly than pretend otherwise.

So we back every engagement two ways. You can run the 40-hour interview as a working trial before you commit, or you can take the first two weeks with a money-back guarantee. If it isn’t working, you’re not on the hook for it. And because the engineer is already on our payroll, there’s none of the awkwardness of asking someone to do trial work before they’ve left their current job. The trial is just part of how we work. That’s how staff augmentation should work: you get the upside of a strong hire without carrying all the downside when one isn’t a fit. You get to base the decision on real work instead of a gut read from a 45-minute call, and the risk of being wrong sits with us, not with you.

When you pair a screen we’ve already done with a real working trial, you move faster and spend less time on hiring theater. Time you don’t burn on a broken process is money you keep in the business.

The decision is simpler than the industry makes it

What you actually need is an engineer who can do the job: someone who thinks clearly, communicates well, takes ownership, uses AI well without trusting it blindly, and builds things that matter. That’s it. The only real question is how you figure out who those people are before you commit to them. A lot of that ownership is risk judgment, including weighing the risk of a change before you ship it.

A 45-minute whiteboard puzzle was never a reliable answer, and AI just made it useless. Open-ended questions about how someone thinks and works will tell you far more. A week of real work, on your codebase, with your team, will tell you almost everything.

We’ve spent years building a process that finds the right engineers, vets them hard, and stands behind every placement, so you don’t have to build it yourself. If you want to talk through what that would look like for your team, schedule a call with us.