Takehomes & Algos are Both Evil - And Other Lessons from 1000+ SWE Interviews

To hire exceptional engineers, prioritize signal clarity in your interviews, match them tightly to your company’s true needs, and leverage blind reference checks.

I’ve spent an inordinate amount of time and mental energy on recruiting top software engineers—first as an IC interviewing at Airbnb, and later while founding Graphite. Over the last few years, Graphite’s grown to around thirty people and continues to scale. This means I’ve coordinated and run interviews for 1,000+ candidates, primarily full-stack software engineers.

That grind has forced me to reflect on what works and doesn’t in the recruiting process—and I want to share some of those reflections. They’re cobbled together from long conversations with other engineering leaders, talent leads, and a ton of personal experimentation.

What Interviews to Run (They’re All Imperfect)

The first realization I’ve come to is that the specific interviews you run don’t matter too much. You’ll find entire threads of angry diatribes online about why “this” or “that” kind of interview sucks. At some point, you just have to pick a poison and calibrate consistently on it. The industry is famously fractured on how to assess technical skill; if there were a perfect solution, we’d have settled on it by now.

I’ve tried all variations at Graphite. My main takeaway is that algo-style coding interviews, while imperfect, have been the most consistently useful. Take-homes demand a ton of candidate time, are often cheatable (especially with AI), and produce results whose quality can vary widely based on how much effort someone invests. Did a candidate submit an amazing project because they spent 20 hours on it or because they’re exceptionally talented? Hard to say. On the other hand, here’s where algo-style interviews deliver:

1. They’re tried and tested. There’s a well-established format that’s understood across our industry.

2. They’re easily preparable (and beatable). Both new grads and seasoned engineers can practice and feel some level of control over their fate. It’s a more level playing field.

3. They can fit into 45 minutes. You get a tight, controlled environment to glean nuanced signal.

4. They have a correct answer. That reduces variance and personal bias when deciding pass/fail.

At Graphite, we often run two separate algo interviews, each with a different interviewer. That helps mitigate random flukes: even if someone completely chokes on a question in one interview, they still have a second shot. Interestingly, I don’t see huge divergence in how candidates perform across those two interviews—but it’s a good safety net. In the future, I aspire to experiment more with 45-minute-long practical-style interviews.

Beyond those, I typically run:

• A systems architecture whiteboarding interview

• An experience interview

• An interview led by cross-functional stakeholders (e.g., Product or Design)

I Love the Architecture Interview

I find the architecture interview provides most of the deeper signal I need. It tests fluency, reasoning, and open-ended technical thinking. A great candidate might discuss tradeoffs between REST, GraphQL, gRPC, or event-driven APIs, while also touching on how they’d handle load balancing, caching, or security concerns. The point isn’t to complete a “correct solution.” It’s about articulating tradeoffs, constraints, and thoughtful decisions—whether it’s frontend design, backend scaling, or security hardening.

A bad candidate might not even know what an API is. A passable candidate will say “we should use REST.” But the truly outstanding candidate will say, “We could use REST, GraphQL, or WebSockets, depending on X, Y, and Z, and here’s the risk-reward of each.”

The Experience Interview is for Leveling

The experience interview is usually the candidate’s chance to walk through a real project they’ve built or owned. I’ll ask questions like: Who came up with the idea? How many people were on the team? Were there any big missteps? How did you handle them? By exploring how they collaborated, how they solved problems, and what they learned, I get a sense of their leadership potential, growth trajectory, and overall maturity. Airbnb taught me that coding alone can’t distinguish a new grad from a staff engineer—real past experience usually can.

So in short, I want these interviews to answer:

1. Can the candidate code—and how strong are they at it?

2. Are they fluent in architectural reasoning?

3. How seasoned are they, and at what level of responsibility have they operated?

4. Are they disciplined, clear communicators, and generally courteous?

That’s all I really need for a reliable hiring decision. Our scorecard, like many other companies’, is simple: pass each individual interview and earn at least one strong pass from the loop.

But again: the specific interviews themselves matter far less than the clarity of the signal. A “good” interview gives you a crisp read. A “bad” interview yields a bunch of “meh” signals that fail to differentiate among the candidates. If five people come through and they’re all scored as “slight pass,” you haven’t learned anything truly decisive. We killed our longer take-home format precisely because the signal was often muddy. Meanwhile, algorithm interviews, for all their controversy, consistently generate a clear pass/fail/strong pass distribution—and that matters.

Values Interviews: My Evolving Perspective

I used to be a volunteer interviewer for Airbnb’s core values process. It was a robust, multi-day training and something I took pride in. When I started Graphite, I initially cloned that system. But over time, I phased it out for engineering hires—at least in that official capacity—because it wasn’t failing enough candidates who needed to be failed, nor rescuing borderline candidates who might have soared. I wouldn’t pass someone who bombs every technical and architectural interview just because they told a great story about living the company values. Conversely, if they aced everything else, I’m not going to fail them for not delivering a perfect values anecdote.

