I recently designed a take-home. I made sure to pick a real, interesting, problem we faced, and one where there is a very high dynamic range of responses - it can distinguish between good and bad juniors (I know this because I let all my students try it if they want, which also gave me great deal flow of juniors without even needing to spend time on screening the bad ones), and it gives some information even at my level (I didn't arrive at the best possible solution myself, someone came up with a better solution to one subproblem).<p>I like respecting candidates' time, because I want the strongest candidates to not filter themselves out at the mention of a take-home. That's why I ask them to schedule 4 hours with me where at the start they will get the problem description and at the end they will submit what they have - this way they aren't pressured to put in more time because they know for sure that their competitors didn't - and I get to compare apples to apples.<p>I also designed the rules to minimize the perverse incentives set by the clock by giving multiple ways to get recognition for partial solutions.<p>This is the content of the document the candidate gets initially (they only get the actual problem later):<p>Meta<p>This is a real task we encountered and solved at Finubit. Out of respect for your time, we limit this task to 4 hours (of wallclock time, to remove the incentive to spend more than that to gain a competitive advantage). It took us much more than four hours to get the perfect solution, so don't worry, we don’t expect a full production-ready solution to 100% of the problem.<p>We ask that you approach this task as you would the first 4 hours out of as much time as you need to finish the task to a reasonable quality standard. We do want to see a working Proof Of Concept at the end of those 4 hours, like we would ask of any team member picking up a long, open-ended research task. The POC can be very limited in functionality, but functionality that it promises will be held to a standard of quality.<p>If you encounter ambiguities or mistakes, assume the most reasonable way to resolve them and make a note to check with Product that your understanding was correct. If you disagree with Product about something, make a note to push back against the design decision they made (but in the meantime assume the current spec, unless it's grossly wrong). If there's a subcomponent in your design that you don't know how to implement but believe to be solvable, it's OK to assume the existence of a black box that solves it.<p>Please take a moment to set an alarm clock. When the clock strikes 4 hours, please send us your code and research notes, and then go over the code and document everything you’d change before you consider the code production-ready and send us the annotated code.<p>We will be available to answer clarification questions if needed.<p>Then there is a checklist to reduce loss on technicalities (forgetting to set an alarm or send annotations).<p>(If you're in Israel, and you want to try it for fun, shoot me an email)