Two engineers can interview the same candidate, ask completely different questions, and come away with opposite recommendations. One asked algorithm puzzles, the other asked system design, and neither one was actually testing for what the role needs. The candidate gets two strong opinions and one bad hiring decision.

This article gives you a structured question bank for engineering interviews, organized by what you're actually trying to assess and by seniority level. Use it inside a structured interview, not as a grab bag of questions to pick from on the fly.

A note on context. These questions are designed for SMB engineering hiring, where you're typically looking for engineers who can ship in a small team, handle ambiguity, and own outcomes. The bar is different from FAANG hiring, where the playbook is heavier on algorithms and large-scale system design. Match your questions to your context, not to the interview style of companies you're not.

Before you ask anything: define what you're hiring for

Three things genuinely predict engineering performance in a small team setting.

Technical competence in the relevant stack. Can they actually build the thing? This is the obvious one but it's also the most often poorly tested. A whiteboard algorithm doesn't prove they can ship a feature.

Judgment under ambiguity. Engineering at small companies involves a constant stream of underspecified problems. Senior engineers who can navigate ambiguity outperform brilliant engineers who need perfect specifications.

Collaboration and communication. Especially in a small team, an engineer who can't communicate clearly with PMs, designers, and other engineers is a tax on everyone. This is often dismissed as "soft skills" and dramatically underweighted.

Build your interview to test all three. Skipping any of them is how teams hire engineers who pass interviews but don't perform.

A workable interview structure for engineering hires

For most SMB engineering roles, this structure works well:

Phone screen (30 min): Background, motivation, basic technical fit
Hiring manager interview (45 min): Past experience, judgment, ownership
Technical exercise (60-90 min): Practical coding or system design, not a whiteboard algorithm
Cross-functional interview (45 min): Collaboration with PM, design, other engineering
Founder or leadership conversation (30 min): Final fit and motivation

For senior or staff hires, replace round 3 with a system design or architecture conversation, and add a round on leadership and influence.

Phone screen questions (engineering-specific)

The general phone screen approach in Questions to Ask in a Phone Screen (Template Included) applies. Add these engineering-specific questions in the 10 minutes of core screening.

Walk me through the most recent significant project you shipped. What did you specifically build?
What does your current stack look like? Where are you most comfortable, and where are the edges?
What are you looking to learn or work on in your next role?

What to listen for: Specificity. Strong candidates describe what they actually built and the technical trade-offs they made. Weak candidates describe team outcomes without showing what they did.

Hiring manager interview questions

This is where you assess judgment, ownership, and how the engineer actually works. It's mostly behavioral, with some scenario-based exploration.

Past behavior and ownership

Walk me through a technical decision you made that you'd make differently now. What did you learn?
Tell me about a bug or incident that took you longer than expected to solve. What was hard about it?
Describe a project where you took ownership of something outside your formal scope.
Tell me about a time you disagreed with a teammate about an engineering decision. How did it resolve?

What to listen for: The first question is the strongest. Strong engineers can articulate exactly what they got wrong and why. Weak engineers describe trajectories with no real mistakes, or blame circumstances.

Working in ambiguity

Tell me about a time you were asked to build something and the requirements were unclear. How did you proceed?
Describe a project where the right approach wasn't obvious. How did you decide what to do?
Walk me through how you approach a problem you've never solved before.

What to listen for: Whether they push for clarity, build prototypes to learn, or just start coding. Strong engineers reason about what they don't know before committing.

Collaboration and communication

Tell me about a time you worked closely with a PM or designer on something complicated. How did the collaboration go?
Describe how you usually handle code review. What kind of feedback do you give and how do you receive it?
Walk me through a time you had to explain something technical to a non-technical stakeholder.

What to listen for: Whether they treat non-engineers as partners or obstacles. Senior engineers know that PM-engineer collaboration is most of the job.

Technical exercise: what to do instead of whiteboard algorithms

Algorithm puzzles on whiteboards are a poor signal for SMB engineering hiring. They test memorization of CS curriculum more than they test what your engineers will actually do.

Better alternatives:

