Technical Interview Questions From the Other Side of the Table

Key Points

Before diving in, here’s what this article covers for engineering leaders building or auditing a technical interview process:

• Structured interviews work best when questions are tied to defined competencies and interviewers use a shared scoring approach. Recent research supports the value of structured evaluation for assessing job performance.
• Coding, system design, behavioral, and situational interviews measure different things. Defining the skill and seniority level first turns them from generic interview questions into deliberate assessment tools.
• Trivia and brainteaser-style questions mostly reward memorization and interview practice. If seeing a question before makes it dramatically easier, it’s worth asking whether it belongs in the interview process at all.
• Whether a nearshore partner runs the first technical screen or your internal team runs the entire loop, the same calibration discipline applies: defined skills, written rubrics, consistent scoring, and interviewers trained to the same standard.

Most engineering leaders have seen this one: a candidate who does great in interviews, writes clean code on the whiteboard, designs systems confidently, and tells polished stories in the behavioral round. But once hired and put on the project, that same person struggles to deliver, avoids unclear situations, and needs more support than the junior they were supposed to mentor. The interview gave one impression; the real job revealed something different.

When this happens, it’s easy to blame the interview process, and more specifically, the questions. Teams respond by making the questions harder, spicing up the coding challenges, or adding another round with more interviewers. But usually, the questions aren’t the real problem. It’s more likely that no one decided ahead of time what each question should measure, what a strong answer for the role looks like, or how to score answers consistently. The hiring decision ends up resting mostly on gut feeling, not on evidence calibrated across candidates.

Decades of research suggest that structured interviews are useful predictors of job performance. A major study covering 85 years of personnel-selection research found that structured interviews were substantially more predictive selection methods examined. Google’s own hiring research also emphasized the value of structured behavioral interviews and consistent evaluation rather than relying on individual interviewer judgment.

That gut-feeling approach is expensive at a moment when skilled talent is already difficult to find. Nearly three in four U.S. employers reported difficulty finding the skilled talent they needed in 2025, according to ManpowerGroup’s 2025 U.S. Talent Shortage Survey. A hiring process that can’t distinguish a strong senior engineer from a well-rehearsed one doesn’t just risk a bad hire; it wastes an already scarce and expensive search.

Most of the available advice on technical interview questions is aimed at candidates: what questions to expect, how to practice for them, and how to explain their thinking. This article is for the people doing the hiring, the engineering manager running interviews, the VP trying to improve results after a string of bad hires, and the CTO who wants a consistent signal across teams. 

We’ll look at the same interview question types everyone uses, but from the hiring side: what each one should reveal, what makes an answer strong instead of just rehearsed, and how to build an interview process that gives you better evidence about how someone is likely to perform on the job.

Structure First, Questions Second

Before any question makes it into your interview loop, it should pass a simple test: which competency does it measure, and at what level?

This might sound bureaucratic, but it’s one of the most effective things you can do when designing interviews. List the four to six key skills the role truly needs. For a senior backend engineer, that might include specific programming languages, technical depth in APIs, microservices, or CI/CD, plus problem decomposition and system design skills. 

For each skill, define what “senior” looks like compared to “mid-level,” since the same question can produce a strong answer at different levels. Your interviewers need to know which standard to use and where the bar sits.

Each question in the loop should map to one, or at most two, key skills. That way, every interviewer knows which skill they’re testing, what a strong answer looks like, and how to score it against a shared rubric rather than relying on a gut read. Instead of “we liked them,” you end up with a set of skill scores you can compare across candidates and over time.

This is the heart of structured interviewing, and the evidence is more than a slogan. A 2025 meta-analysis spanning 37 studies and 30,646 participants found that interview evaluations were meaningfully related to both task and contextual performance. The researchers also found evidence that evaluations of contextual performance may particularly benefit from more structured interview scoring.

Once you have this structure, the main types of technical interview questions, coding and algorithms, system design, behavioral, and situational questions, stop being conversation starters and become real measuring instruments.

The Structured Interview Loop

The path from a job description to a hiring decision runs through six deliberate steps, not a single conversation:

What Each Question Type Reveals

Before scoring any answer, it helps to know what each question type is actually measuring, and what a red flag versus a strong signal looks like:

Coding and Algorithm Questions: Watch the Process, Not the Output

