Hiring Java Programmers
#
This is an interesting article. Holub argues that "smarts" beats tool experience (or rather, "skill lists") favored by HR departments:
It doesn't matter if a candidate has written a kazillion EJBs, if they were all garbage. I'd much rather hire a smart programmer who knows both the core language and object-oriented design principles inside and out, but who has never written an EJB, than a marginal programmer who has written 200 of the things badly. More important, I want someone smart enough to recognize that I shouldn't be using EJBs at all if they're not appropriate, someone who can quickly pick up the technology necessary to implement an evolving system.
From what I've learned in my career, I argue that there is no substitute for experience gained through real-world use of a language. The skilled programmer knows the language inside and out. For a team like ours that depends heavily on another product (in our case, DB2 and IBM Content Manager) it's also important to have someone who knows these tools like the back of their hand.
I think my criteria are quite like Holub's, just stated a little differently. He calls these programmers "smart". I think that's just part of it. You have to be both smart and knowledgeable.
I don't really buy that fresh graduate mantra that "I can learn anything."
Or rather, I do. It'll just take you five or ten years, like everyone else.
P.S.: The "widowmaker" strikes again. We've been giving a programming test to people applying for a senior software engineering position. It's amazing how poorly some people who have great resumes do on this test. So I think that a quick programming test, as Joel Spolsky recomments, is a really good way to select skilled programmers.