How to Interview a Software Engineer: Why the Process Is Broken

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. And the thing I keep coming back to is uncomfortable for an industry that runs on it:

The technical interview mostly measures how well someone prepared for technical interviews.

That’s not the same as measuring whether they can do the job. It never was, and in the age of AI the gap between the two has gotten wide enough that I think most teams are still hiring blind.

So when people ask me how to interview a software engineer, my real answer is that you should stop interviewing them the old way and start watching them work. Let me walk through why the standard process fails, and what I’d do instead.

The interview puts two people who are bad at this in a room for 45 minutes

Here’s the structural problem nobody likes to say out loud. A technical interview asks two people, neither of whom is naturally good at this, to make a big decision under artificial pressure in less than an hour.

Start with the interviewer. Most engineers and tech leads were never trained to interview anyone. It isn’t the job they were hired for, and it usually isn’t the part of the week they look forward to. Strong engineers tend to be heads-down and methodical, not quick to build rapport with a stranger or read between the lines of a nervous answer. That’s not a knock on them. Ask anyone to do something they were never trained for, don’t enjoy, and aren’t measured on, and the results are going to be all over the place.

Now the other side of the table. A lot of excellent engineers are not at their best talking through a problem out loud while someone grades them in real time. They can be deep, careful, productive people who ship great work, and still freeze in a formal interview because the format rewards a skill the job doesn’t really use.

So you’ve got two uncomfortable communicators trying to make an important call in 45 minutes. The process is built to produce doubt, not clarity.

Whiteboards and live coding look nothing like the actual job

The format problem runs deeper than nerves. The tools we lean on in technical interviews don’t match how engineers actually 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, and uses AI tools without thinking twice. They work in their own editor with autocomplete and version control. They test, refactor, and come back to the problem over hours and days, not minutes. They talk across teams and time zones. And before they decide how to build something, the good ones ask why they’re building it at all.

That last one is the part I care about most. The best engineers I’ve worked with don’t just take a ticket and execute it. They think about the outcome, they push back when the ask doesn’t make sense, and they connect their code to the customer. That’s the whole idea behind Product Driven, the approach I wrote about in my book and the way we train people at Full Scale. None of it shows up in a timed algorithm puzzle. All of it shows up when someone is in real work, on a real team, solving a real problem.

AI made the cracks impossible to ignore

AI didn’t break the technical interview. It just turned the cracks into something you can’t unsee.

The job changed. The engineers who stand out now aren’t the ones who can recite a sorting algorithm from memory. They’re the ones who think clearly, use AI tools well, work well with other people, and stay focused on shipping something that matters. 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.

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 typing speed isn’t the differentiator anymore. What matters now is judgment and ownership: knowing what to build, and standing behind what you ship. When you strip away the tools and the context that define how engineers actually work, you have to ask what you’re really measuring, and whether it’s anything you need.

I’d add one more thing here, because it’s a related trap. 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.

The best way to interview a software engineer is to watch one work

Here’s what I’d do instead of the formal technical interview. Skip it, and replace it with a week of real work. We call it the 40-hour interview.

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

Can this person contribute to our work?

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 things that tell you if a hire is going to work. You can’t see any of them in a whiteboard session, and you can see all of them in a few days of working side by side.

Trust the screening, then trust the work

There’s a catch with the 40-hour approach, 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 week 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. That’s the whole point: 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 shows up, communicates well, takes ownership, 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 45-minute interview with a whiteboard puzzle has never been a reliable answer. A week of real work, on your codebase, with your team, almost always is.

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.