On TechCrunch, Jon Evans published "Why The New Guy Can't Code," a post saying to hire only people who've shown that they've accomplished something instead of people who can jump through interview hoops.

The situation looks like this: some schnook is interviewed, and is able to answer the brain teaser questions (example is from MS: "why are manhole covers round?", etc.) The idea is to see if the person can think on his feet in the interview.

The problem is that people have managed to develop good interviewing skills but not good coding skills to go with them, so these hires end up being worthless.

Mr. Evans says to require hires to have done something in the real world, suggesting that anyone with any real ability is going to have published something on AWS or GAE or maybe in Android market.

It's an interesting thought. Some of his points are ridiculous - he says that the guy who invented Hungarian Notation was an unworthy person who rode Bill Gates' coattails, apparently unaware that Charles Simonyi is very well respected - maybe more than Gates is - and that Hungarian Notation's bad reputation is more at the feet of morons like Herbert Schildt who use it badly in books than Simonyi himself.

But the thought of hiring only the experienced is a chicken-and-egg problem. People have to start somewhere; a student's project isn't likely to have real-world implications (and therefore, "having done something" wouldn't mean much) unless they're Facebook.

Plus, you don't need brilliant people sometimes - sometimes you just need competent coders, and sometimes competent coders have real lives and donb't live to be virgins. So they wouldn't spend their offtime writing yet another fart app just to get a coding position, and maybe just knowing some basic analytical skills and how to read the compiler error messages from Eclipse are enough.

So how would you approach hiring to make the process work?

The idea that you can determine someone's ability to think in an artificial situation like an interview is ridiculous.  You'll have better luck if you disabuse yourself of that notion.

Another problem is asking silly questions like why manhole covers are round.  There are lots more puzzler questions that are more sophisticated than this, but puzzles are worthless and annoying in interviews.

See what they know about architecture and application of design patterns.

Have them write some meaningful code during an interview.  I was a contractor for 13 years and interviewed many times.  Only once did a potential client sit me in front of a computer and have me write some code.

 

A lot of people can talk the talk. But. I like your posting. Walk the walk.

 

 

J

Geez, how hard can it be?  Yes, you /can/ get a glimpse of how their minds work if you just engage them in conversation.  Steer the conversation (and if you can't, and it doesn't go where you want it to, maybe that indicates a problem (not necessarily with the new hire)).  Don't ask them stupid brain teasers, don't put them on the spot.  Sure, ask them to write some code, but then engage them to see what they were thinking.  I don't think you build a team with just good coders.  You build a team with good communicators.  Those two things might be coincident, but a star coder who produces impenetrable code is not what you want.  A person who can usefully, effectively share knowledge w/the rest of the team (both giving and receiving) is better.

Or not, I dunno.

IMO, its pretty easy to build a resume nowadays.  Just contribute something meaningful to an open source project.

Couldn't agree more.  There are plenty of open source projects that need a few days or a week of intensive developer attention.  Find one you like that is bite-sized enough and has a developer or two on it and crank on it for a while.  Then watch the magic.  

I'd just like to point out  that there is a difference between being a good coder and being a good worker.  As it was stated anyone can come out of college and code, and just as the post implies anyone can create a web page.  But that doesn't determine how a person works, lazy is lazy no matter what discipline we are talking about.  Maybe it's not them, maybe it's a lifetime of working in poor companies with poor motivation that has brought them to this point, but a good worker can be developed.  It's part of the reason for managers isn't it?  Whether or not your company is prepared to take this on is on a case-by-case basis, startups are not likely to have resources to give more time to develop new developers.

The punchline of all this is that you can't test for good workers.  There is no dept. I know of that has ever gotten it right.  It doesn't matter how many brain teasers you throw at someone, or how many lines of code you have them write, a worker is an individual trait, like a sense of humor, and despite us all wishing we had a magic solution to find them, the truth is you no one does, and it's up to the managers to deal with that appropriatly.

...guys that post useless articles or post useless articles on useless talks in any industry relevant forum - talks that try to tell us things that we all know, more or less, or try to postulate ones subjective (but probably completely silly) opinion as the way to go. And I would recommend to keep fingers of the "know it all" guys that polute our world with useless stuff...instead of writing good code. Damn - I answered to one of this useless threads I was complaining about, meaning I would not hiring me, becuase waisting peoples time ;-)

Just based on my own experience, to echo John's point, coding is part of the criteria - but not the only one.  I have been directly witness to more than one hiring decision that was based purely on someone's ability to churn out code - only to find out later that the individual would not or could not take direction, would not take the necessary steps to understand a business problem before attempting to code to it, would not validate assumptions, etc, etc.  I would take a solid communicator with so-so coding skills over a top coder whose code I had to throw away, any day of the week.

Be careful, for example as a contractor in major projects.

Thats my expirience as a contractor in very large projects with a lot of people in the last 15 years. You dont have to be a good coder, a little bit perhaps, but its essential to be a good politican!

Many times I was witness of decisions against good coders and pro good talkers. The good coders checked out of the project and the talkers went from meeting to meeting, from supervisor to supervisor, even in their leisure time in the evening, and still are sitting in their positions over years - talking! And this was what they often wanted to have - making money hourly!

So, if its a "time and material" project - talker

If its a service contract- good coder ( faster perhaps )

So, to come off best, you need deeply information what kind of project the interview is for, but this is difficult to obtain.

Such things drive me crazy !