Effective Interviewing (Part 2): How to Bring 'Legacy' Questions to 2026
Effective Interviewing (Part 2): How to Bring “Legacy” Interview Questions to 2026
In Part 1, we discussed the foundational rule of interviewing: define the role before you start, align the JD with the Job Ad and your Rubric, and know what you want to assess the candidates on.
Usually especially for more technical positions in which technology can blur the lines of knowledge, you inevitably hit a common dilemma: How do we evaluate whether the candidate understands how systems work or their knowledge is just superficial?
To combat this, hiring managers resort to questions that are more legacy and basic. A prime example being SQL Injection.
Let’s fully clear here: SQL Injection is not a legacy concept. It remains one of the most crucial attack vectors with high security risks in modern software and engineers do a considerable effort to defend against it. Engineers must, without a doubt know it, care for it and understand it.
Unfortunately there is a big problem, asking a candidate how to manually write a SQL Injection payload in 2026 does not test engineering depth. It mostly checks whether they were around in 2006 or if they have spent time memorizing the OWASP top 10 cheat sheet.
Of course, there are people who do consider this part of their skillset and I do not wish to reduce them, but it is not a common skill.
Instead, this is how you take a foundational concept, remove the quiz-like testing and turn it into a modern evaluation of system understanding, security thinking and adaptiveness.
1. The Trap: Testing Trivia vs. Testing System Flow
Let’s imagine you ask the candidate “How is an SQL injection attack executed in a raw SQL script?”
They would answer something in the realms of “You insert a single quote and comment out the rest of the query with --,“
But what did we just measure here?
- Did we measure their system design capabilities? No.
- Did we measure their architectural awareness? No.
- What we actually measured was their ability to remember the syntax of an attack vector which is largely handled today for us by frameworks.
If part of your rubric contain contains questions around esoteric payload string, you are missing the point.
Software engineers (unless specifically pen testers or white-hat hackers), are not responsible to memorize the OWASP directory. What you should aim to evaluate is: “Can this person understand the data flows of the system, where do vulnerabilities emerge and what are the mitigation plans at different boundaries?“
2. Flip the Question: From “How to Attack” to “How Data Flows”
Let’s flip the framing entirely but remain in the same domain area. Instead of asking the candidate to write the exploit give them a scenario in which the exploit is presented and maybe in an obscure way.
”Here is an potentially exploitative input string. What would happen if this gets passed into the database layer. Walk me through all the places in a modern application stack where we can identify and protect against such potential threats.”
With this framing, the question is no longer trivia quiz. It is an architectural discussion that can be followed by any cross-functional interviewer. PMs looking at the input validation logic or Staff engineers evaluating the defense boundaries. In detail you can track:
- API Layer: Are we validating the contract schemas and inputs before they reach our internal services?
- Repository Layer: Does the candidate understand the role of ORMs, MicroORMS and Query Builders? Do they understand the mechanics used from such tools and why using Query Builders doesn’t automatically make the system 100% immune if raw fragments are passed?
- Database Layer: Are we using Stored Procedures or feed the database using non-parameterized queries?
What we have managed to create is a ground in which the candidates understanding of end-to-end system hygiene is tested and not their ability to memorize superficially.
3. What if They Don’t Know What SQL Injection Is?
In this case we are in a delicate situation. Largely it depends on your hard requirements. Interviewing for a role or in a company that requires the candidate to be up to speed from day one would mark this criteria as a fail and resonably so.
However, if you are in an environment in which you have a SaaS offering and you have space for the candidates to pick up skills such as this then do not drop or skip the question; pivot the situation into an adaptiveness test.
If the candidate is not familiar with SQL injection largely because modern tooling has abstract it away throughout their career, take a step back and explain the concept to them in 30 seconds.
Then evaluate how quickly they process the new concept:
- How fast do they adapt?
- Are they able to reason where the untrusted input enters a system and the different layers?
- How do they go about in reducing the attack vector once a problem has been explained?
Seniority and engineering capacity are shown through speed of comprehension and system reasoning, not pre-existing trivia knowledge.
4. Updating the Question for 2026: Prompt Injection
If the goal is to test this fundamental concept of untrusted input being executed, using something more relevant to the modern tech stack, replace SQL Injection with Prompt Injection.
In broad strokes the underlying mechanics are very similar:
[ Legacy Paradigm ] User Input ──► Concatenated SQL Query ──► Database Interpreter [ Modern Paradigm ] User Input ──► Concatenated LLM Prompt ──► Model Interpreter
Asking the candidate how they approach the topic of Prompt injection in an AI-enabled feature with human input tests the same fundamentals of security and data flow:
- How do you detect and guardrail input boundaries?
- How do you log potential breaches?
- How do you reduce the effect of untrusted system instructions?
The test follows the same core engineering principle, but it signals that the candidate understands the same fundamental issue but with a modern flair.
5. Check Your Rubric: What Are You Actually Measuring?
Exactly as we mentioned in Part 1, it is important to understand what we are measuring:
- Which attribute or dimension of the Job descriptions does this test?
- If we can’t map this question to a specific rubric metric, what is the purpose of it?
If the result is that this exploit question is there for you to see if someone is able to memorize it, throw the question out. If you are asking it in order to evaluate how they think about data breaches, then update the phrasing and setup so you test their reasoning and not their memory.
The Takeaway
I urge you not to abandon fundamental questions, I am actually a fair believer in them, but don’t ask them like a textbook quiz from 2006.
Regardless of which discipline you are evaluating, the goal of a technical or domain question is not to catch someone out on an implementation detail (unless the job necessitates this). It is to see how they analyze the flow, mitigate the risk and adapt to new concepts.
Modernize your legacy questions and everyone involved in the hiring process including the candidate will thank you for a smoother interview process.