Coding challenges should reveal how a candidate thinks through problems in code: how they break them down, reason about data structures, consider complexity, handle edge cases, and ask clarifying questions before writing a line. These challenges aren’t meant to test whether someone has memorized the best answer to a well-known puzzle. If a question only works because the candidate hasn’t seen it before, it’s measuring luck, not skill.

Here are a few examples that hold up well, with the signal each one carries.

“Given a stream of events arriving out of order, design a function that returns the events of the last five minutes in order.”

This tests data structure selection under realistic constraints. A strong candidate asks about volume and what ordering guarantees mean before writing anything. A weak one reaches for a sorted list and starts typing.

“Here is a function that works but is slow on large inputs. Walk me through how you’d find out why, then make it faster.”

This tests complexity reasoning the way it actually shows up at work: profiling and improving existing code rather than producing greenfield solutions. Listen for whether the candidate measures before optimizing, and whether they can articulate the complexity of their improvement instead of just asserting it’s better.

“Write a function that merges two customer records, where fields may conflict.”

This is deliberately underspecified. The entire signal is in what the candidate does with the ambiguity. Strong candidates surface the conflicts and propose rules; they treat the missing specification as the problem. Candidates who silently invent rules and code them up are showing you exactly how they’ll behave with an underspecified ticket.

For all these challenges, how you evaluate the answers matters more than the challenges themselves. Did the candidate ask clarifying questions before coding? Did they state their assumptions? Did they think about edge cases on their own, or only when prompted? Did they explain time and space complexity based on the real input, or just repeat Big O notation without context?

Someone who writes a slightly suboptimal solution while reasoning out loud, naming trade-offs, and catching their own bugs is giving you far more usable signal than someone who quietly writes a flawless answer they may have practiced beforehand.

System Design Questions: Buzzwords Are the Tell

System design questions are meant to test how candidates think about scalability, performance, and especially trade-offs. For senior roles, this part of the interview highlights the difference between engineers with real experience running systems and those who’ve only read about them.

Good prompts are open and grounded:

“Design the backend for a notification system that must deliver to ten million users across email, push, and SMS.”

“We’re seeing p99 latency spikes on a read-heavy API backed by a relational database. Walk me through how you’d diagnose and fix it.”

Or, a favorite for senior candidates:

“Take a system you built. What would break first if traffic grew tenfold, and what would you do about it?”

That last question is hard to rehearse because it requires real history.

To test depth, look for specifics. Anyone can suggest adding caching or a message queue. A senior engineer explains where the cache goes, what gets invalidated and when, what happens if the cache is out of date, and how the queue affects delivery. They point out the trade-offs, such as accepting eventual consistency to improve write performance.

If someone only mentions the tools without discussing the downsides, ask, “What does that decision break?” Candidates with real experience will engage with the question, while those who only know the buzzwords will often repeat them.

Interviewers should avoid pushing candidates toward their own favorite designs. The goal is to measure the candidate’s judgment within the given constraints, not whether they pick the same solution as the interviewer. Scoring should reward clear trade-off reasoning, even if the candidate’s design differs from the usual approach.

Behavioral and Situational Questions: Often the Most Underdesigned Round

After years of reviewing interview processes, I’ve noticed that the behavioral round often gets the least attention in its design, even though it can reveal some of the most important information. For senior hires, it’s rarely coding skills that cause problems; conflict, ambiguity, ownership, or basic communication skills are often the real issues.

Behavioral questions come in two forms, and a good loop uses both. Past-experience questions ask what the candidate actually did:

“Tell me about a technical decision you pushed for that turned out to be wrong. What happened next?”

“Describe a time you disagreed with your manager about technical direction. How was it resolved?”

“Walk me through a project that was failing when you joined it.”

The second type poses hypotheticals:

“You inherit a service with no tests and a release scheduled in three weeks. What do you do in week one?”

“A teammate keeps approving pull requests without reading them. How do you handle it?”

Past-experience questions show what the candidate has actually done, while hypothetical scenarios reveal how they think through problems they might not have faced before. Senior candidates should do well with past-experience questions because they have the background. For people switching careers or moving up, this format helps you test their judgment when their prior experience doesn’t cover everything.

The STAR method (situation, task, action, result) helps you score answers; it isn’t a script the candidate must follow. Check whether the answer includes a real situation, a clear personal action, and a visible result. Rehearsed candidates often give great situations but vague actions, using “we” instead of “I.”

