A Method I’ve Used to Eliminate Bad Tech Hires

Not to say you shouldn't do this but it's very important to remember a lot of these kind of things when it comes to recruiting involve tradeoffs and you rarely get an unalloyed good.

Where I work, our take-home is a simplified version of a task that's common enough (in our field) that we built tooling for it. It's generic, it tests understanding of a few things, and we've gone through three iterations of our own tooling so we know there are multiple viable approaches.

As for judging decisions, that's why the interview that goes with it is a collaborative code review. You treat it the same as if you were reviewing code a co-worker had written; ask questions, discuss tradeoffs, etc. etc.

> Since the candidate is getting paid, the candidate treats it as a legit consulting session and therefore gives their best effort in solving the problem.

If a candidate has applied for a job then it is in his interest to treat that application as his career depends on it. Best effort is wagered not on the fact that he is paid but on the premise that his life will become better by getting this job.

> It gives the candidate a real life sense of how you interact with people on the team.

Where is this coming from ? This is just another assumption the author is making.

> The biggest issue I have seen with tech hires is that they can become very defensive over their solution. I will purposely challenge their solution to see how they react.

You are asking us to be non-judgemental in the paragraphs above and then being judgemental on the candidate becoming defensive.

> Pay them immediately on Monday

Why ?

Really? I've found blanket IP ownership to be more common than noncompetes, at least in US outside CA. My experience, is that noncompetes are more likely to be limited to key personnel, whereas the company IP is sacred and must not be tainted, and the employee is not to be trusted to come up with their own material on their own time, at least not without sign-off.

Blanket IP is really back-door antimoonlighting anyway. You can't very well moonlight as a software developer if your employer is encumbering your IP.

I'm sure the California startup world is different from my experience.

When I was first looking for a software job I was a researcher who'd written a lot of his own tools but I didn't yet have an open source portfolio or commercial development experience. Solving a challenge was a great way to break the chicken-and-egg dilemma of needing experience to get hired and needing to be hired to get experience.

If I had to switch jobs again I'd also love to find employers screening with weekend challenges instead of live coding. Paying me to complete challenges would just be icing on the cake. I've done well at every company I've worked at, but asking me to write heapsort or whatever while you're peering over my shoulder and the clock is ticking is extremely stressful and unrepresentative.

I'm one of the people screening hires at my current job and I don't want to subject candidates to stressful live coding. But neither would I want to hire someone who can't write decent code and challenges look like a good way to prevent that. Surprisingly, even some people who include a github link in their CV are sharing code that's quite poor. (Like turning O(1) operations in an inner loop into O(N) because they picked the wrong collection type, in a language that offers perfectly suited collections in the standard library.) Maybe they think that nobody will actually read it, and having a github account at all will mark them as savvy?