Take-home interviews

1) I didn't score well on the test. It's within reason they read this post and release my scores with a 'it was because he scored low'. Future employers then come across my scores and deny me.

2) Don't bite the hand that's like the hand that MIGHT feed you. You don't yell and storm out of investor meetings. Because then they tell other investors. Similar logic here.

3) This place is very optimistic. Pessimistic people aren't particularly desirable. Whistle blowers are included in the latter group especially by corporate entities. Who knows what it could cause.

It really boils down to the fact that it's not a safe environment to do so. Or at least it doesn't feel so.

So, if you are interviewing at 20 companies, you need to expend 100+ hours or almost 3 full work weeks?

It should take 1 hour or less. Period. Probably less that 1/2 hour. I doubt I get much more information asking you for a 5 hour assignment than a 1/2 hour assignment.

If I'm really that interested in your programming on the fly, I should do it at the interview where I'm paying for your lodging, food, etc. I should tell you what you are going to be doing, and to bring your laptop set up to do that.

The problem with Rosalind or Project Euler assignments is you end up with an excellent theoretical math or bioinformatics programmer. Often not bad, but not on point.

Fundamentally anyone with a degree or experience or a non-trivial github can write code, but you want to test their judgement, their thought process, their comprehension, their style, their knowledge about your business domain. Other than total open field blank slate projects (very little of my time over the last 35 yrs has been spent in that mode) you usually have existing systems and code. So give them a "special" sample of your own code. Shouldn't be too hard to find unless you're literally hiring the first technical employee. Then give it to them a couple days before an interview and inform then you're gonna review that code together, they'll present you with a rewritten, redesigned version, and then review the rewrite together.

If you'll feel bad about making them do "real" work, the best code to send out is some that has been heavily customized to only work some of the time, not properly error check, and intentionally somewhat obfuscated, so I sincerely hope that code thats screwed up to that level has to be intentionally manually generated for the interview. So strip out most of the failure/error detection code, screw up some of the code, maybe intentionally cut and paste an almost identical function in place to see if they clean that up. Some folks like intentional outright errors, like typos, is this the kind of programmer who can't write English? Also wipe most of the comments, put some intentional logic errors in the comments. This can be fun...

If you're looking for non-intro level programmers "everyone knows everyone" and my latest job we didn't talk programming because I was vouched for as knowing what I'm doing from years of coworker experience at a past employer. I'd be moderately offended if someone I worked with for five years asked me to fizzbuzz, either in person or as a take home test.