Recruiters spend a lot of time right now sorting through noise.
Hundreds of applications. AI-generated resumes. Candidates applying everywhere.
So when they finally find someone worth moving forward, that candidate is supposed to matter more. Not less.
But in practice, that’s where something breaks.
Because once the interview is scheduled, the focus often shifts away from the candidate.
And that’s a problem.
The disconnect nobody talks about
I spoke with an engineer, Eric Garcia, who recently interviewed for a Full Stack Developer role at a global professional services firm in one of their internal product engineering teams supporting tax and enterprise platforms.
On paper, the role was clear:
- Angular
- .NET Core / C#
- SQL Server
- APIs and troubleshooting
- Cross-functional collaboration
- AI integration
A real full stack engineering role. Real systems. Real production work.
Then came the technical assessment.
The assessment didn’t match the job
The test was delivered through Codility.
90 minutes. Two questions. Closed book. Proctored. No prep guidance.
No context about what to expect.
Question 1: build a stack machine with strict edge cases and constraints.
Question 2: find the largest palindrome in a string with scaling complexity.
This is not Angular.
This is not .NET.
This is not SQL Server.
This is algorithmic pattern recall under time pressure.
Eric’s reaction was blunt:
“It puts your brain in a box. It’s you, your memory, and nothing else.”
Even if he had scored perfectly, it still wouldn’t have told anyone whether he could build or maintain the kind of systems described in the job.
So the real question becomes:
What exactly is being measured here?
And does it match the work?
The bigger issue isn’t the test
This isn’t just about whether coding assessments are good or bad.
It’s about alignment.
Because the role being hired for requires:
- Debugging real applications
- Working in Angular and .NET systems
- Designing APIs and databases
- Collaborating with teams
- Integrating modern tools, including AI
But the evaluation removes all of that context.
No frameworks. No systems. No collaboration. No real-world constraints.
Just isolated logic problems.
Then there’s the AI contradiction
There’s another layer that makes this even more outdated.
The role explicitly includes AI integration work.
But the assessment environment is closed book, with unclear rules around tools like Copilot or IntelliSense.
Eric turned Copilot off out of caution. Not because it was explicitly banned, but because “no cheating” was undefined.
So candidates are left guessing:
- Is Copilot allowed?
- Is IntelliSense allowed?
- Is documentation allowed?
- What counts as cheating in 2026?
These aren’t edge cases anymore. They are normal parts of how engineers work.
Yet most recruiting processes that provide these type of tech evals haven’t adapted to that reality.
The recruiter gap
Here’s the uncomfortable part.
Recruiters are not expected to be engineers.
But if you’re sending someone into a technical assessment, there are a few things you should be able to answer:
- What platform is being used?
- What kind of problems will show up?
- What does “closed book” actually mean?
- What tools are allowed?
- How does this relate to the actual job?
Because right now, candidates are often walking into assessments with zero context.
Not because recruiters are careless. But because the system doesn’t require recruiters to own that clarity.
And that’s where candidates lose.
What candidates should be asking
This also shifts responsibility to candidates.
Before walking into any technical evaluation, they should be asking:
- Is AI tooling allowed or disabled?
- Is this a speed test or a real-world problem-solving exercise?
- What are the main categories being assessed?
- What does success actually look like in the assessment: only care about correct working code, clear explanation of the approach etc?
- Is this reflective of the day-to-day work?
Most candidates don’t ask these questions because they assume the recruiter doesn’t know.
And often, they don’t. But they should. These aren’t complex questions for a recruiter to get clarity on. After all, the recruiter wants the candidate to prepare for the interview. How do you prepare when you don’t know what you’re walking into? As Eric put it, “It’s like being told to go prepare for the SATs” without being told what sections will be on the test.
The real takeaway
This isn’t about blaming recruiters.
It’s about a gap that has widened:
- Hiring teams define roles in real-world systems
- Assessment platforms test abstract logic (IKM, Leetcode, Hackerrank, codility’s of the world)
- Recruiters sit in the middle without enough context
- Candidates are left to bridge the gap themselves
So you get situations where:
A candidate is hired for AI-integrated full stack engineering work. But the evaluation process removes the very tools that now define how engineers actually work. That disconnect matters.
Because if you want better hiring outcomes, the solution isn’t just better assessments or better candidates.
It’s better alignment between:
- the job
- the evaluation
- and the preparation
At minimum, if you’re going to make someone take a technical assessment…The least you can do is help them understand what they’re walking into.
Otherwise, you’re not evaluating talent. You’re evaluating guesswork.
Appreciation to Eric Garcia for sharing his experience and helping unpack what these technical evaluations feel like on the candidate side.