[shagie]

> The majority of the companies I noticed issuing takehomes weren’t your star companies. They weren’t FAANG. They weren’t looking to change the world. They weren’t looking for olympiad champions or kumon alumnis.

> Rather, they were the design studios, the lean web development agencies, the mobile dev teams based out of Eastern Europe.

Given a team of... let's make up some numbers.... {8} devs working on client projects that have {250} candidates to evaluate, how much time do the {senior} members of the team have to evaluate them? Note that taking {two} senior devs in such a shop out for {30 minutes} for each candidate for a live coding interview is {=about a week and a half} of nothing but doing interviews for each of them - removing them from other revenue generating tasks and a reduction of {at least 1/4th} of the work for that duration.

Extending this beyond 2 weeks of time means that the best candidates are likely to have found other opportunities.

Take home tasks shifts that time to a standardized "I can look at this sample code in 2-3 minutes and get a feel of if the candidate will be producing something maintainable or hot garbage."

At that point, one can narrow down the pool of candidates down to a small number that can be interviewed and decided with some expedience.

[vundercind]

The flip side is that there’s no way I’m doing a “two hour” (really 4-8 hour) take-home if I’m still at the stage where there are 250 candidates. Or 25, even. Maybe three.

[shagie]

The next question would be "how do you narrow from {250} down to {25} by spending at most 3 minutes per resume?"

The answer there is often "select only the ones that show the most things on the resume without evaluation of their practical skills" ... and we get to the complaints then of "but people lie on their resumes all the time" and "but my skills at coding aren't things that I can reflect on the resume?"

And when you're spending 3-4 minutes per resume, you don't have time to open up a GitHub link and try to figure out if the person who this is wrote the code or if they just forked another repo ... and what contributions are theirs.

For evaluating a coder, the time imbalance is heavy on one side or the other.

Having two people do seven hours of interviews a day for two weeks is also in the "not feasible" category. As its the company that is setting up the criteria for the interview, they've got the first move and are setting up a process that they can fairly evaluate the candidates that apply and go forward with that step in a way that is most likely to eliminate the most risky candidates and find the candidates that have the skills but don't present well on a resume.

[vundercind]

That’s offloading nearly a quarter of a person-year of work onto the 250 candidates—potentially much more, if it’s more than a truly-two-hour assignment. To save yourselves a far smaller amount of work. And that’s for just one stage of the interview process!

249 will receive no benefit for their work.

Nobody with options is gonna take that offer and you’ll be left with the desperate. It’s beyond rude, it’s a bad joke. If desperate’s what you want, then I guess go for it.

[shagie]

I am certainly not saying that it is time fair or that it doesn't result in a lot of excess work being done.

Take home assignments are there to minimize the amount of time spent per candidate with the most limited resource in the interview process - the people on a small team doing the interviews.

That is the problem that it is trying to solve.

Trying to minimize for the candidate time spent, increases the amount of the limited resource (the interviewers' time) and may mean that the interview process will be longer than is acceptable for candidates (are you willing to wait 4 weeks between the last interview and offer?) and removes the interviewers from revenue generating tasks.

There is no good solution to this. Often take home assignments are the least bad solution.