Most technical interview loops are fundamentally flawed.
They test your ability to regurgitate algorithms you'll never use on the job, or your recall of whatever API the interviewer thinks you should know by heart.
Back when I worked at Airbnb, I fought hard to remove algorithmic questions from our onsite. One particularly egregious interview asked engineers to simulate how water would flow through terrain represented by a two-dimensional array. I wanted our interview to test whether future coworkers could write well-reasoned and maintainable code; I didn't care how well they could implement recursion or avoid off-by-one errors in a time-pressure environment.
Removing algorithmic questions is only one half of the battle, though. We still need to design an interview loop that tests practical skills! This has historically been a tough needle to thread. I want to see how a candidate tackles a problem with real-world scope, but my time with a candidate is short. An interview shouldn't be a proxy for an engineer's typing speed.
But engineering problems that were historically time-consuming no longer are: AI dramatically compresses the timeframe required to go from zero to functional. When designing our interview loop at Tolan, I realized that we can get more signal on the full scope of someone's capabilities by encouraging our candidates to use AI. Since I'm now using AI to write most of the code I ship to production, it only makes sense to include AI in our interview loop.
So we designed our interview loop from the ground up to mirror our day-to-day work. If I give you a product spec, can you build it quickly? Can you tell me where the holes are? Can you reason through trade-offs? Do you know when something's not ready to ship? Do you know when something is ready to be reviewed and maintained by another person?
Candidates spend the morning with us at our office in San Francisco. I'll hand you a small problem – one that we've solved ourselves – usually from a bare-bones Figma file or a short spec. This might be a simple flow or a lightweight feature that would ordinarily take a day or two to build and ship. But for this exercise, you'll have just a few hours—and that's not enough time to make a polished product. I want to see how you work within constraints.
You're encouraged to use AI to solve the problem. Whatever tools you would want to use as an employee, use them during the interview. We'll give you a Claude, Codex, Cursor, or Gemini license if you need one. I want to see you balance LLM-generated code against your own judgment.
But make no mistake—even if you aren't writing the code, you own the output. I want to see how you approach the problem, how you structure a solution, how you think through constraints, and how you decide what actually matters.
Before lunch, we'll sit down together for a 20–30 minute conversation about what you created, and I'll ask what you would improve if you had more time. What would you change before you send it to me for review, and what would you change before we actually ship it? I want to hire people who know when their work isn't good enough, and who know how to make it better.
Then we go eat.
A few words of advice
- I get itchy when a candidate uses an LLM to think through how the project should be completed. It's not enough to screenshot the Figma, upload it to Claude Code, and ask it to solve the problem. You know how to architect. Show me!
- Really good candidates will question a spec when something isn't clear. They clarify the problem statement, explore edge cases, and think about the end-user. They can recognize tradeoffs. When something is a little weird or doesn't feel right, they point it out.
- In a world where implementation is getting easier and easier, what I'm looking for is judgement. You won't have enough time to create a polished product. With this in mind, I want to see what sacrifices you're willing to make. And when you can't get everything looking or feeling just right—what drives you crazy?
- The best candidates surprise me with their creativity. I just hired an engineer who built a mini-game to keep a user entertained during a long wait for a LLM response. That's incredible!
- Working code isn't the finish line. I've had candidates tell me, "I'm still not sure what this part does," and then say they wouldn't change anything before putting it up for human review. Yikes! Those candidates don't pass muster.
- If you don't understand your own code, it isn't ready for another engineer to review. It isn't ready to be maintained, and it definitely isn't ready for production.
While AI has changed how much code an engineer will produce, it actually hasn't changed what makes a great engineer. Even before we Claudified our codebase, I hired engineers who can reason, communicate, and make smart judgment calls.
If that's you - we'd love to chat. We're hiring for both backend and client roles. You can find our open roles here, or just send me a note directly (dfed@portola.ai).