One of the major problems with take home tests is the rampant cheating.
It's been a long time since I've been on the job market - but even a decade ago, I had third-party recruiters who would forward me a take home test... and another successful candidate's solution, "for reference".
And even if candidate doesn't get external help, I'm extremely sceptical about time limits. Nothing stops someone spending 6 hours on a "2 hour" take home test, producing a better solution than someone who followed the time limit strictly.
It's pretty hard to extract a signal under such circumstances. Unless you're hiring for a job where a willingness to bend the rules to get results is desirable - used car sales, for example.
> Nothing stops someone spending 6 hours on a "2 hour" take home test, producing a better solution than someone who followed the time limit strictly.
Unless you can ... demonstrate you only spent two hours. It's pretty rare you can do that, but... several years back I got a callback on an interview, and they forwarded me the 'coding test' portion. I got it around 1:30p, and I emailed them back the finished product around 3:45p, so.. a bit over two hours, including download and setup of their test environment.
I advanced further, but they ultimately chose someone else. I think I may have been a bit too senior/advanced for them, or.. maybe I was just a jerk in the interview, or... someone else was just a better fit? I'll never know.
I do know it was one of handful of interviews in the last 10+ years that was actually done well. On the technical side, they had a test git repo that actually worked - fork the repo, pull down, run the docker compose and everything just worked. I spoke to the woman who'd set it up and it was obvious she'd put a lot of time in to making it all as smooth as possible, and it was. I wanted to work there just because she'd put that much effort just in to 'a test'.
I will say that this is something you definitely should not be, especially if it's a larger corp. You should be political, passionate, approachable and friendly. It doesn't matter if you are more technically skilled. It might be even worse for interviewers if you are technically skilled and arrogant about it, because it would make their work lives worse. Even though I appreciate technical skill and passion, I wouldn't hire anyone who was actively arrogant or similar about it. I look to create a team that in theory would be supportive or empathetic towards low performers, although of course preferably we would find a solution to low performers or understand why they are performing low if possible, because ultimately I do want high performing team.
I certainly don't try to be... and I generally don't think I come across that way (rude, arrogant, etc) but I'm sure I've had my moments unintentionally. There's a limit to how much influence I can have on someone's perception, and I know I've said things in the past that have upset folks without meaning to, or just... knocked me out of the running for a particular technical point of view.
It's like most things can be done right - If anyone just cared to! And when I run into something done right, it's so refreshing.
But most things we interact with are done half-assedly, or are MVPs, or are deliberately made to a stupid spec, or don't prioritize the user, etc... there are a million ways to mess it up - usually by not even trying - and the result is draining.
Before I go any further, broadly speaking, I'm not in favour of take home tests, but not for the reasons you mention.
I did a stint of hiring for a software company over a decade ago where they did use a take home test. Now we did get the odd person cheat on it, but I can think of only a handful of occurrences where that had happened - at least in a way where it had meaningful impact - out of the probably hundreds of people we interviewed.
The take home test was simply there to figure out whether or not it was worth inviting an engineer in for interview, at which point we of course did an in person coding assessment. If you cheat at the take home test, what happens at the interview? You get found out is what happens, and it can lead to quite an awkward conversation. If you don't get found out perhaps it doesn't matter anyway because you've just got through a coding interview anyway. That's not to excuse cheating but to point out that it's perhaps only a risk in terms of technical skill if it's your sole point of assessment of those skills.
But, anyway, as I say: I don't much like take home tests for other reasons. And I don't much like platforms like Codility either (with these I found the signal to noise ratio to be particularly poor). The reason I don't like any of this stuff though is that, if you're hiring, most likely it disadvantages you as an employer versus other companies who don't put candidates through these tests.
Unless you work for a company where everyone wants to work you have to ask yourself this question: why would anyone willingly go through our burdensome and tedious selection process when they can get a job on a similar, or maybe even better, salary elsewhere much more easily?
It's hard to extract a signal about prospective work quality from anything but a trusted referal or a probationary hire. It's not like there's a great alternative just being ignored.
Some orgs feel more comfortable assuming that whiteboard performance represents general aptitude rather than drill practice, some are more comfortable assuming that small assignments represent work simulation rather than plagiarism or misrepresentation. Both approaches are swamped by noise, but when you're sieving innumerable applicants and are accountable to an image of fairness and standardization, you have to use something.
So if you do a take home, I believe you MUST follow it up with a live review. It becomes painfully obvious who cheated based on their ability to reason about their decisions.
In my experience, the single best question for screening out overt charlatans is a simple "Tell me about a problem you've worked on recently." Everybody engaged with technical work has a few war stories, and they're hard to fabricate without a deep understanding of the domain (at which point they wouldn't be a charlatan, now would they). It generally relaxes nervous candidates a bit, since it's external enough to not feel like bragging, while being self-congratulatory in that candidates almost always talk about a problem they succeeded in solving (and the ones who don't are always talking about a very interesting problem). What kind of problem they describe tends to give you some insight into their strengths, and their general enthusiasm clues you into their interests. Throw in some probing questions if they don't go into enough detail, and you can come out the other end of it pretty confident whether they have technical chops or not.
So far, it's been extremely successful for me in predicting whether a candidates going to get weeded out by the rest of the interviewing process or not.
This selects for people that are chained to their email and slavishly do whatever the company says immediately -- probably intentional, and you dodged a bullet.
If a company sends me a take-home, they aren't getting it back any less than 24 hours later. I prefer if I can open it, read it and then come back to it later.
I hate it when I have to immediately open it and finish it, like a timed coding test, although I don't bother with those because I don't think I've ever passed one...
This. Email is async. I don't have notifications set up for email. I go over private email once a day. Yes even when interviewing this would only be something like once every few hours.
We can set up a time at which you will send me the take home in advance of course. Like "we will send this to you Friday around 6p.m." coz I told you that this is when I will have time for it.
You send it to me 1:37pm on a Wednesday? Forget it. I am working during that time so I won't see your email and even if I did I have no time for it. I'm working.
In the past I've even written a quick batch file to change all of the creation and modification time stamps for all files to the exact same time where they wanted a zip file. As well as setting the date and time of the git commit to a time before they sent me the take home where they wanted me to commit something to a repo.
It either goes completely unnoticed and that's fine or it makes for a nice technical convo. Meaning if someone notices and talks to me about it it would make it more likely for me to accept an offer because they have people working there already that know and understand such technical details and find them fun too. Vs. most where they would be in shock and awe how such a thing is even possible.
It's always a good idea to follow up with them in an interview, where you can ask the candidate questions about their implementation. Makes cheating much harder.
It's been a long time since I've been on the job market - but even a decade ago, I had third-party recruiters who would forward me a take home test... and another successful candidate's solution, "for reference".
And even if candidate doesn't get external help, I'm extremely sceptical about time limits. Nothing stops someone spending 6 hours on a "2 hour" take home test, producing a better solution than someone who followed the time limit strictly.
It's pretty hard to extract a signal under such circumstances. Unless you're hiring for a job where a willingness to bend the rules to get results is desirable - used car sales, for example.