The real TL;DR: "I have no patience for jumping through <i>your</i> hiring hoops. Now, here's a list of <i>my</i> hiring hoops you'll need to jump through before I consider working for / hiring you."<p>I would never, <i>ever</i> hire this guy. With his hubris and self-centered worldview there's no way he'd work well with a team, and with his apparent aversion to writing code under any circumstances other than inside his own delicately-crafted bubble, I'd have serious doubts about his ability to hit a deadline.<p>Nor would I trust him as a manager. He walks out of an interview (multiple!) because they asked him to code (how <i>dare</i> they), then interviews the guy who responds to (an incredibly ridiculous) code test with a jokey response? Sounds like a great way to make friends, and a terrible way to find job candidates with strong skills.<p>Even if he was the greatest programmer/manager in the world, unless you're looking for a solo developer who doesn't need to produce within a given timeframe or a manager who values a "cold call with attitude" over a first-class résumé, you're in for a world of hurt.
I thought I'd write a graf about how much I disliked the "Screening" section of this, with its instruction for candidates to have "attitude" and to "make it fun" for him, but then I reread it and at the end he's saying things like "send him an email about one of his blog posts", and that sounds totally sane.<p>I recommend reconsidering "culture fit". The "culture fit" meme is poisonous. Mostly to the profession, but also to you, because it'll cause you to eject people who would be solid performers, eventually in favor of prima donnas who will underperform, feel no ownership of their work, and use your team solely as a stepping stone.<p>If you're convinced that "culture" matters, find a way to distill it to the culture attributes that directly implicate job performance. But then make sure those attributes don't exclude whole classes of life circumstances, like parenthood.<p>PS: I interviewed at Bloomberg about 10 years ago and enjoyed the experience immensely. I got hammered with concurrency and distributed systems questions; everyone who talked to me was smart. Maybe it depends on the group you're talking to there.
Re: Google (et al), "I’m purposely focusing on companies that got it all wrong."<p>As someone who's hired hundreds of people and worked to build three startups, I am increasingly of the opinion that it's critical to carefully study the hiring practices of companies that appear to employ a consistently high level of talent, like Google. And Google's talent base was one reason I thought the employees of my last startup would be happy there, and argued (to me) in favor of an acquisition by them. (Virtually all of them are still there, too.)<p>That said, entrepreneurs should take with a grain of salt any definitive pronouncements about hiring practices. In my experience, hiring and organizational design are not solved problems yet, by any means.
I'm curious as to how the "real-world" programming task works. I find that most task are either new features, in which case domain knowledge is essential - e.g you need to talk to the users before you can write any code. That doesn't lend it self well to a homework task.<p>The alternative is bug fixes and inceemental tweaks and improvements to existing systems. These are often of a more technical nature, but they are also 90% about understanding existing code, which means that the candidate would need copies of the existing code base. I'm not sure I would be comfortable dishing that out to random strangers, which job candidates essentially are.<p>How do you do this in practise?
Is "I don’t read resumes", "I don’t care about your resume", very common? It seems a bit cold hearted and unfriendly. It says to me "I don't care enough to read a bit about you, and your achievements". But that's just me.
i continue to question the "whiteboard coding" experience.<p>on one hand: a dev cannot put their thoughts about a problem set into code on a white board.<p>on the other hand: a dev answers all problems with code on a white board.<p>i find it hard to believe that taking a dev away from their desk and providing a whiteboard with marker is so different that it would make one become a "bad developer" incapable of solving a problem.<p>i find it easy to believe that the dev has just not practiced coding on a whiteboard. therefore, when asked to do so, cannot bc of to anxiety from not practicing.<p>if one can write english on a whiteboard and not get anxious, then why would a professional developer get anxious about writing c++ or java on a whiteboard?<p>like i said, i go back and forth on this when it comes to interviewing people.
This seems like a reasonably good process. This item under "DONT'S" is a particular annoyance for me:<p>* Don’t ask those who interviewed the candidate before you what they think. Form your own first impression.<p>For some reason, some people feel the need to grab you before stepping into an interview and gush about the candidate "This person is AWESOME! I'm really excited about them!", which, if you aren't cognizant of it, can heavily skew your evaluation of them and basically destroys the point of having multiple people interview a candidate.<p>The lone exception might be if a candidate is so unbelievably bad that you want to save everyone's time by ending the whole thing early, but hopefully your screening process is good enough that it doesn't happen often enough to worry about.
I think most of the things mentioned in the post is a good way to go about interviewing. However, I don't really agree with the "no resume - look at open source" part.<p>I know I am not the target demographic for this company as I am no coder and I don't really have any interest in contributing to open source development, even if I were a coder. Surely there are other/better ways of initially judging potential new recruits?<p>As far as I can tell the author is an open source advocate so I guess I wouldn't fit into the "culture" but ignoring those who aren't as into open source as the author would exclude a number great of people who might contribute greatly to the company (and a missed opportunity to convert them into open source advocates/fans/contributors).
Wow -- this is one of the first write-ups on this dead, beaten horse that makes a considerable amount of sense. I've often done something like this "lite", and had reasonable success.
It sounds like they've found a legal way of getting free work completed.<p>Is there some kind of signing bonus if you make it through the interview process and get an offer? I think there should be.