Interesting, I actually prefer take home challenges to the previous trend of whiteboard interviews. And within the realm of take home challenges I prefer ones without time limits which usually implies they are full or multi day assignments.
Even with rehearsal I am not a great public speaker and impromptu formats certainly don't make me better. I also prefer take home assignments since it is more closely related to how I actually do work: Get a problem, think about the requirements, do some research and design a solution, implement.
Since I personally prefer this style of interviews, I have given assignments like this. Usually a simple microservice that is given AWS t2.micro size constraints and no time limit for a response. When I get a submission I am looking at code style, tests, and documentation as well as solution quality to get a better picture of how a candidate approaches tasks and gauge how they work independently. It's amazing how much you can tell about a single person from a challenge like this.
I also think it is more flexible since there are no strict pass/fail criteria. A solution in C/C++ that optimizes heavily but skimps on documentation could be just as impressive as someone who uses Python to stitch together multiple tools with more features and more thorough documentation.
Interviewing is difficult...for both interviewee and interviewer. Finding the right compromise between depth for the interviewer and work required of the interviewee is a challenge. I am sure there are take home challenges that are ridiculous, but I wouldn't dismiss all take home assignments.
With no time limit, aren't you just optimizing for the candidate with the most free time? (Granted, some people are more efficient than others, but you probably only want to hire from the top band of efficiency anyways. Meaning that "time spent" becomes the primary deciding factor.)
This is definitely something to keep in mind, but we keep the requirements for the microservice extremely light for this reason (2 API endpoints). A solution submitted in a week with many extra features can be just as appealing as a solution submitted in a day with the bare minimum. It's not primarily about how much work is put in or how fast it is done; rather it is about the quality of what is included.
Even with rehearsal I am not a great public speaker and impromptu formats certainly don't make me better. I also prefer take home assignments since it is more closely related to how I actually do work: Get a problem, think about the requirements, do some research and design a solution, implement.
Since I personally prefer this style of interviews, I have given assignments like this. Usually a simple microservice that is given AWS t2.micro size constraints and no time limit for a response. When I get a submission I am looking at code style, tests, and documentation as well as solution quality to get a better picture of how a candidate approaches tasks and gauge how they work independently. It's amazing how much you can tell about a single person from a challenge like this.
I also think it is more flexible since there are no strict pass/fail criteria. A solution in C/C++ that optimizes heavily but skimps on documentation could be just as impressive as someone who uses Python to stitch together multiple tools with more features and more thorough documentation.
Interviewing is difficult...for both interviewee and interviewer. Finding the right compromise between depth for the interviewer and work required of the interviewee is a challenge. I am sure there are take home challenges that are ridiculous, but I wouldn't dismiss all take home assignments.