How to Interview Engineers: What to Ask Beyond LeetCode

2026-07-15 · 8 min read · Hiring & Onboarding

The standard engineering interview looks roughly like this: a series of algorithmic problems that require memorised data structures and pattern recognition, often on a whiteboard or in a code editor with syntax highlighting disabled, timed to 30 or 45 minutes, evaluated by someone who Googled the solution before the interview.

This process is widespread. It is also a poor predictor of whether someone will do good engineering work on your team.

The evidence on this is reasonably clear: algorithmic puzzle performance correlates weakly with job performance in software roles that don't involve designing algorithms. The skills required to pass a LeetCode hard question — memorising algorithm families, solving under time pressure, performing under observation — are largely orthogonal to the skills required to design a feature, review a PR, debug a production issue, or work effectively with a team.

If you're an engineering manager who has influence over your hiring process, here's a better approach.

Start With What the Job Actually Requires

Before designing interview questions, write down what good performance looks like in the specific role. For most engineering roles, this includes:

• Ability to break down ambiguous problems into clear requirements
• Writing code that other people can maintain and understand
• Finding and fixing bugs in existing systems
• Communicating technical tradeoffs clearly
• Working effectively with collaborators

Your interview process should test these things. A 45-minute dynamic programming problem tests none of them.

The Take-Home Project

One of the most effective interview components is a realistic take-home project. Candidates work in their own environment, with access to documentation and search engines (as they would in any real job), and produce something they can explain and discuss.

A good take-home project:

• Takes 2–4 hours, not 10 (longer projects filter for availability, not ability)
• Mirrors real work — a small feature, a debugging exercise, a code review of something broken
• Has multiple valid approaches so you can discuss trade-offs rather than compare against a perfect answer
• Is accompanied by clear instructions about what you're evaluating

What you're looking for in the submission isn't perfection. You're looking for how they think: what assumptions did they make and did they make them explicit? Did they write tests? Is the code readable? Did they identify the things they left out? A submission with a clear README explaining trade-offs and limitations often reveals more than clean code with no reflection.

Follow up with a discussion session. Ask them to walk you through their thinking. "Why did you approach it this way?" "What would you change if you had more time?" "What did you consider and decide not to do?" The reasoning matters more than the output.

The System Design Conversation

For senior roles especially, a system design conversation is valuable — but it needs to be conducted well to be useful.

The goal is not to see if they can regurgitate a particular architecture pattern. It's to see how they think through a problem:

• Do they ask clarifying questions before diving into solutions?
• Do they think about scale and constraints appropriately for the context?
• Can they communicate trade-offs clearly?
• Are they open to challenge and willing to change direction when given new information?

Good prompts for system design are open-ended and realistic: "Walk me through how you'd design a notification system for a platform with a million users." The best candidates ask questions like "What kinds of notifications? What latency requirements? What's the budget for infrastructure?" before drawing any boxes.

Evaluate the conversation, not the conclusion. Two engineers might arrive at different designs for the same prompt — both could be excellent.

Behavioural Questions That Actually Reveal Things

Behavioural questions are often poorly designed: "Tell me about a time you showed leadership" produces rehearsed answers that reveal little. Better behavioural questions are specific, probe for real events, and dig into the uncomfortable details.

Questions that work well:

"Tell me about a project that failed or went significantly worse than expected. What happened and what did you learn?" This reveals self-awareness, honesty, and how they process failure. Candidates who can't identify a failure are concerning. Candidates who describe failure without any reflection about their own role are concerning. Candidates who can clearly explain what went wrong, their part in it, and what they'd do differently are often excellent.

"Describe a technical disagreement you had with a teammate or manager. How did you handle it?" This reveals how they engage with conflict, whether they can distinguish technical correctness from personal dynamics, and whether they're capable of changing their mind.

"Tell me about a time you had to push back on a requirement or deadline. How did you make the case?" This reveals communication style, ability to manage up, and how they handle pressure.

For each behavioural question, follow up with specifics: "What did you actually say?" "What did they say back?" "What happened after?" Surface the details that distinguish a real memory from a polished answer.

The Code Review Exercise

If your team does code reviews (and it should), consider adding a code review exercise to the interview process. Present the candidate with a PR — a real one from your codebase, ideally, with names removed — and ask them to review it.

This tests:

• Can they identify substantive issues versus cosmetic ones?
• Do they communicate feedback constructively?
• Do they understand the codebase well enough to evaluate the change in context?
• What do they prioritise when reviewing?

It also gives you directly useful information about how they'll participate in one of the most important team practices.

The Question of Culture Fit

"Culture fit" is a phrase that often functions as cover for bias. It's worth being clear about what you actually mean when you use it.

What you're probably trying to evaluate:

• Do they communicate clearly?
• Do they engage honestly, including when they disagree?
• Can they give and receive feedback constructively?
• Do they seem motivated by the kind of work this role involves?

These things can be evaluated with specific questions and observations, not vibes. Ask about communication style explicitly. Observe how they handle challenge in the technical conversation. "Tell me about the environment you've worked best in" often reveals more than "are you a team player?"

The Candidate's Experience

The best candidates are evaluating you as much as you're evaluating them. An interview process that's disrespectful of their time, poorly explained, or that tests irrelevant skills will filter out good engineers who have options.

Set expectations clearly upfront: what stages, what you're evaluating, how long it takes. Give real feedback when you can. Thank them for the take-home project, because it took real time. And if you're asking them to solve problems, make sure those problems are worth solving.

The interview process is a signal about what it's like to work with your team. Make it reflect how you actually want to operate.