UPDATE: I wrote some more recent things about Steve’s famous google plus post.
http://steve-yegge.blogspot.com/2008/06/done-and-gets-things-smart.html
I’m a big fan of Steve Yegge and his blog. I was recently rereading some of his posts and the above one had a lot of new meaning for me. At my job, I had recently been involved several interviews of technical candidates, as well as working with a new hire that I didn’t interview before the job. Mistakes have been made, and I’m looking to learn from them.
Judging ability is very difficult in the short course of traditional interviews and resume screening. Particulary tough for me, is that ego is a difficult thing in a programmer for me to see past. Don’t get me wrong, every programmer has an ego. As Yegge points out in his post, if you’re not a smart person, you don’t get in the field in the first place. It requires a very different form of thinking to start with a blank canvas and create an abstraction that you know a compiler can turn into instructions that you know a processor instruction set can execute as a series of binary math and actually do some practical work for someone (an end-user) that doesn’t understand what’s going on under-the-hood. In a nutshell, that’s what a programmer does, so the barrier to entry means you’re looking a pretty specialized subset.
Add to that the fact that people generally buy into confidence. However, confidence shrinks as you become a better programmer. The more patterns, frameworks, and languages you know, the more humbled a programmer (usually) becomes. So now, you have to find the most effective people, who when you ask them won’t tell you they are effective.
And without a doubt, you will be fooled when a senior programmer who hasn’t been humbled walks in. Because you think naturally this person has seen the ways of the world, but if he still thinks he’s smart, he must really be.
Not necessarily so. Some people just can’t figure out they are working in a field of smart people and that they can never assume they are the smartest in the room, regardless of age, experience, appearance, or anything else.
You also can’t judge based on opinions, because they’re moving targets. If someone told me 5-10 years ago that javascript was one of the most important langauges around, I would have thought them crazy. Browser standardization wasn’t there (and still isn’t), it was seen as only viable in the browser, slow, and object-oriented but not really. Now, dynamic languages are all the rage, many have realized and embraced that javascript is more object-oriented than languages like C# and Java (which are really class-oriented), the language has a spec, it is simple the dom model that has compatability issues, and there are really fast vm’s out there that make javascript a powerful multi-platformed language. And by the way, with upcoming changes in emca4, it will be much easier to write good tools and ide plugins. So if someone is singing javascript’s praise in 2002, were they 5 years behind the times or 5 years ahead?
I think there are a couple of ways to solve this. Yegge refers to the 6 month trials at Google. You may or may not keep your job at the end of that, and you can have your position in organization adjusted (up or down) at that date. Setting that precedent is powerful, because many organizations won’t make the proper adjustments on a hire that is a mild mistake. They will only come in an fire or move an employee in the most aggregious of cases. And while it’s a tough adjustment for an employee, the right employees will take that adjustment as an inspiration to get better, and self-evaluate. If they walk, maybe you want them to walk.
The other consideration I’m giving is to assigning a small technical problem to an interviewee. Assign them a very simple program that features 2 technologies. 1 they claim to know, and 1 they don’t. The program should be able to be finished in 60-90 minutes. The purpose is to see if they really know something they claim they do, and if they can effectively pick up a new tool. I think that tool has to be related to something they know, to be fair.
For example, maybe assign a CRUD page with postgres to a php programmer that knows mysql. To keep it short, you’d have to provide the db with sample data. But can they look up the minor nuances in setting up connections and passing queries.
Or, if it’s a windows form programmer that knows unit testing, you have them write a calculator in a wpf form with unit tests. Make sure they really know their testing, and they can look up the basics of a an application that is similar to a framework they know.
You have to be reasonable, you can’t assign a dependency injection app to a programmer who’s never heard of the concept.
Ideas like this won’t stop these problems from happening. I still have to use incomplete information to figure out if someone is any good. And worse, I have to figure out how they compare to me and other developers when my view of our existing staff is probably skewed, and in particular I always question my own self-awareness. But hopefully these ideas help.