Technical Vetting Software Engineers: What AI Has Changed and What Still Matters

A software developer can build a full, working app in an afternoon now, with one good prompt. That used to take a senior developer the best part of a day. So if producing code isn’t the hard part anymore, what should you actually be testing for when you hire a developer today?

It’s also something we’ve had to sit with ourselves. In a recent next-gen engineer episode, OfferZen’s Dinielia Pillay asked: “If you feel your hiring process is slow, it’s worth asking yourself and your team: are all your stages truly predictive of on-the-job success, or is it just legacy habits? Is your take-home exercise realistic, or might it drive top candidates away?”

Here’s what we’ve rethought about our own process and what it means for yours.

How OfferZen adapted our own take-home assignment for the AI era

Recently, our Head of Engineering, Nick van Noordwyk, explained how our take-home assignment wasn’t giving us what they needed anymore.

“In the past, the code a candidate produced was the signal. Read it, judge it, decide. That got harder to trust. AI can generate a full, working submission with very little real effort now.”

Video is now the higher signal

The answer was to rebuild the assessment around a video walkthrough. Our candidates now talk through what they built, the trade-offs they’d stand behind, what they deliberately skipped, and where they pushed back on the AI.

The video replaced their code repo as the primary deliverable. We’ve found that a strong video with incomplete code goes further than complete code with a weak video.

Code becomes a test of ownership

We still use their code in the follow-up interview, but as a way to test ownership rather than correctness. The team reads the code and watches the video ahead of time, then asks the candidate to walk through a section of their own code live, checking whether the two line up.

One candidate, for example, caught a redundant validation check that AI had introduced during the build but spotted it live in the interview. He explained exactly what it should do instead. That moment told our team more about his judgement than a clean submission ever could have.

That’s who we’re hiring for: someone who’s deliberate about what they build, steers the AI to get there, and can stand behind what they ship.

It’s a useful story, because the questions we had to answer are pretty much the same ones most hiring teams are asking right now.

What is the difference between technical vetting and a technical interview?

We hear these two terms used interchangeably, and it’s worth pulling them apart.

Technical interviews

A technical interview is usually just one stage within the broader hiring process and typically tests how someone thinks and communicates in the moment. It can take the form of a whiteboard interview, a paired programming session, or a take-home technical assessment.

Technical vetting

By contrast, technical vetting is everything around it. It is a structured, multi-stage process including the assignment, the team’s review of it, the interview itself, and often a simulation of what working together would actually look like.

The distinction matters because a strong interview tells you someone can talk about their work. It doesn’t necessarily tell you how they’d hold up over four hours of ambiguity, or how they’d take feedback from a teammate that disagreed with a call they made.

What skills should technical assessments test for in the age of AI-assisted coding?

In the age of AI, great engineers know what’s worth building. They should know how to collaborate across the full cycle, evaluate trade-offs, and bring enough context about the customer, the industry, and the business to make judgement calls.

Technical assessments need to help you test a candidate’s judgement, problem framing, trade-off reasoning, and code ownership. This can include:

Problem solving

Did they question or refine the brief, or just implement it literally? A candidate who takes the brief entirely at face value will build exactly what’s asked, even if a requirement doesn’t quite hold up or an edge case is missing.

The stronger signal is someone who treats the brief as a starting point rather than a fixed spec, or who flags an assumption that seems off, asks a clarifying question that changes the approach, or points out a case the brief didn’t account for. This helps you see if they’re thinking about the problem or just executing instructions.

System design and trade-offs

Can they explain their design choices and what they deliberately left out to keep the system workable? Every real system involves trade-offs: speed versus simplicity, scope versus the time available, or robustness versus getting something shipped.

What you’re testing for here is whether those trade-offs were made consciously. A strong candidate can tell you not just what they built, but what they chose not to build, and why that was the right call given the constraints. That’s a very different signal to someone who just built whatever came out of the first approach that worked.

Code review as an editor

Can they defend every line, spot over-engineering, and tell the difference between code that looks plausible and code that’s actually correct? This one matters more than ever now that AI can generate code that reads cleanly and looks right at a glance.

