I've been giving applicants home assignments for years now, in 3 companies. I do it as a third step, only after a phone screening and at least one personal interview (that might include some very very light whiteboard coding, but will touch a lot of technical stuff), and only if I find the person to be right for the job.
So out of dozens of CVs, a handful will be invited to a personal interview, and maybe one or two people will actually get the home test. I get that it's time consuming so I try not to waste people's time if I'm not serious about them. On a couple of occasions when people said they're time limited, interviewing for a lot of places, etc - I've allowed them a one hour on site task that is of course simpler.
And it's very rare that people are rejected based solely on the code in the home test, it usually has more factors than that. But if you have two good candidates, it might help tip the balance in favor of one of them.
BTW I don't only review the code. I find that the quality of the documentation (not only comments - I ask for a short text describing the design choices, code structure, etc) is usually one of the best signals. Bad grammar and poor language, complicated descriptions of simple things, focusing on unimportant parts - are huge telltales of problems in a person's thinking. Clear, well versed, concise text usually indicates a smart and pragmatic person.
So out of dozens of CVs, a handful will be invited to a personal interview, and maybe one or two people will actually get the home test. I get that it's time consuming so I try not to waste people's time if I'm not serious about them. On a couple of occasions when people said they're time limited, interviewing for a lot of places, etc - I've allowed them a one hour on site task that is of course simpler.
And it's very rare that people are rejected based solely on the code in the home test, it usually has more factors than that. But if you have two good candidates, it might help tip the balance in favor of one of them.
BTW I don't only review the code. I find that the quality of the documentation (not only comments - I ask for a short text describing the design choices, code structure, etc) is usually one of the best signals. Bad grammar and poor language, complicated descriptions of simple things, focusing on unimportant parts - are huge telltales of problems in a person's thinking. Clear, well versed, concise text usually indicates a smart and pragmatic person.