As such, if you hire any of those, you're hiring somebody with a proven willingness to ignore their contract, which is a strong anti-pattern.
"Work for contract for other employers" could literally mean I can't help my neighbor mow his lawn in exchange for a beer. In this case what it really means is a non-trivial amount of work done for meaningful profit.
If I fix a friends computer in exchange for a nice meal, I am using my relevant skills to perform work, but I'm not actually violating a contract forbidding outside work in a way that could ever possibly result in damages or firing for cause.
For a potential employee to be so rule-stricken as to concern themselves with performing a coding interview, that would be the potential red flag for me. So this could actually be another positive outcome of this approach.
You can call that a red flag, but it is the reality I live in. Maybe most of your candidates don't have that problem, but I would definitely be eliminated.
But since almost everything we do is in some way technically illegal, it is important for everyone to be able to function under that premise.
I mean, just to cut the check technically the employer would need a W-9, a work for hire contract, and who knows what else. Let's call the lawyer and spend $5k deciding whether we can do this, and then decide 6 months later it's too risky.... Or, we do it, get better hires, execute on our plans better, meet revenue targets, and succeed in the market, by not following all the rules, just the rules that matter.
Knowing the rules to follow and the rules to forget is the hardest part, but a crucial skill in life and business. The more you push the envelope, the faster you can run, and the more likely you are to combust. See Zenefits...
Learning of your little deal to pay them for software development work will be the stick they use to hit you with that interference suit.
Moreover, if you have a current employer that is sufficiently disrespectful of their employees that they'd even consider enforcing an anti-moonlighting clause in this circumstance, with the preposterous assertion that it qualifies as employment - run away now.
The law is not a programming language.
In California, it's illegal to prevent employees from moonlighting: https://californiaemploymentlaw.foxrothschild.com/2015/03/ar...
I would be much more willing to do the project if I knew the employer would lose $200. Among other things, this shows that I'm valued.
The thing is, there are always reasons why this method isn't viable. It's not till you try it that you notice huge gains.
I avoid these problems like the plague and very much prefer to whiteboard. If you pay me consultant rates, I can more easily justify the effort.
Edit: I most likely would have completed it if I were offered some type of compensation, even below market. They claimed it was an exercise and they wouldn't use it, but this was a startup with about 10 employees, and the deliverable was definitely something they could have used. That alone rubbed me the wrong way.
Who would have thought? Maybe - just maybe - not everyone has the same strengths and weaknesses. The real answer here is obvious: present the interviewee with options. Forcing all potential hires to whiteboard is a terrible idea. Forcing all potential hires to do a take-home project is a terrible idea. It's extremely short-sighted and a little pompous to assume that any single interview format one chooses is going to magically sort everyone into neat little buckets of "good" and "bad".
If you force the whiteboarding approach, you are only going to wind up hiring social butterflies who have absolutely no nerves standing up in front of complete strangers and having all the answers on the spot. If you force the take-home project approach, you're turning off a lot of people who can nail a first impression presenting themselves and their skillset in person.
People are different. Applying the same interview type to everyone is going to target a specific set of strengths, and a specific set of weaknesses. And frankly, no business should be composed entirely of one type of person. Some diversity does wonders when assessing the overall strength of a team.
Whiteboarding is a poor reflection of what people do day-to-day, and can be misleading if a candidate practices interview technique over coding experience. In other words, just because someone can regurgitate an algorithm on command, doesn't mean they'll be a good developer.
If all you want to optimise for is finding people who make a good first impression, by all means carry on with whiteboarding. However, if you want to find good developers then there is a one-size-fits-all solution, and that's to see how they develop code in the real world, which is exactly what the 'weekend project + appraisal' approach is a great fit for.
If you're a company that does any kind of business with the federal government, that's simply not an option. You have to be super-consistent in terms of your interviewing and recruiting process across all candidates for a job req and can't do things for some candidates without doing it for all of them.
I think that would be misusing this approach.
We build recruitment software.
The recruitment process is a funnel. At each stage, the employer tries to weed out the bad candidates. Simple maths says they try and use cheaper tests early on in the process when there are more candidates.
For example, first stage is often eyeballing the resume and a quick search on GitHub/SO. 5 minutes, costs say $10, weeds out say 65% of candidates.
At the next stage, we use a more expensive test, since we have fewer candidates to filter.
This particular test sounds like it would sit after an initial phone screen and before a team interview in terms of cost.
Personally I would only use it after a first interview, or tell the candidate that you will decide immediately after completion of the first interview whether it was successful, and if so send them away to do this project afterwards,i.e. reduce double handling
That means you don't care enough about changing jobs. There are people who will happily do that "interview" for free even when being employed full-time. The only relevant question for the company is whether there are enough qualified candidates willing to do the test for free.
...as someone that's fully employed I'm probably only looking at jobs I'm really interested in. I don't mind doing some free work for stuff I'm interested in. I also enjoy doing small unpaid side projects or programming puzzles in my free time...basically the same concept.
That being said, my guess is (ignoring legal implications) paying 200$ or whatever for it is actually more beneficial to the company than expecting you to do it for free so it seems like a nobrainer (once again assuming you can handle legal). Reciprocity and all.
I do something that I enjoy and throw it away afterwards or whatever I tend to do with little programming puzzles and project Euler stuff or I do the same thing and a company profits off it. The profiting doesn't really hurt me so I don't mind it. I'd also argue that if the intention of a company is to profit off my interview code I'm hopefully filtering them out (as they tend to be pretty boring)...having people write code for you by pretending to offer a job is also all kinds of horrible strategically so I don't see the potential for a mass exploit.
I can understand your point of view but I hear the dreaded "but my time is too valuable" more often than "it's unfair that they profit of it". My argument was mostly that...if you want the job, your time probably isn't too valuable to try to get it :)
I'd much rather travel and meet you in person and do stuff there, but if you don't have the budget for it, we could figure other stuff out (shared docs, skype, whatever, I've done a few of these on both ends with some luck).
"Since the candidate is getting paid" seems like far weaker motivation than "since the candidate wants the job you're offering," which is what's going to determine my level of effort.
The "not a real problem" thing is key, though. I've tried testing out a few different "this is one of our real problem" things but there's almost always more hidden business rules or assumptions in there than you think.
There's a concept around a lot of preliminary engagements between two entities called "skin in the game." The idea is that when something is completely free the other party will take advantage of it without any real serious intent to follow through on anything.
Mostly this seems a reaction to the homework-type assignments where candidates are expected to spend a lot of time on some interview assignment with very little real cost to the company--which raises the possibility that it's effectively a cattle call.
I could run 50 candidates through a $200 problem for 10K. That's still a pretty large mismatch between "amount of work done by the candidate" and "amount of work done by the interviewer," and is cost-of-doing-business money for recruiting for a lot of companies currently.
Compare that to the cost of me flying people out (which is still done in this approach), or even the cost of spending an hour of mine or someone good on my team's time on the phone with them.
I guess it's just down to the difference between trying to hire fresh-out-of-college (or still in) free-time-to-spare junior devs and experienced people. That's actually a topic I should write a blog about somewhere myself, one day - I pushed pretty hard at my current company for moving towards a different process for industry candidates, and are extremely pleased with some of the people it's helped us hire.
I do agree that if people are flying around, that represents a fairly significant investment in any case. But in Silicon Valley, that often isn't true.
It's hopefully a case of coming up with processes that don't encourage people to waste others' time. But that also assumes some reasonable balance of power in the process.
Even after that, the "experience candidate phone call to see if they're worth flying in" part is definitely the one where I have the hardest time, being not in the Bay Area. I was lucky to find some great local people, where the cost was lower, because that's an expensive one to have to get good at fast. You lose a lot of nuance over the phone, though some other people in the company have been having very good luck with homework in this case - but as a candidate-choice option, where they could still go the traditional route if they wanted.
It's easier than it seems.
Just put a HackerRank test with a single question. "Print the numbers from 1 to 10 [inclusive, one number per line]".
20-30% of candidates won't attempt the test. 20-30% will be unable to give a decent solution.
If you're running 50 people through this, you're doing it wrong (unless you have 20+ positions).
I don't understand why you think improving your employment situation wouldn't be hard work.
Well that was very, very dumb of them. Maybe we engineers ain't so smart after all.
And I don't have an employee handbook. I own my own business.