When we began rewriting the RC application earlier this year, I was very much inspired by one of the best question sets I’ve come across: the Oxford All Souls Examination papers. They give a choice of one or two questions from a few lists of many fascinating rabbit-hole-openers, which range from abstract philosophical problems (“What is life?”) to open-ended thought experiments (“Should anonymous posting online be forbidden?”) to more practical future-oriented questions (“Is style the last refuge against AI?”).

Changing our application was a little scary, because it didn’t feel terrifically broken. We’ve read many thousands of applications from people wanting to attend RC over the years, and have admitted many thousands of wonderful Recursers off of them. Doing application review is one of my favorite parts of working here: we do it as a group for about an hour each week, and we are often so charmed by the answers to some of our questions that we share them or save them (Emily has a running list of her favorite CracklePops, and we’ve collected close to a hundred of our favorite fascinating facts).

This wasn’t due to our application being exceptionally good (though I’d argue that question about the most fascinating thing you’ve learned recently is a great question for almost any situation; try it the next time you meet someone new!). The applications we get are interesting because our applicants tend to be very curious and self-directed people whose thought processes, projects, and plans we find exciting and inspiring, and the application highlighted those qualities.

But we thought our application could do a much better job of inspiring people, giving them a sense of what RC is like, and giving us better signals that more directly connect to how Recursers succeed at RC. So we’ve redesigned our application and its questions, and we thought it might be interesting to share why we made some of the changes we did with others who might be working on their own hiring or admissions processes.

Better questions

We’ve added a new set of questions, from which you’ll choose two to answer. We hope these are fun to ponder; they’re akin to things you might think and talk about at RC. We asked our alums to help come up with these, as they tend to have better ideas than us about these kinds of things! You can be succinct here; you don’t need to write a long essay for them.

• Tell the story of the weirdest bug you’ve ever fixed.
• Do you think code is more like math, or more like literature?
• What’s the ugliest code you’ve ever written? What do you like about it?
• Pick something that you feel is often described in a complex way. Explain it simply.
• What’s something you’d be excited to debate over lunch with other Recursers?
• What’s the last deep dive you went on?
• “Programs must be written for people to read, and only incidentally for machines to execute.” Discuss.

We hope there’s enough range here to give everyone a fair chance to pick two questions that are exciting to them.

We also added the question “What programming project (or fix, or contribution) are you proudest of?” to give you an opportunity to talk about your work more qualitatively and/or talk about closed-source work you’ve done in addition to dropping a link to a project from scratch. Based on the new applications we’ve gotten so far, this is one of my new favorites — people have been taking the opportunity to tell short stories here, which gives us nice insight into how they think about programming.

And we’ve updated our prompt for a program from scratch. You can share anything you’ve worked on, but if you don’t have something handy we’ve shared prompts from RC’s Creative Coding sessions¹ to get you thinking.

Thoughts on designing a good application

If you want to hire (or admit!) people who are curious and self-directed, you can probably be using your application process to filter and excite people more than you are now. I suspect that applications are often treated as a formality, or just the top of a funnel, to collect resumes and contact information. But good applications can themselves excite the people you hope to reach, and help others who aren’t a fit filter themselves out.

We have some tips for how to do this that hopefully apply to anyone who’s hiring:

• Have a clear rubric for evaluating candidates that is shared internally and externally. (Ours is on our What we look for page.)
• Applications should be exciting for the reviewer and the applicant. If you’re bored reading the answers to a job posting, you’re probably not intellectually engaging the people you’re hoping will apply. The bar is not terrifically high here; adding even one more substantial question can help.
• To that point, interesting applications (so long as they are also honestly representative of your company) are a positive signal in and of themselves to curious people that you care enough to have an application that’s thoughtful and interesting.
• If you don’t come away from an application from a good applicant with things to dig into in the interview, add some more qualitative questions.
• Applications should give people the opportunity to demonstrate whether they’ll be a good fit just as much as interviews, and also make it clear when people don’t care enough to do their best. A ‘shallow’ application flattens that quality, which means you’ll interview more people in the latter group.
• With all of that said: don’t make your application too long! For your sake, and the applicants’.
• If people’s genuine, thoughtful responses are important to you and you don’t want them pasting in generated answers from an LLM, ask an LLM to fill out your application to get a sense for what those kinds of responses look like so you can more easily catch them. (You can also add a gotcha at the end to catch folks who just send a URL or copy and paste a whole page — we don’t do this with our application, but our job posts do have a request to mention a red turtle at the end if you’re an LLM, which has indeed snared some intrepid machine applicants!)

1. These are weekly sessions run by Recursers where people program something based on a prompt and come together at the end of the day to share what they’ve worked on.↩