At Sourcegraph, we’re building not only a great product for engineers, but also a great, inclusive company for engineers to be a part of. Over the last few months, we’ve been experimenting with our hiring process and wanted to share our experience so far.

(Our last experiment was putting open roles and job descriptions in the sourcegraph/careers Git repository in Markdown. That worked well!)

The idea

We set out to test whether giving candidates an option to work on a real-world, independent project (instead of on-site programming challenges) would:

• appeal to the kind of engineers who would do well at Sourcegraph; and
• give us and them a more comfortable and natural way to establish mutual fit.

The experiment

To test this idea, we started offering candidates who pass the initial phone screen 2 choices for next steps:

• Option #1 (existing): 6-hour interview consisting of 6 different interview modules with different members of the team, covering technical proficiency, teamwork, and communication. (This used to be the only option.)
• Option #2 (new): A real project. Candidates get a list of real issues on open source libraries that Sourcegraph actually uses. They pick the one that sounds most interesting to them.

The project (option 2) replaces some but not all interviews in the hiring process. It gives candidates an option to highlight their skills, work on their own schedules, work in their preferred environments, and show us how they work with others (especially how they respond to code reviews).

We’re aware that engineers are often asked to work on a project for a company as part of the interview process. It’s a significant time commitment. To respect their time, anyone who does a project (option 2) is compensated with a fixed payment for their efforts, regardless of the outcome of the interview.

The results

So far it has been a success! We obviously can’t divulge many specifics without violating privacy, but here’s what we’ve learned:

• Candidates had an overwhelmingly positive response to the “choose your own adventure” project option. Those who did a project had positive feedback and said they found the work interesting and fun.
• It provides the team better insight to a potential new teammate’s work.
• It allows the candidate to experience what working with us would be like.

Because the work is all open source, you can check out one of our new teammate’s interview projects.

We will always be learning and testing new ways to let great candidates show their skills. Our hope is that more choices helps us find more awesome teammates—and helps establish Sourcegraph as a company that's thoughtful about growing our team.

We'd love to hear your thoughts on these questions. Reach us on Twitter at @sourcegraph!

For engineers:

• In what ways do you wish developer interviews were improved?
• What kinds of projects would most effectively demonstrate your skills?
• Do you think you’re more likely to do your best work in an onsite interview or in a project-based interview?

(And check out open roles at Sourcegraph if you're interested in joining our team.)

For other companies:

• Have you tried a similar approach? If so, what was your experience?
• What kinds of projects do you propose to candidates?