Ask, “What did you specifically do?”

If their story falls apart, they probably weren’t really responsible. But don’t penalize candidates for not following the STAR format perfectly. Use it to understand their answers, not as a performance they have to give.

A Word About AI

Two distinct questions sit under this topic, and they deserve separate answers.

1. Candidates using AI assistance during interviews. If your loop runs remotely and your coding questions are generic, you should assume that some candidates may use model-generated answers in real time. The defense isn’t surveillance; it’s the selection and design of questions.
   
   Questions anchored in the candidate’s own history, such as “a system you built” or “a decision you regretted,” and live dialogue, such as “what does that decision break?”, are hard to outsource mid-conversation. Pure puzzle questions are much easier to outsource, which is one more argument against them.

2. Should you test for AI fluency? Increasingly, the answer is yes, since your engineers will use these tools in their day-to-day work. One practical approach is to give the candidate an AI-generated solution and ask them to review it.
   
   Look for whether they check the answer instead of trusting it, spot subtle bugs, and explain when they would or wouldn’t rely on a model. An engineer who treats AI output like a senior reviewing a junior’s pull request, helpful and quick, but always checked, is showing the kind of judgment that matters when AI becomes part of the normal engineering workflow.

Questions to Skip

Some questions hurt your ability to get useful signal and hurt your chances of landing good candidates, not to mention the reputational cost among job seekers.

Trivia questions like “What’s the default heap size of the JVM?” test memorization and penalize candidates who’d normally just look up the answer. Gotchas and brainteasers mostly measure how much someone has practiced puzzles, not their technical knowledge. Google reached a similar conclusion in 2013, when its own hiring team moved away from brainteaser-style questions after finding that they weren’t useful predictors of job performance.

Research has long raised questions about the predictive value of brainteaser-style interview questions. If you’re using them because they make candidates uncomfortable or because they seem difficult, that’s a poor substitute for measuring the technical skills, problem-solving abilities, and judgment the role actually requires.

And if you’re pulling questions from popular lists, serious candidates may already have practiced them. You’re then testing preparation as much as skill. If a question becomes dramatically easier once someone has seen it before, it doesn’t belong in your interview process.

The Primary Signal Is the Reasoning

In every type of interview question, the clearest signs are often small and behavioral. Does the candidate ask clarifying questions before answering? Do they explain their thinking so you can follow their reasoning, not just see the final answer? How do they react when they don’t know something?

That last point should be a clear part of your scoring. A candidate who says, “I don’t know how that works internally, but here’s how I’d find out, here’s what I’d test first, and here’s what I’d expect to see,” is quite often giving you more useful evidence than someone who simply guesses the right answer.

The first person shows how they handle the uncertainty that’s common in real engineering work. The second may simply have known the answer.

Make sure your interviewers understand the difference. It’s easy to reward a confident guess over an honest approach, especially when the interviewer already has a favorable impression of the candidate.

What Strong Reasoning Looks Like

When a Partner Runs Part of the Loop

If a nearshore engineering partner handles your first technical screen, or you interview candidates together, use the same calibration process, just at a higher level.

Before you trust their screening, check three things: their questions should match your required skills, not just come from a generic list; they should use a written rubric you’ve reviewed; and their interviewers should be trained to your standards for the role.

A good partner can show you their rubric and walk through a scored example. If all you get back is “strong candidate, good communication skills,” that’s vague, unspecific feedback, and you’ll notice the gap during onboarding.

The same discipline that makes your own interview loop reliable is exactly what you should expect from a partner running part of it. You should also periodically compare the partner’s interview assessments with how candidates actually perform after joining the team. If the strongest interview scores don’t correspond to stronger performance, the problem may be the screening criteria, the scoring, or the calibration itself.

Make the Interview Resemble the Job

Before your next interview loop, run through this checklist.

None of this makes interviewing easy. But it makes it measurable, which is better.

The goal isn’t to create a harder interview. It isn’t to find a cleverer coding puzzle or add another interviewer just to make the process feel rigorous. The goal is to collect better evidence about whether someone has the technical skills, problem-solving abilities, judgment, communication skills, and prior experience the job actually requires.

A structured, calibrated loop gives you a much better basis for identifying the candidates most likely to succeed on your team. The quality of the hiring decision depends less on the elegance of any individual question than on whether the entire process measures what matters.