The business of takehome assessments

My counterpoint to this is that takehome tests are great for folks who don't necessarily do well on brainteasers, but are otherwise strong functional developers. Despite having a family and children, I always prefer a takehome assessment. (And, just as an FYI, I'm 36 and a single parent to a young grade-schooler)

I might be biased, in that I feel like I do poorly in the live programming / brainteaser style interviews, but do strongly when I have a takehome assessment. Live programming is like a completely bizzaro-land version of programming, where a real person is staring you down while you type, observing your every interaction, and deciding your fate based on a random 60 minutes of the highest-stress part of your day. ("Oh, you googled a for loop syntax, you are clearly an idiot lying about your experience" when in fact, it's more like, "I get thrown 6 different programming languages every single week, each with similar but slightly varied syntax for every single thing, and having a person stare at me and decide the entire future of my career is a little bit stressful and anxiety-inducing").

With a takehome assessment, I can think about it for a while, I can write it all upfront, I can try a few different implementations and pick the one that feels best, I can accurately and intelligently explain exactly what I did and why I did it, I can talk in detail about the problem and potential tradeoffs. I can wrap the whole thing in nice automated testing, I can setup basic CI/CD for it on GitHub Actions or equivalent. I can demo my commitment to strong well-written clear documentation and dev experience, right in my branch Pull Request -- and all of that will likely be a closer match to what real-world day-to-day work at the new company might be like, than solving your LeetCode brainteaser.

I don't love "unpaid work before getting a job", yes that part sucks. But it sucks less than having a random stranger decide your an idiot, based on watching you sweat for an hour. Even if I'm going to get ultimately rejected anyway, the takehome route still feels better.

Sadly how people recruit is completely broken for most companies that are not FAANG etc. (It is broken for FAANG as well but in a different way).

As I often say "you need to win, not win an argument". Similarly you want candidates that can be good productive members of your team at the salary you are paying and not the candidates who can nail your interview process.

The problem with take home tests is not the cheating. But rather failure of the recruiter to actually evaluate the assignment. Do you care about the end result or do you care about the art of craft ? Do you care about readability of the code or performance of the app ? Is the assignment similar to the work candidate will end up doing at workplace ?

My suggestion generally has been:

1. Look at candidate's past work. Has candidate worked with reputed companies ? 2. Talk with candidate with general technology topics around their work. Something like "what do you like about react?" 3. Give candidate a very simple codesignal test. Nothing to fancy. Say if you want react engineers just test their ability to implement simple components.

This vastly kills a lot of inferior talent in my opinion.

4. Give a very simple problem without any "trick" or "iq test" and ask the candidate to code it in front of you. Also let the candidate use internet, documentation and AI tools.

In this day and age asking candidates NOt to use AI tools like asking a candidate to write code without using keyboard. You want people who can use things like Github copilot.