Technical Interview: Real Work, Real Signal

Why Our Technical Interview Looks Different

Most technical interviews ask candidates to solve algorithm puzzles on a whiteboard or rush through problems that don’t resemble real engineering work. That’s never felt right to me.

When I hire someone, I’m not hiring them to solve contrived problems under pressure. I’m hiring them to build, debug, refactor, and collaborate inside real systems—just like the ones we work on every day.

That’s why our technical interview is designed to mirror the job itself. It’s practical, collaborative, and open-ended. We want to see how candidates think, what trade-offs they consider, how they ask questions, and how they work through uncertainty.

It’s also a matter of fairness. I’m a self-taught engineer. I wouldn’t have thrived in a process that relied on textbook algorithms or trivia. And I don’t think those skills are the best predictors of success on our team. So we’ve built a process that gives every candidate—not just the classically trained ones—a real chance to show what they can do.

What the Interview Looks Like

The technical interview lasts 45–60 minutes and takes the form of a pair programming session. But the real work starts before we even get on the call.

About 24 hours in advance, we send the candidate a link to a real codebase—one that includes both frontend and backend components, written in multiple languages. They can choose whichever stack they’re most comfortable with.

We also include a list of tasks they can work on. These aren’t step-by-step instructions—they’re intentionally open-ended. The tasks leave room for interpretation, trade-offs, and even disagreement. Part of the work is deciding how something should work, not just how to implement it. If a candidate wants to clarify assumptions, suggest alternatives, or push back on the problem framing, we welcome it.

The interview itself is open-book. Candidates can Google, consult documentation, or ask clarifying questions. AI tools are fair game when used like reference material, not as a shortcut for implementation. We're not testing recall—we’re interested in how people navigate ambiguity and solve real problems.

What We’re Looking For

Our goal isn’t to see whether someone can complete every task. It’s certainly not a homework test. In fact, we don’t expect candidates to show up with a full solution already built—and it’s not necessary. But if they do, we’ll use that as a starting point to go deeper: asking about their decisions, exploring trade-offs, and pushing into new directions.

What matters most is how they engage with the work: how they think, how they communicate, and how they adapt when things get murky.

That’s why we ask candidates to speak aloud as much as possible. We want to hear how they reason through uncertainty, how they debug when something breaks, and how they make decisions under loose constraints. It’s not about being polished—it’s about showing up and thinking out loud.

We look for signal across many of our engineering competencies. Some of the clearest tend to be:

• Code quality – Are they intentional with structure, naming, and clarity?
• Debugging – How do they investigate, test assumptions, and narrow things down?
• Testing – Do they think in terms of validation, edge cases, and confidence?
• Communication – Can they explain their thinking and ask good questions?
• Prioritization – How do they scope and sequence the work?
• Feedback – Are they receptive, collaborative, and open to shifting direction?

These aren’t the only things we look for—but they tend to surface most clearly in this format. With thoughtful listening, you can learn a lot more than just technical skill.

Why It Matters

This kind of interview takes more effort to set up—and more skill to run—but it’s worth it.

We want every candidate to have a real opportunity to show what they’re capable of—not just those trained in textbook algorithms or interview puzzles. That’s especially important for people from non-traditional backgrounds: self-taught engineers, bootcamp grads, career changers. We believe the path someone took matters less than the way they think and work now.

By giving real code, real tasks, and real choices, we try to make the interview feel like what the work actually is. And by keeping it open-book, we remove the artificial constraints that can turn good engineers into anxious ones.

We still challenge candidates. But we do it in a way that respects their time, their autonomy, and their humanity. That’s the kind of team we’re trying to build—and this interview is one small but important part of that.

Closing Well

We usually don’t leave much time at the end of the interview for discussion. After 45–60 minutes of focused work, we want to respect the candidate’s attention and energy.

But we do try to close clearly and thoughtfully. We thank them for their time, explain what comes next, and let them know when to expect a decision—usually within a week.

It’s not elaborate, but it matters. Even a brief, intentional ending helps reinforce the respect we aim to carry through the entire process.

A Note Beyond Engineering

While this post focuses on our technical interview process, the underlying principle applies more broadly. Whether we’re hiring for engineering, design, support, or operations, we try to simulate the actual work in some way. Our goal is to create an experience that gives both sides a chance to understand what it might be like to work together. Real tasks, real context, real signal.