Ideas for a Great Take-Home Interview Question

Interview PR makes it easy to run take-home interviews using GitHub pull requests, but how do you design a great interview question? Designing a great interview question requires thinking about what skills are most important to evaluate in your interview, and then thinking about the kinds of questions or tasks that might evaluate those skills. Ultimately, the best interview questions will closely imitate real work, which is why using a GitHub pull request as the interview format makes so much sense. The best interview questions will also include some personalized touches so that the interview matches the industry or job that the candidate is interviewing for. As you think about designing in interview question for the role you need to fill, here are some ideas to get you started.

Build on Boilerplate

One of the primary skills of any software developer is implementing new features. A great way to evaluate this is to provide candidates with some boilerplate and ask them to implement a feature on top of it. Providing the boilerplate is nice because it allows the candidate to focus on building something useful rather than wasting time setting up and configuring tedious boilerplate code. It also ensures everyone’s on the same page, setting a base level of expectations about what kind of codebase we’re working with.

The feature itself could be anything, but the best-designed interview questions are tailored (at least a little) to match the company or industry the candidate’s interviewing for. To provide some quick examples, suppose your company works with map data. It would be perfectly reasonable to ask a candidate to provide the candidate a “hello-world” app in your company’s framework as the boilerplate and ask them to implement a JSON API that performs some common interview task like producing the Fibonacci numbers. But it would be a much better interview to ask them to use the same boilerplate to implement a JSON API that calculates the distance between two GPS points. The candidate feels like they got a taste of what to expect at your company, and the hiring team gets to see the candidate build something highly-relevant for the job. Everybody’s happy!

This boilerplate approach works great with Interview PR, and it’s easy to find public boilerplate repos on GitHub – so your interview team doesn’t need to maintain your own. Here’s a list of some boilerplate repos for some common frameworks.

• Heroku Getting Started Rails
• Heroku Getting Started Python(Django)
• Heroku Getting Started Node JS (Express)
• Heroku Getting Started Java (Spring Boot)
• Next.js Landing Template

Free Public APIs

Free APIs can be an awesome resource as the basis of an interview question. Using a (free) API allows the candidate to develop against a real API with real data, and can make the interview more interesting than it would be without data. Using an API in your interview question is a great way to evaluate a candidate’s ability to implement a solution that consumes an API and does something with the data – either presenting it in a web UI or processing it to produce new information. And this makes a great interview question since this skill is so important in many software engineering roles. If you want to design an interview question that uses APIs, this list of public APIs is a great resource to get started!

Data Repos

Like free APIs, open data repositories can also make your interview question more interesting by providing some non-trivial data to work with. Data repos might be most appropriate for a role that’s oriented toward data. For example, you might ask the candidate to write scripts or SQL that extracts interesting metrics and insights from the data. But the right data set could also work as the basis for an interview question for a more general backend engineering role, asking the candidate to build a script or app against the database.

If you think you want to build an interview question around a data repo, this list of public data sets might help you find something interesting to get started.

An Open Source Repo

It might seem tempting to use an open source repo as the starting point for an interview and ask candidates to add some small feature to it. While I’ve heard of a couple cases where this worked well, I’d be cautious about using it. It can be time consuming to orient yourself with a large codebase, and in the context of an interview that time is probably better spent writing code. Also, it might be unappealing to candidates to do work on an open source project that doesn’t contribute back to the project in any way. If you really want to see open source work, consider an approach like DHH, to look at a candidate’s existing open source contributions as part of the hiring process.

Something to Debug

Some professional engineers spend as much time fixing bugs as they do writing code from scratch. If it’s important to you to evaluate a candidate’s ability to fix bugs, it’s easy to make this part of your interview process with Interview PR. To make an interview like this, you’d need to start by creating a repo with some bugs in it. Maybe it’s a copy of a particular commit of your own codebase, before you fixed a bug. Maybe it’s a simple project with one or two pages or endpoints where you’ve introduced several bugs for the candidate to find. Either way, Interview PR can help you automate a process to send this buggy repo to candidates and allow them to submit a PR to fix the bugs, to evaluate their bug-fixing skills.

A Blank Repo

Giving candidates a blank repo to work in as part of an interview is a bit of a double-edged sword. On one hand, it opens the door for candidates to show off their best work in a creative way, from scratch. On the other hand, it removes some of the guardrails. Different candidates might take the interview in wildly different directions. Candidates also have to spend more time toiling to set up a repo from scratch. While some candidates might breeze through this setup, others might spend a disproportionate amount of time setting things up rather than writing their own code. So while a blank slate (with the right prompt) can be a good interview format in some cases, you should be cautious with it. If you want to use Interview PR to let candidates start with a blank repo, you can use interviewpr/blank as your interview repo.

Tests Only

Want to give candidates the freedom to choose their own solution path, but worried about the lack of guardrails in a blank repo? Consider using an interview repo that includes only tests. Perhaps the tests could be language-agnostic, like checking some simple output with a bash script or using Hurl to run some API tests. Or, perhaps you provide tests specific to your language or framework but omit the implementation. In either case, the tests provide good guardrails so the candidate knows what to work towards, while still leaving the solution very open-ended for the candidate’s own creativity.

Other Creative Ideas

The ideas above are common starting points to build a great take-home interview, but you don’t need to limit yourself to these – particularly if you’re interviewing for a specialized role where you need to evaluate a specialized skill set. There are a wide variety of other creative things you could use as an interview. For example, maybe you could take inspiration from a previous Advent of Code question.

Personalize the Experience

Regardless of which style of interview question you choose to build, an important part of a really great interview question is a personalized experience. When the interview question feels like it matches the work that a company does really closely, it’s a better experience for both candidates and the hiring team. The candidate feels like they were evaluated fairly and were able to show off their most applicable skills, and the hiring team feels like they got a great sense of how the candidate would perform on the job. So whatever you pick, see if you can come up with a way to make the interview question feel like real work at your company.