Today, I still care deeply about kindness, work ethic, and collaboration, but I watch for signs of that during the experience interview (and, honestly, throughout the loop in general). If there’s a glaring red flag, that’s easy to handle. No specialized interview needed. Someday, I might refine or reintroduce a formal values screen, but for now, this simpler approach has worked well.

The Hiring Bar vs. a Hiring Bullseye

There’s a mythic, invisible entity in the recruiting world called “the hiring bar.” Nobody can say exactly what it is, or write it down, yet everyone references it. People wonder, “Are we lowering the bar too much?” or “Is this candidate a bar-raiser?” It’s reminiscent of big tech hiring—Google, Meta, Amazon—where you hire for “generic greatness” rather than specific team needs.

But this can be problematic if the “bar” becomes disconnected from the actual business problem. If you’re not hiring for a specific need—or you simply want to land the best possible people no matter what—then fine, the bar metaphor might sort of work. But for most of us, especially at startups or on smaller teams, we have immediate business challenges that need solving. We’re not just collecting “10X engineers” to keep in a back room; we need real solutions, pronto.

That’s why I prefer a bullseye metaphor:

• Need (the center). What job or jobs are you trying to fill, and what’s the urgency? If your site keeps going down due to Postgres issues, you might need a database expert yesterday. If you have a year to find a security lead, maybe you can be more patient. The clarity around the need shapes everything.

• Risk (the scatter). Even well-designed interviews aren’t perfect. You could end up with a candidate who’s “spiky” and excels in the exact skillset you need—but there’s also a chance they might have big blind spots. If your timeframe is tight, you might be willing to take more risk. If not, you can hold out for a unicorn who checks every box.

The bullseye approach frames hiring as a balance of specificity and risk tolerance, rather than “we have one gold standard bar that we never compromise on.” In fact, a candidate who’s “spiky”—with some yes/no signals—can sometimes be better than a lukewarm, well-rounded candidate if their spikes align perfectly with your need.

Reference Checks: Do Them

Reference checks are often underleveraged because they can be tedious, and hiring managers frequently run out of time or skip them. But they can be invaluable for clarifying uncertainties or revealing hidden red flags.

I think every hire should have at least two named references plus a few blind references (with the candidate’s permission). That might sound like a lot, but here’s why:

1. Named references verify the candidate’s role, anecdotes, and achievements. Did they truly lead that project? Or were they a minor contributor? They also confirm that someone out there is willing to endorse them wholeheartedly.

2. Blind references can deliver incredible insight when they work out. A trusted mutual contact can provide an unfiltered read on strengths and weaknesses, or even share a horror story that won’t come through in a normal loop.

If you’re going to do references, invest the time to ask nuanced questions. And remember: for top candidates, references are also interviewing your company. They’ll often share their impressions with the candidate, so bring your A-game and be consistently thoughtful and kind.

Don’t Hide That Your Process Is Hard

We’re in an era where more companies are vocal about having a rigorous or “high bar” interview process. It might run counter to the typical recruiter instincts of casting the widest net possible, but I’ve found that many of the best engineers want a challenge. They’re selective about teammates and don’t want to be in a place where someone who can barely code is passed along for convenience’s sake.

Being upfront about having a difficult process can actually attract certain high-performers—if you back it up with what one of my favorite recruiters calls “the brilliant basics.” That means you:

• Respond quickly

• Provide a clear schedule and materials in advance

• Treat the candidate with respect

• Give feedback or decisions promptly

• Offer a competitive package at the end

In short, if you’re going to make them jump through hoops, at least hold up your end and run a smooth, respectful process. It’s basic decency, but it also confirms what great candidates are hoping to see: a company run by professionals who care deeply about every detail.

Final Thoughts

Recruiting—especially at scale—is fundamentally about discovering truth and reducing risk. We’re trying to figure out if someone can solve our problems, fit our culture, and thrive long-term. A strong interview loop isn’t about showing off the “correct” method or adopting the hottest new assessment trend. It’s about generating clear signals with minimal noise.

When in doubt, remember:

1. The specific format of your interviews matters less than the clarity of the signal you get.

2. Customize your process to the actual need of the role, not some arbitrary “hiring bar.”

3. Reference checks can be a superpower if you use them intentionally.

4. Don’t be shy about having a “tough” loop—just make sure you execute your end flawlessly.

Ultimately, a robust, fair, and well-structured interview process not only helps you find amazing new colleagues, but it also reassures candidates that your company is serious, intentional, and worth joining. In my experience, that’s the real key to hiring success.

I imagine I’ll remain obsessed with hiring well long into the future. If you have deep questions and hot takes here, I’d be happy to talk and share notes! Message me on X.