Computing Thoughts Hiring the Rowing-Forward 30% by Bruce Eckel April 16, 2008
A business owner at a workshop I held made the very disturbing comment that he thought that 70% of programmers were "rowing backward," doing things that you had to fix in order to keep the boat moving in the forward direction.
This person had created a software tool company of about 25 people that he later sold to a much larger company. Based on his descriptions of his company before it sold, I guess he is referring to his after-sale experience with the much larger company. Or it could just be his experiences with customers using his tools.
His anecdotal "70% Rowing Backwards" sounds roughly right to me, and it bothers me a lot. Studies show that programmers derive their primary satisfaction by being productive, so such an environment sounds downright depressing. But managers obviously don't want this kind of thing to happen either. It's wasteful and costly. Of course, if you believe that you're a productive programmer you may think that you're rowing in the right direction when you're not (actually, I know I've gone in the wrong direction while thinking I've done the right thing, and I think we can discount the small percentage of people who are intentionally causing trouble as being mentally unbalanced). If you're a manager, presumably you are getting information that makes you believe you're making the best decisions given the situation.
And still, we are only fractionally productive compared to what we know we can do. How did we get here? (Jerry Weinberg says: "one logical step at a time.") Why do we stay here? (Because we think we're doing the best we can in the given situation, and change is hard.)
Is there some way we can change things?
Instead of holding a session that discussed the problem, I decided to go out on a limb and hold a session to try to come up with an answer. My fantasy would be to come up with something like Open Spaces, where the solution is so topsy-turvy that you have a hard time believing it works, but when it does work (because it relies on everyone acting in their own self-interest), it works better than anything else you've seen before. And requires minimal leadership and structure.
I believe such an organization can be created, but I haven't imagined it yet. When it became clear that we weren't going to get very far in the session, I suggested that we go around and describe the best job we've ever had. This turned out to provide great insight.
To a person, everyone described the best team they'd ever been on. The actual state of the company was unimportant; it could be falling down around their ears and if the team was great, they were very happy.
Six Hiring Points
Later, at one of the meals (these are not formalized during the JPR, but happen in various and sundry different ways), the discussion turned to the most important factors in hiring. The hiring process in most companies amazes me because it seems to be a short courtship for such an important choice. I suppose this happens because "hire a database programmer" becomes a to-do item that someone would really, really like to cross off. Everything is being held up, and if we could "just" fill that position we can move forward. Thus it becomes a short-term urgency, and the thought of both the short- and long-term damage that the wrong choice can cause is pushed to the background.
Our group came up with six things that you should test for when hiring someone, each of which is critical for the well-rounded programmer that everyone wants to have on their team.
Technical Knowledge. This is the easiest thing to test for, and it's what most companies fall back on. It's ingrained from our own decades of schooling. However, technical knowledge is a relatively small part of the picture, and only for the short term. Even though it's what is typically tested, the remaining points on this list are the truly important ones.
Critical Thinking. This industry is full of new technologies that promise to solve all your problems. Architects like to think they have it all under control, and hand out a system design to be consumed without question. When the programmer encounters a real system, are they capable of expressing doubt and asking the right questions?
Can You Solve Problems? The college teaching system trains people to learn for tests that have one right answer. A system like this often produces people who believe that programming is a bunch of rules that you simply apply. What does the candidate do when they encounter a real problem where the answer is not clear and balancing tradeoffs is necessary?
Can You Learn? A hire that self-teaches is very valuable. This is less about classroom situations than it is about learning from other outside influences. Can you learn on your own, and more importantly, do you want to? What have you learned recently, under your own motivation?
Can You Change Based on Environment and Evidence? Which means: Are you open to a better way of doing things? However, not every single "better" way of doing things that comes along. This requires a balance between the ability to see and adopt a change when that change is truly an improvement, but at the same time having a highly developed sense of skepticism and a good BS detector.
Are You Toxic? The worst person to hire is the one that passes tests 1-5, but turn out to have some kind of quirk or imbalance that causes destructive behavior. There's nothing worse than dropping a toxic person into a team.
When you see these in a list, they may seem fairly obvious. Of course everyone wants to know about these things in an interview. Why doesn't everyone find out about these things? It's because they're harder to test for, sometimes much harder to test for, than technical knowledge alone. Even though you know hiring the wrong person is like accumulating credit-card debt (easy to get into, but costly to carry and hard to get rid of), the temptation is great to just hire the person, check that task off the list, and hope that they will work out. But as I learned from some workshop, "Hope is not a strategy."
Testing for the Six Points
The success of a new employee is going to depend far more on points 2-6 than point one. So to become more successful as an employer, you really do need tests for those points, and you need to apply them on every single candidate, or else you're going to end up with a lot of employees that are rowing in the wrong direction.
Technical Knowledge.Of course you need to know what level of technical knowledge a candidate has; the problem is only testing for technical knowledge. And consider this: someone with a hard technical background, such as physics or chemistry or engineering, may be a much better candidate because they can learn faster and tackle harder problems, even if they have relatively little formal training in programming. So they might not know how to write an insertion sort from memory, but they also might be more valuable than someone who does. Remember that code reviews are an incredibly valuable way to discover problems. So show them some code and have them review it, and see what kinds of problems they can discover and improvements they can make. That's likely to be far more revealing than whether they have something memorized. A good programmer looks things up anyway, so memorization is not a skill you really want to test for.
Critical Thinking. Ask the candidate to compare two technologies that they know about (EJB vs. Hibernate/Spring, for example), or to talk about the applicability of a tool (what aspects of UML are commonly useful, and which are rarely used?). If they know more than one language, ask where one language might be more appropriate than another. Show them a design or an architecture and ask if they see problems and how they might improve it.
Can You Solve Problems? You want to see problem-solving in action, so give them a problem and watch. Two that I like (I think I heard them from the same person) are: "make an object model of a chicken" and "design an online monopoly game." I think it's important that such problems be open-ended, because that adds an extra dimension to the problem-solving experience. Challenges that involve back-of-the-envelope calculations or estimates are good, because software design is an inexact art and if someone cannot move forward unless they have an exact right answer they may not be a match for your team. Another thing to notice is whether they ask questions during the process; this gives an indication of whether they consider software a team sport or if they are a "lone wolf" developer.
Can You Learn? Ask the candidate what kinds of things they have done to enhance (if they were in school) or continue (if they were working) their education. User group meetings are a good indicator, as are conferences, workshops, and seminars. What books have they read? Have they learned new languages or technologies? If these are self-taught this is a very good sign.
Can You Change Based on Environment and Evidence? For a programmer, the most telling fact may be the editor they use. If a programmer is hardwired to only use emacs or vi (for example) and could never consider using anything else, they may also fight any efforts to do unit testing or use version control or your build system. Or to use any other tool that might improve productivity. Ask what kind of editors and development environments they have used; ask them to create something with that tool. If you really want to see them in action, walk them through the development environment that your team is using.
Are You Toxic? Testing for toxicity is the trickiest and most difficult of these tests, primarily because bad behavior doesn't show up until a person perceives that they are in a position of adequate power, which is to say, after they've been hired and very often after they've been working at a place long enough to know what they can get away with. There are three approaches I can see to the problem:
Follow up on references -- former employers tend to be very careful because they fear lawsuits, but if you give the former employers lots of room, they might say things between the lines that allow you to pick up important clues. If there are gaps in employment, find out about those. If an employer won't speak to you at all, that's an important clue.
A simulation of some common activity where the toxic individual is likely to lose themselves and expose a problem. For a programmer, pair programming with someone on the team may show certain kinds of behaviors.
There must be a probationary period where, if the new hire turns out to be toxic they are dismissed. Yes, this is painful because you have to go back through the hiring process (although you may be lucky enough to tap your second or third choices from the original process), but if you don't do it you will either greatly reduce the productivity of your team or destroy it altogether.
The No-Asshole Rule is a book that was highly recommended by a friend, though I have yet to read it myself. It may or may not help here.
How would you test for these points? Are there other points you consider important during an interview?
I found The Five Dysfunctions of a Team to be a very insightful and helpful book for understanding what a team needs to do in order to work well, and the numerous ways that a group can fail to be a team. The dysfunctions and their effects are:
Absence of trust, which causes "invulnerability" in each individual; Fear of conflict, which produces "artificial harmony"; Lack of commitment, creating ambiguity in the team's goals; Avoidance of accountability, leading to low standards; and inattention to overall results, which causes individuals to pursue results for themselves, increasing their status and feeding their ego. The book also had a great definition for "politics": "Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think." Also, there are supplements to the book, including a workbook showing how to administer the team-fixing process.
Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.