Building an Interview

The tech industry has a cargo-culting problem when it comes to hiring. Small startups routinely adopt interview processes designed for companies with fundamentally different constraints, often with disastrous results. Here's why context matters more than "best practices," and what a genuinely adapted interview process might look like.

The One-Size-Fits-All Fallacy

Everyone agrees that software engineering interviews are broken. Ask any group of engineers, hiring managers, or executives, and you'll hear the same complaints:

Candidates hate:

• LeetCode-style problems that don't reflect actual work
• Inconsistent, subjective evaluation that feels arbitrary
• Time-intensive processes that take weeks or months

Hiring managers hate:

• High false negative rates that filter out strong engineers
• Poor correlation between interview performance and job success
• Candidate drop-off and reputation damage

Leadership hates:

• Massive time and resource drain on senior engineers
• Slow time-to-hire that costs business opportunities
• Persistent diversity and inclusion challenges

The irony? Despite universal acknowledgment of these problems, most companies keep doing the same thing. Why? Because they're copying the "best practices" from companies operating under completely different constraints.

Understanding Asymmetric Risk

The hiring calculus for Google versus a startup is fundamentally different:

For Google:

• False negatives are cheap (500 more qualified applicants arrived today)
• False positives are manageable (one mediocre hire disappears into a large team)
• Interview capacity is abundant (thousands of engineers available)
• Optimize for: Minimizing false positives, even at the cost of many false negatives

For a small startup:

• False negatives are expensive (that might have been the perfect candidate, and you won't see another for weeks)
• False positives are catastrophic (one bad hire poisons culture, blocks a critical role, and burns irreplaceable runway)
• Interview capacity is your scarcest resource (every hour interviewing is an hour not shipping product)
• Optimize for: Speed and accuracy on both sides

When a bad hire costs you a year of runway and $200,000 you can't afford to waste, that's not the same problem as Google having someone underperform in a low-impact role. For a startup, a hiring mistake can literally mean shutting your doors.

A Process Built for Small System Constraints

Hers's what we implemented on one small backend team and why each piece made sense for our context:

1. Recruiter Screening with Technical Questions

The recruiter handled initial resume screening and asked basic technical questions like "Can you describe the difference between horizontal and vertical scaling?"

Initial problem: Non-technical recruiters produced false negatives when evaluating responses.

Adaptation: Recruiters sent responses to engineers for quick validation. Since questions were simple, this took only seconds of engineering time while maintaining high-volume screening.

2. Live Debugging Session (1 - 2 hours)

Candidates worked with a pre-built service containing intentionally flawed code. The bugs were layered: some simple and obvious, others edge cases that required questioning data quality and even the correctness of unit tests.

Why this worked:

• Tests real-world debugging skills and assumption-questioning
• Weak engineers treat tests and data as gospel truth; strong ones ask "is this test actually validating the right behavior?"
• You could pass without solving everything, but could also solve everything and still fail if you showed poor judgment

The key insight: In production, the right answer is often "I found these three issues, here's my confidence level on each, and here's what I'd investigate next" rather than claiming you've fixed everything. This tests self-awareness and judgment, not just technical chops.

3. Collaborative Extension

After debugging, candidates extended the service with new functionality (like adding organizations or user roles to a user management service).

Why this worked: The candidate was now familiar with the codebase and its quirks. This tested collaboration, code quality under realistic conditions, and how they handle working with imperfect existing code—which is what all real engineering work looks like.

4. System Design (Grounded in Their Code)

Instead of "design Twitter," candidates discussed how to scale the service they just debugged and extended. How would it handle traffic surges? What would it cost? What would CI/CD look like?

Why this worked: Candidates were discussing something they understood intimately—including its current limitations and technical debt—rather than regurgitating memorized system design patterns. Much better signal on whether they actually understand tradeoffs.

5. Values Interview (Cross-Functional)

Conducted by people outside the hiring team—usually someone from a different engineering org plus someone from product, design, or content.

Why this worked:

• Fresh perspectives not anchored on "we like their code"
• Candidates met more of the company for realistic preview
• Different interviewers cared about different signals: engineers focused on technical curiosity, while product/design/content folks valued communication, vision, and handling workplace friction
• Built complete candidate pictures without overloading any one group

Bonus benefit: Regular cross-functional interview participation improved overall collaboration. Getting product and engineering folks regularly exposed to how each other think paid dividends beyond just hiring.

The Scaffolding Approach

The key insight binding this all together: using the same service throughout multiple stages. The candidate debugs code, extends it, then discusses how to scale and operationalize it. No context switching to different problems. Each round builds naturally on the previous one, testing progressively higher-level thinking about the same system.

This approach respects the candidate's time (everything is synchronous, no homework), provides consistent signal across rounds, and mirrors how real engineering work actually happens—you rarely build something from scratch in isolation. You're usually debugging, extending, and scaling existing systems.

The Real Lesson

The startup interview process described here wasn't perfect, but it was genuinely adapted to its constraints rather than cargo-culted from Big Tech. When you have limited interview capacity, catastrophic downside risk from bad hires, and need to move fast, your process should look nothing like Google's.

Context matters more than best practices. A 50 person startup burning through runway can't afford Google's 2% acceptance rate, but it also can't afford their tolerance for false positives. The right process for your company depends entirely on your specific constraints.

Before copying someone else's interview process, ask yourself: Are the soltuions to problems of their system applicable to ours?