So, you got this person’s resume and it isn’t bad. You interviewed them and they passed. However, you’re still not sure if they’re a good fit for the position. Before rushing into deciding to accept the candidate, you can always share a post-interview challenge.

What is a post-interview challenge?

A few things that can’t be measured in an interview are code quality and learning ability. You might have some indications, but to be absolutely certain, you would want to see their work in action. The post-interview challenge is a mini project you give the candidate after the interview and before accepting them. It’s extremely useful for both you and the candidate.

How to create one?

Some companies use a standard software test using HackerRank or a similar tool. For the rest of us with limited budget, the best you can do it to go back to your issue tracker and pull out two tickets. The idea is: if this person joins the team right now, what would they be working on? What would be their first task? and what would they be working on a couple of weeks from now?  The tasks should be:

• Task#easy: The simplest task that this person needs to be able to solve trivially without any research. You’ll find something like (change css, simple behavioral change, …)
• Task#intermediate: A task that requires some research before doing it. You’ll find something like: Change dependency version, add security on the client-side, ..)

Now of course you can’t just give them two tasks from your issue tracker, you need to prepare them first. Mainly by…

• Hide any company-specific information and trade-secrets.
• Remove any company-specific setup around them [e.g. instead of calling an API, read a json file]
• Keep the task relevant to the industry, theme, and expected role.
• Package them in one email and explain that (if they join), task#easy is something they’ll be working on during the first week and task#intermediate is something they’ll be working on in around one month (once they’re comfortable)
• Communicate clearly what is the expected output from each task.
• Communicate clearly how each task is measured (performance, accuracy, memory usage, test coverage, documentation…)
• Give them time estimates for each task, but don’t enforce it.
• Give them one deadline for both tasks, but ask them to send them separately.
• You can allow them to send “partial results” before the deadline. (Some companies require you to send pull requests to a private git repository).
• It’s good to include a stretch goal for each task and see if they’ll pursue it or not.
• Make the instructions as clear and transparent as possible. There’s no point trying to trick the candidate into anything, if you care about unit tests, make it a clear requirement and don’t wait for the candidate to guess for themselves.
• Some companies require the fix in the form of a pull request, which gives them visibility on the candidate’s iterations and growth with the tasks.

Why two tasks?

Sending one task over will test the candidate’s technical ability. However, sending over two tasks will give you insights about their thought process and communication skills. Given that you gave two questions (easy) and (intermediate), consider these questions regarding their technical skills:

• How correct is the output of two tasks?
• How fast were they in solving them? (remember, you asked them to send it over once it’s done)
• How good is the code and methodology of the solutions?

Now consider these non-technical questions:

• The first task should be done in a couple of hours, how long did it take them?
• Were they able to solve both tasks? It’s normal if they solved the easy one but couldn’t do the hard one, but some people will surprisingly solve the hard one and ignore the easy one.
• Did they started with the easy task first or the hard one?
• Did they start early and finish early? or did they wait till one day before the deadline?
• How well did they communicate the results?
• How well did they follow your instructions regarding output format and other requirements?
• Assuming they had time, did they pursue your stretch goals? Or were they content with minimal results?

To be fair, some of the points above are speculative and shouldn’t be taken as facts. If the candidate was too late and only sent the harder task, you might want to give them a phone call clarifying why did they take this course of action and give them the benefit of the doubt.

Benefits for the candidate

• Understand the business case and the problem domain.
• Understand technical workflow inside the company (e.g. we use git, we always have unit-testing, we require inline documentation) – this alone would excite the candidate to join or push them away, depending on their priorities.
• By having a ‘real’ problem, the candidate got insight into the kind of technical problems we solve and how do you solve them. So they can make the decision ‘Do I want to work here or not‘… One candidate replied to me saying “I’m wasn’t comfortable solving this task, so if all of your work is like this, I don’t want to join” (Which is amazing, he saved us both a mismatch).

Personally, I’ve never been a fan of hypothetical questions and the assumptions domain. I’m also not a fan of intimidating candidates or asking them trick questions. You really can evaluate any candidate easily if you use clear, specific instructions and expectations.

If you liked this post, check my previous one on fact-driven interviews.