The place I used to work had actually tried something like this, but it completely fell apart, and I imagine when I tell this story you'll realise why.
One guy came to us from a recruiter highly-recommended. He had a few years experience, but he was widely respected online via his community contributions. He was also out of a job due to redundancies. It was enough to get him an interview, and he could talk well, so my bosses got the dev manager to set up some basic problems on a client website to solve.
He seemed like a nice guy, and he had a lot of questions, which was a good thing. He had a nice chat with some guys over lunch, telling them that he'd been unemployed for several months, and he was down to his last savings. He was able to fix the problem purely through looking on some forums for the answer, and that answer helped him fix the problem. The dev manager was happy, and the PM's were happy. The devs that worked with him were brought into a room to see his solution, and everyone in there said he should be hired. We had a new dev!
He was instantly given a project from the backlog, which was billed out, and would take around six months. He clearly knew what he was doing, so he was left to his own devices. To cut a long story short, the code he was writing was absolutely shocking, and he'd engineered a solution you'd need a PhD to understand. He was also finishing tasks really quickly, but they were bounced right back to him because his code was full of bugs. He stayed with the company for a while longer, but was ultimately let go. That project went over budget by six figures. It turned out that he was let go from his last two places for similar reasons. He was a junior developer that believed himself to be senior, and as such he disregarded any advice from anyone but managers. He had claimed open source contributions, but he was widely considered because he'd made thousands of posts on an open-source project forum, and due to their community contribution rules these posts deemed him a candidate for MVP. Despite thousands of posts, he'd never really solved a problem for anyone.
I looked through the code he had written during his trial, and it was largely the same mess, but obviously smaller and self-contained. It wasn't an optimal solution, and he'd written 500 lines of code for what should be a 20 liner. The dev manager used to be a programmer, but hadn't written code in a while, and didn't see a huge problem with it. When the rest of the devs were asked about it, they all said that they thought his code was messy/crazy, but the managers wanted him, and the guy really needed a job, so they said yes.
I'm not saying that this solution isn't a good one. If you can do it, I'd argue that it's the best way for a typical company to hire a developer. What I would add is the following:
1. Management should not publicly offer their opinion on a candidate before technical advice is given. If the managers weren't praising him, our devs might have had the confidence to say no.
2. Any technical test should be fully QA'd before a "Yes/No" is given. You're not just looking for someone that can write code. You're looking for someone with ___domain knowledge of your tool-set that can offer solutions to problems. If you're shown a bunch of code with little context. Funny enough, the code that he submitted was actually fixed by another dev on the following Monday.
3. Make sure they're not working on something that actually needs to be delivered in the next week. This guy was brought into the office on a weekday because he was unemployed, but it turns out most of the pressure for this was from a PM who said that the problem he needed to work on was actually required in that sprint.
One guy came to us from a recruiter highly-recommended. He had a few years experience, but he was widely respected online via his community contributions. He was also out of a job due to redundancies. It was enough to get him an interview, and he could talk well, so my bosses got the dev manager to set up some basic problems on a client website to solve.
He seemed like a nice guy, and he had a lot of questions, which was a good thing. He had a nice chat with some guys over lunch, telling them that he'd been unemployed for several months, and he was down to his last savings. He was able to fix the problem purely through looking on some forums for the answer, and that answer helped him fix the problem. The dev manager was happy, and the PM's were happy. The devs that worked with him were brought into a room to see his solution, and everyone in there said he should be hired. We had a new dev!
He was instantly given a project from the backlog, which was billed out, and would take around six months. He clearly knew what he was doing, so he was left to his own devices. To cut a long story short, the code he was writing was absolutely shocking, and he'd engineered a solution you'd need a PhD to understand. He was also finishing tasks really quickly, but they were bounced right back to him because his code was full of bugs. He stayed with the company for a while longer, but was ultimately let go. That project went over budget by six figures. It turned out that he was let go from his last two places for similar reasons. He was a junior developer that believed himself to be senior, and as such he disregarded any advice from anyone but managers. He had claimed open source contributions, but he was widely considered because he'd made thousands of posts on an open-source project forum, and due to their community contribution rules these posts deemed him a candidate for MVP. Despite thousands of posts, he'd never really solved a problem for anyone.
I looked through the code he had written during his trial, and it was largely the same mess, but obviously smaller and self-contained. It wasn't an optimal solution, and he'd written 500 lines of code for what should be a 20 liner. The dev manager used to be a programmer, but hadn't written code in a while, and didn't see a huge problem with it. When the rest of the devs were asked about it, they all said that they thought his code was messy/crazy, but the managers wanted him, and the guy really needed a job, so they said yes.
I'm not saying that this solution isn't a good one. If you can do it, I'd argue that it's the best way for a typical company to hire a developer. What I would add is the following:
1. Management should not publicly offer their opinion on a candidate before technical advice is given. If the managers weren't praising him, our devs might have had the confidence to say no.
2. Any technical test should be fully QA'd before a "Yes/No" is given. You're not just looking for someone that can write code. You're looking for someone with ___domain knowledge of your tool-set that can offer solutions to problems. If you're shown a bunch of code with little context. Funny enough, the code that he submitted was actually fixed by another dev on the following Monday.
3. Make sure they're not working on something that actually needs to be delivered in the next week. This guy was brought into the office on a weekday because he was unemployed, but it turns out most of the pressure for this was from a PM who said that the problem he needed to work on was actually required in that sprint.