I like the coding challenge we designed for hiring where I work. A few things about it that work:
- It's designed to take about the same time as the round of interviews it replaces (half a day), and we clearly communicate how polished and complete we're expecting it to (not) be in that time.
- It's a lot like the actual work; if you enjoy it / are good at it, there's a good chance you'll enjoy / be good at the job. It helps make sure (on both sides) that the job is a good fit.
- But at the same time it's designed to be obviously not actually work we're going to use; we're not exploiting unpaid labor.
- There aren't gotchas to it. We review it with an eye toward "if my coworker showed me something they'd been working on for about this long to address this problem statement, how would I feel about their work," and do our best to express that.
- The rest of the application process takes the challenge into account in a positive way. I might have a conversation with you later to understand how you think about the problem you solved, but none of the interviews have to be gotchas or on-the-fly skills tests because I've already seen the kind of work you do.
- Everyone takes the same challenge, and it feels way more fair to discuss candidates based on reviewing how they do the kind of work that we do, compared to "X person has a cool open source repo; Y person gave a good interview answer to this technical question; Z person worked at an interesting place in the past." There's still some apples to oranges in comparing coding challenges, but much less than comparing one person's bootcamp group project open source repo with another person's reason that their best code is closed source but it sounds cool.
With a well-designed challenge the benefits on the hiring side are really obvious (we actually have a basis for comparing applicants that feels somewhat related to the work they're going to do), but also (I hope) we've managed to make a better process for applicants without expanding the time they're spending.
- It's designed to take about the same time as the round of interviews it replaces (half a day), and we clearly communicate how polished and complete we're expecting it to (not) be in that time.
- It's a lot like the actual work; if you enjoy it / are good at it, there's a good chance you'll enjoy / be good at the job. It helps make sure (on both sides) that the job is a good fit.
- But at the same time it's designed to be obviously not actually work we're going to use; we're not exploiting unpaid labor.
- There aren't gotchas to it. We review it with an eye toward "if my coworker showed me something they'd been working on for about this long to address this problem statement, how would I feel about their work," and do our best to express that.
- The rest of the application process takes the challenge into account in a positive way. I might have a conversation with you later to understand how you think about the problem you solved, but none of the interviews have to be gotchas or on-the-fly skills tests because I've already seen the kind of work you do.
- Everyone takes the same challenge, and it feels way more fair to discuss candidates based on reviewing how they do the kind of work that we do, compared to "X person has a cool open source repo; Y person gave a good interview answer to this technical question; Z person worked at an interesting place in the past." There's still some apples to oranges in comparing coding challenges, but much less than comparing one person's bootcamp group project open source repo with another person's reason that their best code is closed source but it sounds cool.
With a well-designed challenge the benefits on the hiring side are really obvious (we actually have a basis for comparing applicants that feels somewhat related to the work they're going to do), but also (I hope) we've managed to make a better process for applicants without expanding the time they're spending.