A candidate sits down for a DSA round. They're asked to reverse a linked list. They do it — clean, correct, no hints needed.
You hire them.
Three months later, you discover they can't explain why they'd choose a linked list over an array in the codebase they're actually working in. They passed the interview. They didn't have the depth.
This is not an edge case. It's the default outcome when the DSA interview is treated as a recall test rather than a reasoning test.
The DSA interview as most companies run it today was designed for a world where problem sets weren't public, AI-assisted prep didn't exist, and the questions themselves weren't categorised into Leetcode patterns and sold as prep courses.
That world is gone. Here's what's replaced it:
Candidates now prepare for DSA interview problems by pattern — sliding window, two pointers, DFS/BFS, dynamic programming — and practice each one until recognition is nearly automatic. Platforms like Leetcode, NeetCode, and AlgoExpert have turned the DSA interview from a reasoning exercise into a pattern-matching memory test. A candidate who has done two hundred problems can often retrieve the right approach within thirty seconds of reading a prompt — not because they understand it deeply, but because they've seen the shape before.
And in 2026, the situation is worse. AI tools can generate a working solution to most standard DSA problems in under ten seconds. Candidates who use these tools during asynchronous assessments — or who memorise AI-generated explanations during prep — can produce correct output without any understanding of the underlying trade-offs.
The result: a passing DSA score tells you a candidate can pattern-match or memorise. It does not tell you whether they can think.
The reason DSA interviews exist is not to verify that a candidate can implement a binary search. It's to surface how someone thinks under constraint — how they navigate ambiguity, recognise trade-offs, handle follow-ups, and extend their reasoning to edge cases they haven't seen before.
A candidate who genuinely understands why a heap gives you O(log n) on a priority queue operation — rather than just knowing to use a heap when they see "top K" in the problem statement — is a fundamentally different hire than someone who pattern-matched their way to the same answer.
The standard fixed-prompt DSA interview can't tell these two apart. It ends when the candidate reaches a correct solution, which is precisely when the signal starts.
The question after the solution is where the real interview begins. "Why that data structure?" "What breaks at scale?" "How would you change this if the input were a stream instead of an array?" A candidate who understood the problem keeps going. A candidate who pattern-matched runs out of road.
Adaptive questioning doesn't mean harder questions. It means questions that depend on what the candidate just said.
Here's the same problem — a standard two-sum variant — run through a fixed interview versus an adaptive one:
Interviewer: Find two numbers in an array that sum to a target. Return their indices.
Candidate: Uses a hashmap. O(n) time, O(n) space. Correct.
Interview moves to next question. Signal captured: candidate knows the hashmap pattern for two-sum.
Interviewer: Find two numbers in an array that sum to a target. Return their indices.
Candidate: Uses a hashmap. O(n) time, O(n) space. Correct.
Interviewer: Why a hashmap over sorting and using two pointers?
Candidate: (Explains the O(n log n) sort cost vs. the index preservation problem — or doesn't.)
Interviewer: If this array is a stream and you can't hold it in memory, how does your approach change?
Candidate: (Extends the reasoning to a sliding window or trie approach — or freezes.)
Interviewer: What's the memory tradeoff you're accepting, and when would that matter in production?
Signal captured: whether the candidate understands trade-offs, can extend to novel constraints, and can connect CS theory to engineering reality.
The second interview takes the same problem and extracts an order of magnitude more signal — not by adding harder problems, but by refusing to stop at the first correct answer.
Senior engineers know how to ask the second and third question. The problem is that most DSA rounds are run under time pressure, with a fixed problem set, and by people who are already in the middle of their own sprint. Adaptive follow-up requires the interviewer to be fully present and improvising from what the candidate just said — not following a checklist.
When a company runs fifteen DSA screens a month across five different interviewers, consistency disappears entirely. Some candidates face three levels of follow-up. Others get one question and a handshake. The candidate who interviewed on a Friday afternoon after a war-room bug fix gets a different bar than the one who came in on Tuesday morning.
This inconsistency is the core problem. Companies don't have a shortage of good interviewers — they have a shortage of consistent evaluation. The same engineer who would ask sharp adaptive follow-ups in a high-stakes final round is running the same shallow first-round screen as everyone else because there isn't bandwidth to do both.
This is the gap Ray was built to fill. Ray runs adaptive voice DSA interviews that don't follow a fixed script — each follow-up question is shaped by what the candidate said in the previous turn. When a candidate reaches a correct solution, Ray doesn't move on. It goes deeper:
A candidate who genuinely understood the problem answers these with the same fluency they brought to the original solution. A candidate who pattern-matched their way to the correct output hits a wall — usually by the second follow-up, sometimes the third.
The output isn't a pass/fail score. It's a structured debrief that shows exactly where the candidate's reasoning held up and where it didn't — so the hiring team can make a real decision instead of relying on "solved the problem, seemed solid."
Bad DSA screens have two failure modes, and most teams only worry about one of them.
The obvious failure is letting in a candidate who can't do the job. But the less visible failure — and in a competitive market, often the more expensive one — is filtering out a strong engineer who blanked on a pattern they hadn't drilled, while passing someone who drilled every pattern and can't think around a novel constraint.
The fixed DSA interview optimises for recall. Adaptive questioning optimises for reasoning. If you're hiring engineers to solve problems you haven't encountered yet — which is most software engineering — the second thing is what you actually need to measure.
Ray conducts voice-based adaptive interviews that probe beyond the first correct answer — and delivers structured debriefs your team can act on.
See Ray in Action →