Pair programming on a realistic problem. Give the candidate a small, realistic problem. Pair with them for 60 minutes. Let them ask questions, use Google, and reason out loud. You're testing how they think and how they work with others, not whether they can recite the solution to a classic problem.

Take-home exercise. A small, scoped exercise the candidate completes in their own time (2-4 hours, paid if you can). Then a 60-minute review session where they walk you through their solution and you discuss trade-offs.

Bug hunt. Give them an intentionally broken piece of code in your codebase (or a representative example). Ask them to find and fix the issues. Tests debugging, code reading, and judgment about what matters.

Live coding on a small feature. Build a small feature together over 60 minutes. Realistic, low-pressure, and tests the actual skill of writing working software.

The strongest signal across all formats: the candidate's reasoning out loud, the questions they ask, and how they handle being uncertain. Don't just evaluate the code, evaluate the conversation.

System design questions for senior and staff engineers

For senior engineers and above, system design is one of the strongest signals. The point isn't to test whether they've memorized a standard design. It's to see how they think through trade-offs.

Starter prompts

Walk me through how you'd design a system for [a realistic problem from your domain].
Imagine we're building [feature X]. How would you architect it for our current scale, and how would you plan for 10x growth?
Here's a real architectural problem we've faced. How would you have approached it?

The third one is the strongest. Use a real problem from your team's recent history. You'll learn whether the candidate would have made better decisions than you did.

What to listen for

Do they ask clarifying questions before designing? Strong candidates always do.
Do they reason about trade-offs out loud? Good design conversations are full of "we could do X, but the trade-off is Y."
Do they recognize complexity they're introducing and call it out?
When you push back on their design, do they defend it thoughtfully or capitulate immediately? Both are useful signal.

Avoid grading on whether they got to "the right answer." There usually isn't one. Grade on the quality of the conversation.

Interview questions by seniority

The questions above apply across levels, but here's how to weight them.

Junior engineers (0-3 years)

Emphasize:

Coachability and self-awareness
Curiosity and willingness to learn
Basic technical competence in the core stack
Communication clarity

De-emphasize:

System design depth
Track record of major projects
Cross-functional leadership

Add:

"Tell me about something you've built outside of work that you're proud of."
"Walk me through a recent thing you've learned. How did you go about learning it?"
"Describe a time someone gave you feedback on your code. What did you do with it?"

Senior engineers (4-8 years)

Emphasize:

Judgment under ambiguity
Ownership of outcomes, not just tasks
Trade-off reasoning in system design
Mentorship and code review skills

De-emphasize:

Algorithm puzzles
Demonstrations of pure technical depth (unless directly relevant)

Add:

"Tell me about an architectural decision you've owned. What were the trade-offs?"
"Describe a time you had to make a call on whether to refactor or build forward. How did you decide?"
"Walk me through how you'd onboard a new engineer to a project you've been leading."

Staff and principal engineers

Emphasize:

Strategic thinking about engineering organization
Influence and leadership without formal authority
Major architectural decisions and their outcomes
Ability to operate across teams

Add:

"Tell me about a major technical decision you've influenced across multiple teams."
"Walk me through a time you've changed how an engineering org operates."
"Describe a technical debt situation you've navigated. How did you decide what to fix and what to leave?"

Red flags to watch for

A few patterns to watch for across engineering interviews.

Inability to describe what they specifically built. Engineers who can't separate their work from the team's work usually weren't doing much of the work.

Treating all problems as algorithm problems. Engineers who reach for clever data structures when the actual challenge is product judgment often build things nobody needs.

No examples of failure or learning. Senior engineers who've never made a mistake either haven't shipped enough or aren't being honest.

Dismissive of PM and design. Engineers who frame non-engineers as obstacles tend to be hard to work with regardless of their technical depth.

Over-engineering instinct. Watch for candidates who, when asked to build something simple, immediately propose Kubernetes, microservices, and event-driven architecture. Strong engineers right-size their solutions.

Build your engineering interview guide

Engineering hiring is high-variance enough without inconsistent interviews on top. Use the same questions for every candidate at the same level, score with a rubric, and debrief the scores.

Build your free interview guide with Oryx