I think take-home assignments are great, but companies using them should be willing to put in the time to properly review and give feedback. And - spoiler alert

I think take-home assignments are great, but companies using them should be willing to put in the time to properly review and give feedback. And - spoiler alert - that takes a whole lot more effort than companies like fly.io are putting in, as evidenced from the comments on here. The reason take-home assignments can work well in my opinion is that it allows the candidate to show off how they perform in _real world_ scenarios - as opposed to live coding computer science toy problems. Interviewers can assess what code looks like that resembles the code candidates would likely write on the job. What companies like fly.io are doing wrong: if you ask candidates to put in multiple hours writing code for free, the _least_ you can do is give them an interview to give the candidate feedback on their assignment, even if you're going to reject them. In case of rejection, it doesn't have to take more than 15 minutes of time from the interviewers (which is far less than the hours the candidate put in) and the candidate walks away with (1) valuable feedback that can help them improve and (2) a positive view on the company and their hiring processes. What many companies don't understand is that your goal should be for candidates you reject, to still become "promoters" of your company. Here is how we do it at Source.ag: 1. If the resume is promising, we always do a first screening interview with the candidate _before_ we even consider them for a take-home assignment 2. The candidate gets the take-home assignment after passing the interview, works on it and sends us back their solution 3. We schedule a technical interview with the candidate. This interview can basically have 3 formats: a. the assignment was bad: we tell the candidate at the beginning of the interview we don't intend to continue with them and give them some personal feedback on the assignment b. the assignment was great: we take time to ask the candidate about their solution, to elaborate on their tech choices etc. and generally use the interview to understand if their "talk" is just as good as their "walk" c. the assignment was ok-ish: we use the interview to figure out what the candidate's engineering knowledge is and to what extend it complements what we got from the assignment. It could be that a candidate didn't perform super well on the assignment, but when talking to them we discover there is enough skill, knowledge and team-fit to work with. This happens mostly for junior-medior candidates, not for seniors. This is a time investment for us as a company, but has gotten us good hiring results and a positive reputation when it comes to hiring practices.