The Interview That Ships to Production | AngelListSign inContact sales

Blog<br>Category<br>Working at AngelList<br>Written by

Thibaut Labarre<br>Engineering Lead

Copied link

Blog

Working at AngelListThe Interview That Ships to Production<br>How we replaced whiteboards with pull requests, and why candidates keep improving the interview itself<br>May 15, 2026 — 7 min read

Written by

Thibaut Labarre<br>Engineering Lead

Copied link

Most technical interviews are performances. You walk into a room (or a Zoom call), solve a contrived puzzle under artificial time pressure, and everyone pretends this reveals something meaningful about how you work.<br>We got tired of pretending.<br>At AngelList, we build the financial infrastructure behind $200B+ in venture & private assets. Our engineering team is small (fewer than 50 people) and every hire has an outsized impact. We needed an interview process that actually measured what matters: Can you read a codebase? Can you think critically when an AI is confidently wrong? Can you ship?<br>So we built one. And then we asked candidates to make it better.<br>The take-home: a real problem, not a puzzle<br>Our exercise gives candidates a domain-relevant coding challenge: implement a three-tier venture fund distribution waterfall in JavaScript. Return of capital, preferred return, carried interest: the actual mechanics of how money flows through a fund. It's self-contained, doesn't require framework knowledge, and exercises algorithmic thinking and numeric precision.

Candidates also get access to a Claude AI assistant while they work. This is intentional. We're not testing whether someone can avoid using AI. We're testing whether they can use it well. Can they evaluate what the AI gives them? Do they verify the output, or do they trust it and move on?<br>The exercise is calibrated to reward critical thinking. Candidates who read code carefully and verify behavior against edge cases tend to do well. Candidates who accept the first plausible answer, whether from an AI or from their own intuition, tend to miss important details.<br>We record the ai chat alongside every keystroke, with millisecond timestamps, so we can see exactly how candidates approach the problem: how they prompt the AI, how they respond to its suggestions, and whether they validate the output before shipping.<br>Then comes the part nobody expects<br>Candidates who clear the take-home move to a follow-up interview. But it's not a system design whiteboard. It's not a behavioral question gauntlet.

Latest articles

Working at AngelListVersion Control for Financial Reality<br>Apr 1, 2026 — 11 min read

We give them access to the testing platform's actual codebase (the same Next.js app they just used to take the assessment) and ask them to ship a pull request.

No contrived task. No "build a TODO app." Just: look at this production codebase, find something worth improving, and ship it.

What happens next has consistently surprised us.

What candidates actually built

One candidate noticed that the Part 2 coding environment forced you to choose between the AI chat panel and your test cases. If you wanted to refine a test case while writing code, you had to navigate back to Part 1. So he built a tabbed sidebar that lets candidates toggle between the AI assistant and an inline test case editor, complete with streaming indicators when Claude is responding off-screen, localStorage persistence for crash recovery, and event-driven architecture so admin replay could follow every edit. Three pull requests, all merged.

Another candidate found a data loss bug that nobody on our team had caught. When a candidate submitted their assessment, if the network request failed, their work was silently dropped. The event flush function swallowed errors, the beforeunload handler didn't use keepalive: true, and the submit flow didn't check whether the flush actually succeeded. He extracted the flush logic into a standalone module, added retry semantics, wrote seven unit tests, and introduced Vitest to the project, all in the interview.

Nathan Amin dug into how the AI assistant was calibrated and found ways to make it sharper. The assessment's difficulty depends on subtle choices in how the AI behaves, and he saw room to improve the signal-to-noise ratio, making the exercise a better test of what we actually care about. He refined the calibration, making the assessment more precise without making it unfair. He made the interview better, and he was right.

A candidate added a small but thoughtful UX improvement: when you add a new test case, the platform now copies the previous case's structure instead of inserting a blank. It sounds minor, but it means candidates spend time thinking about edge cases instead of re-typing boilerplate, which is exactly what we want the assessment to measure.

Another candidate noticed the timer was confusing. There was a clock on the start page but no indication of what it meant. Was it already running? Had they already started? The candidate fixed...