As an interviewer, I think they are the best at assessing the coding aspects of job performance. Not perfect, but better than high-pressure in-person whiteboard/coding tests.
As an interviewee, I like the flexibility to work on it as I have time (rather than using up PTO).
The point of using algorithms isn't to test your algorithm skills (though using job relevant algorithms is a good idea if you can) but to test your ability to translate requirements into code by eliminating the quality of requirement specification as a variable. That is, because algorithms have an unambiguous specification, failing the coding assignment due to poorly specified requirements should impossible (or much less likely).
For the non-coding part of the job, I find a (relatively short) structured interview works best.
As an interviewer homework loops are easier for you. Of course. It requires significantly less of your time time. You don't have to actually confront a human being in front of you, understand the thought-process they went through in doing the work, answer questions about yourself, projects, or the company. You can say no by typing a bit.
You've taken all of the leverage and one-sided information, given nothing to the candidate, and you expect them to be okay with this without payment. Good candidates, myself included, will not jump through arbitrary hoops or suffer such foolery.
I have ample github history, 15 years of senior-level experience with good companies, and the ability to discuss solutions at every level in a tech-stack. I will not coderpad on my own or do unpaid homework. I will pair-program for an hour with an agreeable potential-colleague, but not with somebody who's hiring for other teams.
When you say jump, I say jump with me or I'll see ya later.
This is a huge part of it to me. In a whiteboard/pair-programming interview, you get the ability to judge the company and potential colleagues. In a take home, you get absolutely nothing out of it.
> As an interviewer homework loops are easier for you.
I have been on both the interviewee and interviewer side of this interview style, and I speak from both perspectives when I say that like this style.
> You don't have to actually confront a human being in front of you, understand the thought-process they went through in doing the work, answer questions about yourself, projects, or the company. You can say no by typing a bit.
Are you assuming that the homework is the only part of the interview process? That's absurd. Once they complete the assignment (which should be an objective thing to assess with practically unambiguous criteria) they are brought in to an interview. If they did a good job on the homework, they'll likely get the job. I would rather not ask them to take time out of their workday for their current employer until I think there's a good chance we will extend them an offer.
The interview is exactly what you describe: a chance for them to evaluate me, for us to have a discussion about their thought process regarding their code, about their prior experience, etc.
> You've taken all of the leverage and one-sided information, given nothing to the candidate
Not sure what you are mean exactly here.
> and you expect them to be okay with this without payment.
I also expect them to send me a resume without payment, and people can easily take as much time editing and formatting their resume as they do on the coding assignment.
I'm not categorically opposed to the idea of paying candidates who submit a (correct) solution to the homework assignment. That seems like a nice gesture. It just wasn't an idea that ever came up in discussion, and in retrospect doesn't really seem like it was necessary.
Honest question: If you were to get paid for a completed homework assignment, would all of your objections go away?
> Good candidates, myself included, will not jump through arbitrary hoops or suffer such foolery.
We had some really good candidates (and hires) using this process, but nice No True Scotsman.
> I have ample github history, 15 years of senior-level experience with good companies, and the ability to discuss solutions at every level in a tech-stack.
Good for you.
For every candidate, I would always assess the homework assignment before looking at their resume, or even seeing their name. I wanted to have it be as much of a "blind audition" as possible. We brought in people with weak homework assignments and strong resumes, and people with strong homework assignments and weak resumes (and other combinations). While not a huge sample size, the experience of myself and others on my team was that a strong homework assignment was a better predictor of a good interview and job performance than a strong resume.
> I will not coderpad on my own or do unpaid homework. I will pair-program for an hour with an agreeable potential-colleague, but not with somebody who's hiring for other teams.
If that's your preference, that's fine. As professionals in the same industry who both in good faith want to improve the state of interviewing, we can discuss the trade-offs between homework and pair-programming.
But let's not pretend there are no trade-offs. Time-boxed live programming interviews favor people who are good at working under pressure and who are already familiar the the technical stack. They filter out people who may be great engineers but are more deliberative or come from a different tech stack.
The issue with homework is that the top percentage of engineers really won't have any time to complete a multi-hour homework assessment that might not even be graded by a human. For spammy applications or bad colleges sure. But that's not the target demographic.
How will said engineers have an entire day to do an onsite interview loop, if they can't carve out a couple of hours to do a homework assignment?
My real problem with take home assignments is that while they take away the stress of being put on the spot in front of a whiteboard, often, the reward for doing well on them is... being put on the spot in front of a whiteboard. If anything, it might get one past the phone screen, but phone screens are not the biggest problem in SWE hiring.
The homework assignment is low effort on the employer's side but high effort on the candidate's side. Especially if it's through some SaaS where even the grading is automated. If you are Google then sure, candidates will take the challenge. But the reward is a job at Google. I'm not against take homes, I've said it here[0], they are great when you are swarmed with low quality resumes from places that have a bad application to hire ratio.
To me an on-site is more serious and shows commitment. You are asking the candidate to dedicate an entire day but asking the same to your engineering team. From my experience, engineers with multiple competing offers will go to an on-sites with certain companies that they would have ignored had they sent an online homework.
As an interviewee, a full-day onsite is much more of a turn-off for me. I don't want to use up PTO for my current employer for such a long, stressful interview process, especially without any indication of the likelihood that I will get an offer.
> How will said engineers have an entire day to do an onsite interview loop
Right. This practice is not better than an onsite. It's actually worse. Not only do you have to put in arbitrary amounts of time, you're not able to do any actual assessment of a prospective employer. You have nothing to go on other than a random problem statement which the company could have perfected over hundreds of hours and interviews. It's giving the employer all the leverage while also doing work for them for free.
> often, the reward for doing well on them is... being put on the spot in front of a whiteboard.
Ha! That can be true. So for me personally, I had candidates do a little bit of whiteboarding, but all I do is ask them to walk me through the execution of the algorithm they just implemented using minimal input parameters. Really what I'm looking for is the ability to explain how their code works (and to make sure they didn't copy someone else's work).
My company makes us interview with whiteboard problems. It's stupid but not my decision. My favorite spin on this is the reverse problem.
Ask the candidate to talk about, solve, and explain their favorite whiteboard-style problem. Ask them for something they were initially intimidated by. Maybe ask them a slight twist of it. We all know candidates study riddle problems, so let's both take advantage of that rather than giving an anxiety-test even if it's phrased as low-key.
This actually measures communication skills, and it's often overlooked. If someone's able to clearly explain a design they did or an algorithm/data-structure that's non-trivial it's a good thing.
Not every company, true. But, I've interviewed at least 20 or 30 times over the course of my career, and every one had an onsite loop of at least 4 hours in length. None of hte companies were FAANG, or even close. More than 90% were your typical whiteboard hazing style.
That's really not my experience. The places I've worked that have assignments like have managed to hire some pretty good senior engineering talent, and these people also often have pretty involved lives outside of work (families, communities, etc.).
You've gotten lucky. Imagine how many candidates have taken a look at your process and decided to value their own time and instead look at companies that don't jerk people around.
If some people find this process too burdensome, that's their right. But plenty of skilled engineers that I've worked with don't see it as being jerked around. At the very least, I find it less burdensome that turning coding into some sort of live-performance (which an in-person coding test inevitably is).
Personally, I don't judge an hiring process primarily by how convenient it is for me. I judge it by how likely it is to be a good filter. If the company I'm applying to has a hiring process that is effective at selecting good candidates (along a number of different dimensions) then I'm more likely to enjoy working with the people there.
From this perspective, homework assignments are a good filter, and so companies that use that approach seem like better places to apply.
As an interviewer, I think they are the best at assessing the coding aspects of job performance. Not perfect, but better than high-pressure in-person whiteboard/coding tests.
As an interviewee, I like the flexibility to work on it as I have time (rather than using up PTO).
The point of using algorithms isn't to test your algorithm skills (though using job relevant algorithms is a good idea if you can) but to test your ability to translate requirements into code by eliminating the quality of requirement specification as a variable. That is, because algorithms have an unambiguous specification, failing the coding assignment due to poorly specified requirements should impossible (or much less likely).
For the non-coding part of the job, I find a (relatively short) structured interview works best.