The business of takehome assessments

    for i in $( ls | grep “a complicated enough filter that I never have to use conditionals in my loop”) ;
    do
         echo -n “if I don’t want to work on ” $i 
        echo “ it is time to change languages” 
    done

It's almost the opposite of what the job actually entails. I rarely estimate that a project will take 3 hours and then I have 48 uninterrupted hours in which to accomplish it, no biggie if it takes more than 3. The job is typically the opposite, where I estimate it will take 3 hours and then I realized that I need to accomplish 40 hours of work in the 20 meeting-free work hours I have this week so I need to find a way to finish it in 90 minutes.

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.

I also designed the rules to minimize the perverse incentives set by the clock by giving multiple ways to get recognition for partial solutions.

This is the content of the document the candidate gets initially (they only get the actual problem later):

Meta

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.

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.

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.

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.

We will be available to answer clarification questions if needed.

Then there is a checklist to reduce loss on technicalities (forgetting to set an alarm or send annotations).

(If you're in Israel, and you want to try it for fun, shoot me an email)