I've been doing a lot of thinking about hiring lately as we've been interviewing new developers and designers at Do. Here Micah gives a new take on how to find "awesome" talent. I can't imagine having to tell a new hire, "Sorry, you haven't done anything awesome this month. Later." At the same time, for a team thats as small as ours (14), this kind of hiring tactic might be exactly what we need to ensure a highly motivated and actively contributing member of the team — especially now that we've adopted the Valve philosophy. (http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf)
This is relatively similar to #5 in Jeff Atwood's rules for hiring a programmer (http://www.codinghorror.com/blog/2012/03/how-to-hire-a-programmer.html).
I prefer the way Atwood describes it: "Give [the new hire] an audition project". If you succeed at your audition project, you join the team. If you don't, you get paid for your work and move on.
There's a problem with Micah's "You have thirty days to do something awesome", which is: how does the new hire know what you, the big boss, will think is awesome? I'd much prefer to take on a trial project with clearly-defined terms of success than to be told, "You need to impress this person you barely know".
Knowing what to build is part of the test though.
Any competent B player can do something that's assigned to them, with clearly-defined terms. However, it's an A player that's a self-starter, entrepreneurial, and knows the space well enough to come in, evaluate the product, and say, "Ah-ha! THIS will be an awesome addition!" — and then actually build it.