One of my primary functions in the last 3 years at @omniushq was to grow the engineering team and set up the engineering hiring process along with our HR team and engineering team leads for various roles.
This is my personal take on take-home challenges and interview process. Usually, the process is more or less similar across companies irrespective of the size.
Normally you are approached by a recruiter or you apply for a role. You have an exploratory call for the role and the hiring process after which one is most likely handed a take-home challenge which should take you a week or two to complete. We did something similar at omni:us for almost 2 years. We started seeing the sharp drop of interviewees in the pipeline the moment we moved to the take-home challenge step. We did expect the drop but not as harsh. We are thankful this happened as it led us to ask ourselves, why we are doing the take-home challenges?
Most of the interviewees who are in the process
Are already working at a good organization.
Probably have open source contributions or other works to showcase.
Have tons of other take-home challenges from different organizations.
Most likely does not have the time to do a full-blown solution only to be rejected later because linting was an issue. Trust me, this has happened.
Why we need the take-home challenge as an organization? Well, there are reasons:
On completion, we know for sure that the interviewee is interested in the position with us.
We have access to data on understanding the technical capabilities of the interviewee from one point of view.
Can they write good (relative) code?
We are following standard processes across the industry, we need to do this. Don’t question the process.
Can we make the process more human?
As a hiring company, ask yourself, which level you are hiring the engineer for? If its a mid-level or a senior level, do you really need the take-home assignment?
White-boarding session with the engineering team on a problem you are solving at your current organization helps you more than looking at code submissions. You will learn about how the interviewee could function in your team, debate on ideas, take feedback, and work in situations of conflict if any arises during the discussion.
Can their existing open-source contributions already do the job for you?
Reduce the number of steps, instead of having 6-7 rounds spread across weeks, try blocking half a day with the interviewee for a session of whiteboarding, team discussion and some lunch. This will help you realize if you can see the potential interviewee as part of your team on a day to day basis.
Make it fun for all the parties involved. Talk about interesting problems, talk about hard problems solved by the interviewee in his career, and do not make it all about you and your company. All companies are cool these days.
Do not blindly follow an industry standard for Hiring.
Are take-home challenges giving you all the data you need to evaluate an interviewee?
Take-home challenges can be replaced by whiteboard sessions if the interviewee has been briefed about the problems to expect during the whiteboard session.
Focus on making the process human and friendly towards other engineers. Being kind and thoughtful is more important than just looking at code.