How we interview senior engineers

The Problem with Technical Interviews

Most engineering interviews are theater. Candidates solve algorithmic puzzles that have no bearing on their daily work. Interviewers ask trivia questions about language internals that can be looked up in 30 seconds. The process selects for people who are good at interviews, not people who are good at building software.

We've seen brilliant engineers fail whiteboard interviews because they think better with an IDE. We've seen mediocre engineers ace algorithm challenges because they've memorized LeetCode patterns. The signal-to-noise ratio is terrible.

Our approach tests for what actually matters in the job:

• Can they design systems that work at scale?
• Can they communicate trade-offs clearly?
• Can they collaborate under pressure?
• Can they learn new domains quickly?

Step 1: The Portfolio Review (30 min)

Before any technical discussion, we review the candidate's portfolio. Not their resume — their actual work. GitHub repos, deployed projects, blog posts, open-source contributions. We're looking for evidence of building, not evidence of attending.

What We Look For

• Shipped products — Has this person built something that real users interact with?
• Code quality — Is the code readable, tested, and well-structured?
• Technical depth — Do they understand the "why" behind their architectural choices?
• Communication — Can they explain complex systems clearly in writing?

Red Flags

• GitHub profiles full of forked repos with no original work
• Projects that are clearly tutorials, not original problem-solving
• No evidence of working with other people's code
• Resume lists technologies but no shipped products

Green Flags

• Side projects that solve real problems (even small ones)
• Open-source contributions with thoughtful PR descriptions
• Blog posts explaining technical decisions
• Evidence of iterating — projects that evolved over time

Step 2: The System Design Conversation (60 min)

This is the core of our interview. We present a real system design challenge — something we've actually built or are currently building. The candidate designs the system while we discuss trade-offs. It's a conversation, not a test.

The Format

We pick a domain the candidate is familiar with but haven't solved in exactly this way. For example:

• "Design a real-time inventory system for a pharmacy chain with 500 locations"
• "Design a FHIR integration layer that handles 10,000 patient lookups per second"
• "Design a multi-tenant SaaS platform where each tenant has custom data schemas"

What We're Evaluating

• Requirements gathering — Do they ask clarifying questions before jumping to solutions?
• Trade-off awareness — Can they articulate the cost of each decision?
• Depth of knowledge — Do they understand the systems at the implementation level?
• Pragmatism — Do they design for the actual requirements, or over-engineer?
• Communication — Can they explain their thinking to a non-expert?

The Key Question

At some point, we always ask: "What would you change if the requirements were X instead of Y?" This reveals whether the candidate understands the design space or just pattern-matched to a memorized architecture.

What We Don't Care About

• The specific technology choices — we care about the reasoning
• Whether they get the "right" answer — there isn't one
• How fast they draw diagrams — clarity matters, speed doesn't
• Whether they've used our specific stack — stacks are learned in weeks

Step 3: The Pair Programming Session (45 min)

We sit down with the candidate and work on a small, real problem together. Not a toy algorithm — a simplified version of something we're actually dealing with. The candidate drives, we navigate (or vice versa).

What We're Evaluating

• Collaboration — Do they incorporate feedback gracefully?
• Code quality under pressure — Do they maintain standards when the clock is ticking?
• Tool proficiency — Are they comfortable in their development environment?
• Debugging approach — How do they diagnose problems? Systematic or shotgun?
• Communication — Do they think aloud? Do they explain their reasoning?

Example Tasks

• "This API endpoint has a performance issue. Let's diagnose it together."
• "We need to add a new field to this data model. Let's think through the migration."
• "This test is flaky. Let's figure out why and fix it."
• "We need to refactor this function to handle a new edge case. Let's do it."

The Anti-Pattern

We explicitly avoid "whiteboard coding" — writing algorithms on a whiteboard without an editor. It tests memory recall and syntax knowledge, not engineering ability. Engineers use editors, linters, autocomplete, and documentation. The interview should reflect reality.

Step 4: The Values Conversation (30 min)

The final step isn't technical. It's about alignment. We discuss how the candidate approaches work, conflict, learning, and growth. This conversation happens with a senior engineer, not a recruiter.

Questions We Ask

• "Tell me about a time you disagreed with a technical decision. What did you do?" — Tests whether they can disagree and commit, or whether they escalate every disagreement.
• "What's something you've changed your mind about technically in the last year?" — Tests intellectual humility and growth mindset.
• "How do you decide when to take on tech debt?" — Tests pragmatism and judgment.
• "What would you do differently if you joined our team?" — Tests whether they've thought about our context or are just looking for any job.

What We're Looking For

• Self-awareness — Do they know their strengths and weaknesses?
• Collaboration instinct — Do they think in terms of "we" or "I"?
• Intellectual curiosity — Are they genuinely interested in the craft?
• Pragmatism — Do they balance idealism with shipping reality?

The Dealbreaker

We've passed on candidates who aced every technical step but failed this conversation. The best technical skills in the world don't matter if someone can't collaborate, communicate, or grow. Culture fit isn't about personality — it's about how you work.

The Decision

After all four steps, the interviewers meet for 15 minutes to discuss. Each step has a clear rubric, but the final decision is holistic. We ask one question: "Would I want to work on a production incident with this person at 2 AM?"

If the answer is yes from all interviewers, we extend an offer. If it's mixed, we discuss specifics. If it's no, we decline quickly and respectfully — no ghosting, no radio silence.

The entire process, from first contact to offer, takes about two weeks. We respect the candidate's time. We respect our team's time. And we make decisions based on evidence, not vibes.

Conclusion

Hiring is the most important thing a small team does. A bad hire sets the team back months. A good hire multiplies the team's output for years. The process should be rigorous enough to filter reliably, fast enough to respect everyone's time, and human enough to make candidates want to work with you regardless of the outcome.

Our four-step process — portfolio review, system design, pair programming, values conversation — consistently identifies engineers who ship. Not because it's clever, but because it tests for the actual skills the job requires.

The best engineers we've hired weren't the ones who solved the hardest algorithm problem. They were the ones who explained their thinking clearly, collaborated naturally, and showed genuine curiosity about the problems we're solving.