Technical Interviews Are Broken — Here's What We Do Instead

The Interview Industrial Complex

The standard technical interview: a nervous engineer stands at a whiteboard implementing a binary tree traversal while three people watch and judge. The engineer who aces this test joins the team and spends the next two years writing CRUD APIs and debugging CSS. The one who failed? They were building production systems at their last job but couldn't remember the optimal solution to a problem they'll never encounter at work.

This process is broken. And it's costing you the engineers you actually need.

What Traditional Interviews Measure vs What You Need

Our Interview Process

Stage 1: Resume + Portfolio Review (15 Minutes)

Before any calls, we review:

• What they've built (not where they worked)
• Their GitHub, blog posts, or public work
• Specific technologies they've used in production

What we're looking for: Evidence of shipping real things. Not credentials, not company names — evidence of building.

Stage 2: Technical Conversation (45 Minutes)

Not a test. A conversation between engineers about their experience:

Format:
  10 min: "Tell me about the most complex system you've built"
  15 min: Deep-dive into their answer (architecture, tradeoffs, failures)
  15 min: "Here's a problem we're solving — how would you approach it?"
  5 min: Their questions

What we're evaluating:
  ✅ Can they explain technical decisions clearly?
  ✅ Do they talk about tradeoffs, not just solutions?
  ✅ Do they acknowledge failures and what they learned?
  ✅ Can they think through a new problem out loud?
  ✅ Do they ask good clarifying questions?

Red flags:
  ❌ Can't explain why they made architectural decisions
  ❌ Every project was "perfect" with no issues
  ❌ Jumps to implementation without understanding the problem
  ❌ Can't discuss tradeoffs of their own technology choices

Stage 3: Paid Working Session (2-3 Hours)

This is the core of our process. The candidate works on a real (simplified) problem from our actual codebase. They're paid for their time.

Setup:
  - Real codebase (sanitized), real tools, real problem
  - Candidate uses their own machine and editor
  - Internet access allowed (Google away)
  - They can ask questions (we want them to)

Example problems:
  1. "This API endpoint is slow. Here's the code and the
     performance data. Find the bottleneck and fix it."

  2. "We need to add a feature to this existing service.
     Here's the spec. Implement it."

  3. "This function has a bug that's causing intermittent
     failures in production. Here are the logs. Fix it."

What we're evaluating:
  ✅ How they navigate an unfamiliar codebase
  ✅ Their debugging process and tool usage
  ✅ Code quality of their changes (not perfection, pragmatism)
  ✅ How they handle ambiguity and ask for clarification
  ✅ Whether they test their changes
  ✅ How they communicate while working

Why this works: It simulates day 30 on the job. Can they open a codebase they've never seen, understand the context, and ship a change? That's the actual job.

Stage 4: Team Conversation (30 Minutes)

The candidate meets 2-3 team members they'd work with daily. This isn't an evaluation — it's a mutual fit check:

Topics:
  - How the team works (process, tools, culture)
  - What the candidate is looking for in their next role
  - What frustrates them about engineering teams
  - What they'd change about how we described our process

What we're evaluating:
  ✅ Do they ask thoughtful questions?
  ✅ Are they curious about the team and product?
  ✅ Would the team enjoy working with them?
  ✅ Are their expectations aligned with reality?

Why We Pay for the Working Session

The math:
  - Average engineer salary: $150k-200k/year
  - Cost of a bad hire (3 months + severance + re-hiring): $50k-100k
  - Cost of paying candidates $300-500 for a working session: $300-500

  Even if you interview 20 candidates:
  20 × $400 = $8,000 in working session payments
  vs $75,000 average cost of one bad hire

  Paying candidates is the cheapest quality signal you can buy.

Additional benefits:

• Candidates perform better (less anxiety, respected)
• Better candidates apply (they value their time)
• You see their real work, not their performance

The Evaluation Framework

After all stages, the team scores independently:

Technical Ability (from working session):
  1-5: Could they ship in our codebase on day 30?

Problem-Solving (from conversation + session):
  1-5: How do they approach problems they haven't seen?

Communication (from all stages):
  1-5: Can they explain their thinking clearly?

Pragmatism (from all stages):
  1-5: Do they make tradeoffs or chase perfection?

Team Addition (from team conversation):
  1-5: Would they make the team better?

Hiring bar: Average ≥ 4, no single score below 3

What We Don't Do

No Leetcode

We've never had an engineer who couldn't do the job because they didn't know dynamic programming. We've had plenty fail because they couldn't navigate a real codebase or communicate with the team.

No Trivia

"What's the difference between == and === in JavaScript?" If they don't know this, the working session will reveal it. If they do know this, the question told you nothing useful.

No Whiteboard

Nobody writes code on a whiteboard at work. The skill of writing syntactically correct code without an editor, autocomplete, or documentation isn't relevant.

No Unpaid Take-Home Projects

A 4-8 hour take-home project asks candidates to donate hundreds of dollars of their time. The best candidates — the ones with options — won't do it. You're selecting for desperation, not skill.

The Results

Since switching to this process:

The process is more work upfront. It requires real problems, paid sessions, and thoughtful evaluation. But the output — engineers who can actually do the job and want to stay — is worth every minute invested.

Stop testing for what you can Google. Start testing for what you can't.