“Looks right” and “is right” aren’t the same thing anymore, so the candidate needs to be able to step into the role of editor on their own work: justify each decision, flag anything that’s more complex than it needs to be, and catch the difference between a solution that merely passed the tests they thought to write and one that’s actually sound.

A supplemental video walkthrough

This can be supplemented by adding a video walkthrough to the process. Here, candidates talk through what they built, the trade-off they’d stand behind, what they deliberately skipped, and where they pushed back on the AI.

That’s why we made the walkthrough the core deliverable in the assessment: A strong video with incomplete code goes further than complete code with a weak video, because it shows the thinking a finished repo can hide.

What are leaders prioritising in technical vetting now, compared to a few years ago?

In our 2026 Salary and benefits report, 71% of teams said they’re hiring for specific, high-impact roles rather than simply adding headcount.

Hiring has shifted from adding capacity to building capability, and from judging code output to judging ownership. The industry now focuses on judging how someone can think and if they act like the architect of a system.

That now includes being able to understand a customer’s need, the ability to shape products, and rooting all of that in solid engineering fundamentals.

Learn more: The Software Engineer Skillset 60+ Tech Leads Are Hiring For

Should companies still ban AI tools during coding assessments?

In short, no. Banning AI during a coding assessment tests a scenario that no longer exists on the job.

The majority of developers are using AI coding tools at work, and more companies are recognising AI fluency as a core competency in new hires.

Companies that ban AI tools during coding assessments have no way of assessing whether someone can use these tools effectively.

What to evaluate when AI is allowed

The core skill you’re evaluating is how well a candidate could direct AI, the quality of the judgement they applied to what came back, and whether they can explain and own the result.

One way to do this is running interviews with full AI access and a screen share, specifically so the interviewer can watch how a candidate sets up their approach.

This allows you to assess a candidate’s:

• Fundamentals: is the candidate prompting for a quick answer, or are they using skills, agents, and clear ground rules to stay in control of the output?
• Direction: did the candidate know what “good” looked like before the AI produced anything?
• Judgement: did they catch mistakes, question outputs, and know when to override the AI?
• Ownership: can they defend every part of the solution as if they wrote it themselves?

Frequently asked questions

What does technical assessment mean?

At its core, a technical assessment’s meaning comes down to this: it’s any structured way of testing whether a candidate can do the technical work a role actually requires. That might be a single technical assessment test, or, for more senior or high-stakes roles, a fuller technical vetting process like the one we’ve walked through above.

What is a technical skills assessment?

A technical skills assessment is a broader category that includes take-home projects, live coding sessions, and a more general online technical test for software developer roles. Which one makes sense depends on the seniority of the role and how much time you can reasonably ask a candidate to give up.

What’s a good technical test for frontend developer roles?

A well-designed technical test for frontend developers should mirror real work: building or extending a small UI feature, making sensible calls on state, edge cases, and performance, rather than testing textbook syntax. The same principle holds whatever the discipline; keep it realistic and time-boxed.

Is a coding assessment test still worth running if candidates can use AI?

Yes, but the emphasis shifts. A coding assessment test used to be judged mostly on whether the output worked. Now it’s judged on the decisions behind it, which is why pairing it with a short explanation or video walkthrough tells you far more than the code by itself.

What this means for your hiring process

The point of a technical assessment was never to confirm that a candidate can produce code. AI has made that the easy part. If your process still treats a clean repo as the finish line, it’s worth revisiting how you assess, interview, and score candidates.

The real test now is whether they know what to build, why they’re building it, and what to do when the AI gets it wrong.

Need help with your tech hiring process?

Technical vetting can be complex and time-consuming, especially for non-technical hiring managers or even busy CTOs who have competing priorities beyond reviewing take-home submissions and running technical interviews.

That’s why OfferZen created services to help teams with exactly this challenge. Through OfferZen Embedded and OfferZen Contracting, supported by our dedicated Code Council, a network of senior engineers, tech leads, and domain specialists, we can run the technical vetting on your company’s behalf.

Rather than simply scoring a take-home assignment, our assessors use each candidate’s submission as the starting point for a deeper technical conversation, exploring why they made certain decisions, what trade-offs they considered, and how their solution would adapt if the requirements changed.

Get in touch to learn more, or download the Technical Assessment Toolkit to start improving your hiring process today.