“What’s the difference between REST and GraphQL?”
If your technical interviews still sound like this, you’re probably testing what candidates can memorise, not how they actually solve problems.
But in the world of AI-assisted engineering, what really matters is how people think through problems, not just what they know. The Traffic Light Method is a simple interview framework that helps you assess exactly that.
What is a technical interview?
A technical interview is a discussion used to evaluate whether a candidate has the technical skills to succeed in a given role. It’s not a single test with one right answer. At its core, it’s a conversation where the goal is figuring out whether a person will meaningfully add to your team’s work.
There are a few common ways to run one:
- A standardised list of technical questions, or a tool that structures the discussion for you.
- Asking candidates to talk through a hypothetical system design, like designing a URL shortener.
- Giving candidates a sample of code to review ahead of time, and using that as the basis for the conversation.
- Recommended: A list of follow-up questions based on the candidates’ take-home assignment.
Whichever format you choose, it should tell you whether this person will actually contribute to your team’s work, not just whether they can answer questions well. This is one part of the broader technical vetting process, a technical interview is a single conversation; vetting is everything around it.
The pros and cons of the technical interview
How developers communicate in an interview and how they tackle technical problems can give you a good sense of whether they’ll be a good addition to your team culture.
But the format has real limits too: its effectiveness depends entirely on the strength of the questions you ask, and your interviewer needs in-depth technical knowledge, a thorough understanding of the role’s requirements, and sharp interview skills to drive the discussion.
Advantages of a technical interview
- Fast and convenient for developers and hiring teams, which can prevent drop-off in the pipeline.
- It can indicate whether the candidate will be a good addition to your team culture.
- It shows you how a candidate approached their assessment, the trade-offs, and how they think through technical problems.
Disadvantages of a technical interview
- The interviewer must have good technical and interview skills for it to be effective.
- It requires extensive initial training and preparation for the interview team.
- Pre-interview nerves might get in the way of someone giving a good response.
How is AI changing the role of the technical interview?
As AI makes it easier to produce a working solution, the live conversation carries more weight than it used to. A candidate’s take-home code doesn’t tell you as much by itself anymore.
So, what you learn from watching someone think in real time, how they defend a decision, and respond to a question they didn’t prepare for, have become far more important indicators of their fit, both technically and culturally.
That’s not a small shift. The interview isn’t just a formality that happens after the assignment anymore. Now, it’s where the real evaluation happens. Which means the questions worth asking have to be built around decisions and trade-offs, not definitions and recall.
What should interview questions for software engineers cover?
At OfferZen, we use a framework to sort interview questions into what actually works. We call it the Traffic Light Method.
Every question is graded as poor, better, or strong based on how it’s tied to the candidate’s actual decisions, and how much room it leaves for a real back-and-forth conversation.
Here, we look at a few things technical questions should help to determine and what separates a poor question from a better or strong one.
1. Assess for fit
The goal here is to find out whether a candidate can reason about a decision that actually matters to your team. A question is only doing its job if a wrong answer and a right answer would actually look different in practice.
Poor
“What’s the difference between REST and GraphQL?”
This is purely a definitions question. A candidate can answer this correctly and still have no idea how to make the call in a real system.
Better
“When would you choose GraphQL over REST for a new API?”
This gets closer to testing judgement, but it’s still hypothetical as there’s no real decision behind it to defend.
Strong
“You chose to return a 200 with an error object here instead of a 4xx status code. Walk me through that call, and what would change your mind?”
This is strong because it’s tied to something they actually built, with a real trade-off behind it.
2. Getting past the first answer
Most of the signal in an interview doesn’t come from the first thing a candidate says; rather, it comes from whether they can hold up when you push on it.
This category is less about which question you ask and more about what you do once you’ve asked it: whether you treat the first answer as the end of the conversation, or as an opening you can dig into.
A good interviewer treats the first answer as a starting point for a real conversation.
Poor
“How do you decide when to refactor versus ship?”
This is a reasonable opening question, but there’s nowhere for it to go from here if the interviewer doesn’t push.
Better
“How do you decide when to refactor versus ship?” → “I look at how messy the code’s gotten.” → “Makes sense, next question.”
Here, there’s a reasonable opening answer that the interviewer just accepts, so it never actually goes anywhere.
Strong
Same question, but followed by: “Say the deadline moved up by a week. Would that change your answer, and at what point would it?”
This turns a generic answer into a real trade-off, and shows whether the candidate has actually thought about the boundary, not just the default.
3. Focus on practical understanding
If a candidate hasn’t heard of a specific term, that’s not automatically a problem. What matters is whether they can reason through the underlying issue when you describe it in plain language.
Poor
“What is a race condition?”
This tests recall of a definition, not whether they’d actually catch one in practice.
Better
- “What is a race condition?”
- “Not sure, haven’t come across that term.”
- “OK, moving on.”
Here we’ve got a vocabulary check dressed up as a technical question, and the interviewer drops it the moment the candidate doesn’t know the term.
Strong
“Say two requests hit this endpoint at exactly the same time and both try to update the same row. What happens? How would you even notice if it went wrong?”
Now, the interviewer is surfacing the same underlying understanding whether or not the candidate knows the textbook name for it.
4. Judging an AI-assisted decision, not just the outcome
This is the newest category, and probably the most important one right now. As AI takes on more of the actual typing, the question worth asking isn’t whether a candidate used it, that’s assumed at this point, it’s whether they can explain and defend the specific calls they made while using it.
A candidate who can’t tell you why they accepted one AI suggestion over another hasn’t really been driving the work.
Poor
“Did you use AI to write this?”
It’s poor because it’s a simple yes/no question that tells you nothing about how they actually used it.
Better
“Which parts of this did AI generate?”
This is tied to the code, but stays at inventory-level; it tells you what happened, not whether it was the right call.
Strong
“You accepted the AI’s suggestion to cache this in memory rather than in Redis. What would make you go back and change that call?”
This probes the actual decision and whether they understand its trade-off, not just whether they can identify what AI wrote.
Want the full framework?
OfferZen’s Technical Assessment Toolkit helps your team assess next-gen engineers more easily. It includes a checklist for designing high-signal take-home assignments, a template for scoping the brief by seniority, and an evaluation rubric your whole panel can use to compare applicants consistently.
What makes a good answer to a technical interview question?
A good answer isn’t necessarily the most confident one. A good answer shows the reasoning behind a decision, including the parts the candidate got wrong.
The strongest answers tend to have a shape:
- Here’s what I chose.
- Here’s why I chose it.
- Here’s what I’d reconsider given more time or new information.
A suggestion for evaluating answers to a technical question
It helps to write down more than a one-line verdict when you’re taking notes. Something like “good understanding of caching” is nearly useless when you’re comparing candidates a week later.
Compare that with: “chose Redis over an in-memory cache to support running multiple instances, acknowledged the operational overhead, hadn’t considered staleness during long-running transactions but reasoned through a fix when prompted.”
That tells you the decision, the trade-off, and where the gap was.
It’s also worth listening for the difference between someone who deeply understands an area and someone who’s using the right buzzwords without much behind them. The way to tell the difference is to keep asking why.
Should technical interview questions differ by seniority?
Yes. Junior candidates tend to benefit from more structure, clearer acceptance criteria, and questions with a defined right answer they can build toward.
On the other hand, senior candidates need more ambiguity, more room to challenge the brief itself, and questions that test judgement under looser constraints.
Your rubric should reflect this explicitly. The depth of explanation you expect from a junior candidate is different to what you’d expect from someone more senior, and grading everyone against the same bar either lets junior candidates off too easily, or unfairly penalises them for not having the experience to reason like a senior yet.
How many questions should a technical interview include, and how long should it run?
Generally, it’s best to keep it tight. Around an hour is often the sweet spot and it should need little preparation required from either side beforehand.
A handful of well-chosen questions, explored properly with follow-ups, will tell you more than a long list asked once each and never pushed on.
A lengthy, poorly communicated hiring process is one of developers’ biggest complaints in South Africa.
Time-boxing the interview protects both your team’s schedule and helps keep strong candidates from dropping out of your pipeline.
Are whiteboard-style questions still worth asking?
The short answer: not on their own. A whiteboard-style question like “tell me the difference between write-through and write-behind caching” is poor because it’s disconnected from any actual work the candidate has done, and it’s easy to answer well by memorising the right words without being able to apply them.
If a candidate doesn’t know a term, that’s not automatically a red flag. What matters is whether they can reason through the underlying problem when you describe it in plain language instead.
Someone who’s never heard of “optimistic locking” but immediately spots the problem when you describe two people editing the same record is showing you more than someone who can recite the definition.
How do you interview for soft skills alongside technical skills?
The interview itself is a soft-skills test, whether you name it that or not. How someone communicates a disagreement, takes feedback on a decision, or admits they got something wrong tells you as much about how they’ll work with your team as any technical answer will.
How do you choose a panel for a technical interview?
Choose your panel as deliberately as you choose your questions. Seniority is not the most important quality in interviewers. The best people to have in the room are good communicators who can dig past a surface-level answer.
Generally, you want enough senior developers on the panel to have the technical depth to push back credibly, but you also want people who put candidates at ease early, with a few easier, general questions before moving into the harder material.
What technical interview questions are outdated now that candidates use AI?
Any question whose main job was testing memorised syntax or textbook definitions is on its way out.
If AI can answer it correctly without the candidate understanding why, it isn’t testing what you need it to test anymore. That includes:
- Pure recall questions (“name the levels of the testing pyramid”) with no follow-up.
- Questions that quietly assume a candidate hasn’t used AI at all, and penalise them for having.
- Anything that rewards a fast, confident-sounding answer over one that’s actually been reasoned through.
What replaces them isn’t a totally different question bank. It’s the same question, asked differently. They should be tied to a real decision or trade-off and with room to keep pushing past the first answer.
Frequently asked questions about technical interviews
1. What are good technical interview questions for data analyst roles?
Good technical interview questions for data analyst roles focus on how someone approaches a messy, real dataset. For example, how they’d validate a surprising result, which query they’d write to answer a specific business question, or how they’d explain a finding to someone non-technical.
The Traffic Light Method applies here too, asking about a dataset or dashboard they’ve actually built, and not SQL syntax in the abstract.
2. What should technical interview questions for data engineer roles cover?
Technical interview questions for data engineer roles should focus on pipeline design decisions: how they’d handle a schema change without breaking downstream consumers, how they’d choose between batch and streaming for a given use case, and how they’d catch a silent data quality issue before it reaches production.
3. What are useful interview questions for a database developer?
Useful interview questions for a database developer centre on trade-offs. Indexing strategy, when to denormalise, and how they’d approach a slow query in a system they didn’t design.
Ask them to walk through an actual query plan rather than define normal forms from memory.
4. What should interview questions for ETL developer roles cover?
Interview questions for ETL developer roles should cover how someone handles failure: what happens when a source system changes format mid-pipeline, how they’d design for idempotency, and how they’d debug a job that’s silently dropping records.
5. What are good interview questions for .NET developer roles?
Good interview questions for .NET developer roles focus on how someone structures and maintains a codebase over time. This can include how they made a specific architectural decision, dependency injection, or an async pattern.
6. What should interview questions for Python developer roles include?
Interview questions for Python developer roles should include a real code review. For example, given a working script, ask what they’d refactor, and where they’d add error handling, and why.
7. What about technical interview questions for AI engineer roles?
This is a fast-moving area and we’re still refining our own view on it. For now, it looks a lot like the rest of this framework in that they should test judgement over recall. Moreover, they should be focused on how someone evaluates and directs a model rather than which tools they used.
How does OfferZen combine take-home assignments and interviews today?
Our own process has changed since we first wrote about technical interviews. We used to run interviews off a short code sample sent ahead of time. Today, the take-home assignment and the interview work together: candidates submit a video walkthrough of their work as the main deliverable, and we use the interview to test whether they can defend that work live.
We read the code and watch the video ahead of time, then ask the candidate to walk us through a section of their own code, and check whether the explanation and the video line up.
We’re not looking for a bug-free submission, most people are working under real time pressure, we’re looking for whether someone’s honest when something’s wrong, and whether they can reason their way to a fix on the spot.
If you’re building your own version of this process, it’s worth running through a quick check on your own interviewing before you sit down with a candidate.
Putting this into practice
Here are a few things worth having in place before your next interview:
- A scorecard and rubric, so your team is aligned on what a good answer looks like before anyone’s in the room, calibrated by seniority.
- A diverse panel of strong communicators, not just your most senior engineers.
- A clear brief sent to candidates ahead of time: what you’re evaluating, how the session will run, and why the problem is relevant to the work they’d actually do.
- A round of mock interviews for anyone new to interviewing, with real-time feedback, before they run one for real.
What this means for your next interview
The interview was never really about the whiteboard, or the code sample, or the assignment. It’s about whether you’d trust this person’s judgement on your team. AI has just made that easier to test directly, and harder to fake.
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.