I think this method is good in theory but fails in practice. Recently, I applied to three different companies that asked me to do a code sample that took from about two to eight hours each. I generally don't work for free, but I had some spare time and decided why not? I did all three and turned them in. Out of three, one company liked my sample but in the interview that followed, decided that what I was asking was too much (it's what I'm currently making actually). One company never even looked at the code and after two weeks, emailed back saying they had forgotten and decided to hire someone else. The third company was pretty responsive and I'll be going in for an in-person. A seven hour in-person interview that will be more coding and such (at least on a laptop so it's better than most places). So one out of three. I think this is a huge problem with this approach and basically, most companies are not responsible enough to follow this approach. They drop the ball constantly and wonder why they can't find good engineers when they're literally everywhere. Put into the hands of a respectable company, I would definitely prefer this in the future rather than the typical white board bullshit and trivia slinging.
What you've just described sounds like the exact opposite of a rigorous, objective, work sample based hiring approach. Crappy companies have crappy hiring processes. It sucks to deal with that.
When we started doing work sample hiring, we put a process in place to handle many applicants, make sure we were responsive, and work people through the funnel as efficiently as we could. I don't think it's possible to take advantage of it any other way.
We got complimented several times on how reasonable the process was (by people we turned down!). This both made me feel good, and caused me existential "the world is broken" sadness. It's not a high bar to be decent to people.
No, it's not a high bar to be decent to people, yet many companies (and people) still aren't. The problem then is that prospective employees have no way of knowing that a company is decent versus another company that is not. Will I do another work sample for another company? I'm thinking likely not, but I haven't ruled out the possibility. Note though, that the company must offer something of great value for me to even consider it. In my case, that's remote work. I would never consider it for a non-remote company. Period.
Still, a company could have a great, responsive process in place. But my experience, and that of others, is that it's not worth my time and effort to do work for free. Let's be clear: this is what is being asked of the candidates. It therefore starts to undermine any company using such a process even though I don't think it's an inherently bad process.
Just ask "what is your process and criteria for hiring?" It's a fair question, a company should have a good answer. A thoughtful process is a good sign.
I've recently had a very similar experience with work sample/coding tests and I completely agree. It strikes me that most people setting these tasks are pretty clueless about how difficult the task is and haven't tested them out on non-candidates.
How they're implemented has varied wildly between companies, but most of them were used as an initial screener rather than a major deciding factor, despite being one of the most time consuming parts of the process for the candidate.
Like you I was able to go through with most of them, but I felt like they were a massive waste of my free time and companies were often very slow to follow up in it. I think a lot of the time it just isn't worth jumping through these hoops for a company I don't know anything about.
My best test I took was around an hour and involved building a really basic CRUD app in Django as part of a larger face to face interview, followed by a short discussion. It worked well because they set up an environment for me, the data model was fixed, and there was a list of short requirements I could complete in order, so I was able to just dive into the work, and spend time on the kind of things that were relevant.
Another one basically asked me to take a large dataset, build a web application around it, and deploy it, which would probably have taken me a week to complete but "should" have taken around 3 hours. They tried to present it a really interesting problem I would enjoy working on and then asked me to keep all my work confidential.
Most of the tests I've done are still closer to general problem solving/comp sci tests, which is still pretty far removed from the actual work, but at least they're not a huge time sink when implemented properly.
