Take Home Interviews in the Era of Claude

Back in 2023 I came up with our first take-home interview assignment: build a full-stack Secret Santa app that supports multiple users and groups. It proved to be an effective engineering screen. It tested SQL and denormalization, authentication, React, backend fluency, and API design. But most importantly it also tested product vision: you have to think a little bit before you start implementing (e.g. adding the option to avoid specific pairings).

Unfortunately, this task is totally useless in 2025. There’s so much Secret Santa code floating around GitHub that you can shove the prompt into Claude and it will spit out a working example in 15 minutes (feel free to try this yourself). It’s no longer an effective test.

I suspect the vast majority of industry take-homes are in the same boat.

Should We Scrap Take-Homes?

I know what many readers are thinking - why not just drop take-homes? Run purely on-site interviews instead, where the candidate can only use a whiteboard and the contents of their brain? It certainly solves the problem.

This is how Google runs their process, you may say. Having interviewed at Google successfully, I’m not totally opposed. However, I’m not at all convinced that this process selects the strongest programmers. When I interviewed for Google in college, in addition to being quite a good student and having 3 internships under my belt, I spent easily 40 hours working through every past problem in Cracking the Coding Interview and a Google test bank that a friend had forwarded me. I was also on my college’s ICPC (Programming Olympiad) team. During my actual interviews, of the 5 whiteboard problems I was given, I had seen 4 already verbatim. I got a top score and an offer with my choice of team.

These interviews heavily incentivize a combination of luck and algo prep. If you’ve seen the problem before, you can breeze through a 30 minute interview in 10 minutes. If not, figuring out the answer in 30 minutes will be quite difficult even if you’re quite smart. One of my close friends at Google tries very hard to craft his interview questions to avoid this trap, with limited success (e.g. design an efficient algorithm to find matches in the card game “Set”).

Why I Think Take-Homes Are Great

I’m a big fan of the book Thinking Fast and Slow, which breaks down thinking into two types: quick and deep (sometimes called System 1 and System 2). Many people are good at both (and some are good at neither), but if I had to pick between one or the other, I would hire a Deep Thinker. Real, hard engineering work requires foreseeing pitfalls, designing systems, and evaluating tradeoffs. And I feel strongly that whiteboard challenges select for good System 1 candidates.

Good take-home interviews allow deep thinkers to show their skills. They give candidates the time to really noodle on a problem and come to the discussion interview with their best ideas. I’ve had a lot of people impress me, coming with papers that they read or a recent blogpost on a new tool that might make sense for this problem. Conversely, some candidates with sterling resumes failed utterly. A bad candidate reads the task, thinks for 30 seconds, writes their idea sketch, and doesn’t look at it again for a week. That’s exactly who we screen against.

How Vibe Coding Ruined Everything

With the rise of vibe-coding tools like Claude Code and Cursor, tasks involving quick mock-ups, especially common apps (e.g. TODO list, blackjack) with code available on GitHub, are completely obsolete. I gave this prompt to Claude for our previous task:

Build a full-stack application in Node.js + TypeScript + React for a multi-user Secret Santa app.

With minimal intervention from me, it generated a decent solution in about 10 minutes. I played with specifying the use of particular frameworks, build tools, and libraries - all done in the time it took for my Instant Pot to make dinner.

The only thing these types of tasks check today is whether your candidate has a spare $20 and a credit card.

I suspect Claude also obsoletes many others’ take-home tasks as well. Some other common tasks I’ve seen include asking candidates to implement an API that passes some predefined unit tests, fix some bugs in a template project, or implement a parser for a sample of binary data. All of these can be done by Claude in a matter of minutes.

So what now?

Why This Isn’t Terrible

I think there’s a silver lining in all this. To get to the meat of a problem, often candidates must write a lot of time-consuming scaffolding code. But now they can focus on thinking, and let Claude handle the rest instead.

The next version of take-homes must assume and expect that candidates will use AI tools. They must move the challenge away from “does the candidate know React” or “can they design an API” and towards “can they think”. You can now ask questions like:

• What are the error cases and how should the program handle them?
• How should the program behave under uncertainty?
• How would you design the UX flow and what does it maximize?

Of course, that takes deeper thought from the problem setter too.

We’re hiring → careers@reffie.me