Summary: Eric offers guidelines for handling tough hiring decisions in a small ISV.
Several months ago, I wrote an MSDN column entitled Make More Mistakes. This column was one of the most popular things I have ever written. People seemed to really enjoy reading about my screw-ups. As human beings, we are fascinated by the failures of others.
In the many e-mails I received about that column, one of the most common questions was why didn’t I list any hiring mistakes. “Eric, is it possible that you have simply never made a mistake in a hiring decision?”
Au contraire, I’ve made plenty. But those are stories I would rather not tell. It is one thing for me to air my own idiocy in public, but quite another thing for me to recount tales that might hurt someone else.
Nonetheless, hiring decisions are tricky, and I think I’ve learned enough to say a few worthwhile things on this topic.
I’ll start with four general guidelines for how to proceed with a hiring decision.
After that, I’ll finish the article by saying a few things about the specific challenges of hiring software developers.
1. Hire After the Need, Not Before
The first step in hiring is to make sure that you actually need to be hiring. For small independent software vendors (ISVs), my rule is: Don’t fill a position until after the need for that position is painfully clear.
In other contexts, it often makes sense to “staff up” in anticipation of growth. Many venture-capital-funded companies work this way. Your investors didn’t give you millions of dollars because they want their cash sitting in your bank instead of their own. They expect you to grow your company aggressively, and that often means hiring more staff.
But in a small company that is funded by its own revenues, it is almost always a mistake to hire for a position before it is absolutely clear that hiring is the right thing to do.
This is an easy mistake to make. Version 7.0 of your product is going to ship in 8 weeks. You are expecting lots of new orders, so you decide to hire another customer service person to be ready for the deluge of phone calls.
Better idea: Have one of your existing staff take those calls, or take them yourself. Don’t increase your payroll until you are 100% certain that you have a permanent need for one more person than you have now.
Several years ago, I decided to get very aggressive about growing SourceGear “to the next level”. We made several new hires, including a human resource (HR) person. We convinced ourselves that the company was going to be growing so fast that we needed an HR person to help coordinate policies and benefits. We hired a top-notch individual for that job. Let’s call her Wilma.
Wilma was a dear friend of mine and still is. She did a fine job for us here at SourceGear.
But the fact remains that our company was not really big enough to have a real need for a full-time person in HR. We knew this, but we were “staffing up for growth”. And then the dotcom bubble burst, and SourceGear never did get that big.
2. Realize That Hiring Is All About Probabilities
Hiring is all about probabilities. When we evaluate a candidate, we are basically just trying to predict whether that candidate will be a success in the position being filled. We’re trying to know the future, but we have no prophets and no Oracle.
So, we use various indicators that we believe will be correlated with future success. We look at past experience. We look at educational background. We call references.
We interviewed Wilbur at considerable length. We checked his references. There was no question he had the necessary experience to handle the job. The decision seemed clear, so we did the hire.
Shortly after Wilbur started on the job, things turned surreal. Was this the same guy we hired? The chemistry between him and the team was a nightmare. Wilbur is clearly a sharp guy with solid abilities, but this situation simply didn’t work out at all.
On the other side of the coin, sometimes we miss out on a great employee because our indicators steered us away. Most of the time, we never know about these situations. We turn down a candidate, and we don’t hear where that person ends up. Some of them go on to be a big success.
3. Know the Law
In the United States (and probably elsewhere as well), there are laws that you need to know before you even start the process of trying to hire someone. There are federal statutes and there may be state and local regulations as well. I am not an attorney, so I will not even attempt to explain these laws, but it is very important that you understand them.
The various materials from Nolo Press are usually a good starting point for beginning to understand legal matters. Nolo Press has a Web page on employment law that has lots of information. Even still, it is always advisable to consult a local attorney.
One final remark: Even if you discover that you are exempt from the laws due to the small size of your company, it is well worth your time to understand the law and begin making habits out of following them. In most situations, complying with the discrimination laws will actually improve your decision-making anyway.
4. Get a Variety of Opinions
The general principle here is that good decisions happen when you have several different perspectives. If you want to consistently make the worst hiring decisions you can make, just make all the decisions by yourself without listening to anybody else.
But if you want wise decisions, get a variety of opinions and different perspectives. In my own hiring decisions, I make sure at least one of those perspectives comes from a woman in my company.
The simple fact is that the software industry has a lot more men than women. Julia Lerman noticed that the Tech-Ed speakers list had more people named Brian than women. Our field is perhaps 90% male, and that means I have to work a little harder to get balance on this aspect of our hiring decisions.
I’ve observed a pattern over the years, and of the bad hiring decisions we’ve made, many of them happened when the decision was made entirely without a woman’s voice.
Fortunately, my approach has worked well in ways that I could not have anticipated. In 1998, SourceGear was looking to hire a full-time person in technical support. The decision was primarily being driven by myself and one of my co-workers named Mary. We interviewed several candidates. Mary and I disagreed on which candidate should be chosen. I deferred the decision to Mary, confident that I would eventually be proven right. But the person Mary chose turned out to be one of the best employees we’ve ever had.
Hiring Programmers: The Usual Advice
Most of the writings on the subject of hiring programmers tend to sound the same. The usual advice is to “only hire the very best”.
I’ll confess that I’m not terribly fond of this advice. It is simply too vague.
Please understand that I am not advising anyone to deliberately seek out mediocrity. We obviously want to hire the most talented and experienced people we can. In a hiring decision, the stakes are high. Your decision will affect your team, and it will affect the individual. As Joel says, “It is much better to reject a good candidate than to accept a bad candidate. … If you have any doubts whatsoever, No Hire.”
But the usual advice still annoys me. The problem isn’t so much with the advice itself, but with its tendency to be misunderstood. When applied with no additional precision, the primary effect of the usual advice is to create a sense of arrogance. This effect is especially common among programmers, since elitism comes naturally to us anyway. When we hear that we should “only hire the very best”, we internally translate this to mean:
The “very best”? Why, that’s me! I am the “very best”. Obviously, I should only hire people who are as gifted, as smart, and as good-looking as I am. After all, why should I pollute my perfect team with riffraff?
It is not surprising that this attitude provides a poor framework for hiring decisions. The usual advice works much better when it is understood quite differently:
I want to build the most effective team that I can build. When I hire another person for my team, my goal is not merely to make the team larger. Each person I hire should be chosen to make my team better in some specific way. I am not looking for someone as talented as me. Rather, I am looking for someone who is more talented than me, in at least one significant way.
The very worst kind of manager is the one who feels threatened by his team. Consciously or not, he is afraid of those who are “the very best”, so he consistently staffs his team with people who will not challenge him.
I suppose he might be able to get away with this in a big company. After all, I doubt that the Pointy Haired Boss in the Dilbert comic strip was created with no source of inspiration at all.
But things are very different in the world of small software companies. If you are the founder or “chief geek” in your small ISV, take a careful, honest, and objective look at yourself. If you are the type of person who feels threatened by your own staff, stop and rethink. Until you move yourself past this problem, you have exactly zero chance of building an effective team.
The real point of the usual advice is not to inflate our egos–it is to remind us that we should not be afraid to search for the best people.
But we still need a more specific understanding of what the word “best” really means.
Look for Self-Awareness
The “very best” people never stop learning.
When I evaluate a candidate, one of the most important criteria is what I call “the first derivative”. Is this person learning? Is this candidate moving forward, or have they stagnated? (For more of my thoughts on this topic, see the Career Calculus article on my weblog.)
People who are seriously focused on their own future success are very likely to be successful. This is often the strongest predictive indicator in the hiring process.
I’m not saying you should just hire people who want to succeed. Everybody wants to succeed. I’m talking about hiring people who are serious about constant learning. These people don’t spend their time trying to convince you of how much they know. They don’t focus on their past very much. They are always focused on their future. As you interview them, they are interviewing you, trying to figure out how much they can learn from you.
How do you find this kind of person? It turns out that this posture has a precondition that is rather easily observed: People who are committed to constant learning are people who know what they don’t know. They know their own weaknesses, and they’re not insecure in talking about them.
One of the popular interviewing questions is to ask the candidate to describe their biggest weaknesses. Even though this question is terribly “old school”, I really like it.
Unfortunately, most candidates try to duck the question. They go to their local bookstore and they buy a book on interviewing. That book warns them that I am going to ask this question. The book tells them creative ways to avoid giving a genuine answer:
Sometimes I work too hard.
Sometimes other team members get frustrated with my attention to detail.
When I ask candidates to tell me about their weaknesses, I am hoping for a wise, honest, and self-confident answer. When I hear a candidate rationally admit a weakness, I am impressed. When I hear a candidate duck the question with language straight out of a book, I start thinking about the next candidate.
Hire Developers, Not Programmers
For a small ISV, the “very best” programmers are the ones who can do more than just write code. You should hire developers, not programmers.
Although the words “developer” and “programmer” are often used interchangeably, I make a distinction between them. That distinction is the difference between simply coding and being a part of product team.
I wrote an article on this topic on my weblog, from which I quote:
For the purpose of this article, a “programmer” is someone who does nothing but code new features and [if you’re lucky] fix bugs. They don’t write specs. They don’t write automated test cases. They don’t help keep the automated build system up to date. They don’t help customers work out tough problems. They don’t help write documentation. They don’t help with testing. They don’t even read code. All they do is write new code. In a small ISV, you don’t want any of these people in your company.
Instead of “programmers” (people that specialize in writing code), what you need are “developers” (people who will contribute in multiple ways to make the product successful).
What does the usual advice really mean? Exactly what attribute do I measure to determine if the candidate is “the very best”?
Most of the time, the usual advice is understood to apply only to coding skills. It really is true that the best coders are gifted with an aptitude. They understand things that generally cannot be taught. They are perhaps ten times more productive than average coders. It obviously makes good sense to try to find one of these “10X” individuals, especially in larger environments where specialists like pure coders can fit in well.
But in a small ISV, we need versatility. We often need the people on our teams to wear multiple hats, not just write code. In these cases, it is often very important to look for the best developer, and that person is not necessarily the best programmer.
Education Is Good
People with a solid education in the fundamentals often turn out to be the “very best” developers.
The issue of education is quite controversial in the software field. Right now, somewhere on the Internet, there is a discussion board or a chat room where people are arguing about how much education is needed to be a software developer. The arguments go on, all day, all night, 365 days a year, and they never find the answer to the question.
And they never will. Hiring is about probabilities. Educational experience is an indicator that can be used in predicting success, but it is not always accurate.
Two of SourceGear’s best developers have no degree. One of them is an excellent programmer who is gradually becoming an excellent developer. The other is an excellent developer who is gradually becoming an excellent programmer.
On the other hand, when I see a Ph.D. in computer science, I believe the probability goes down.
Universities don’t teach people to be developers anyway. They don’t even teach people to be programmers. Universities teach their students to be computer scientists. Becoming a programmer or even a developer is usually left as an exercise for the student to complete on her own time.
A bachelor’s degree gives you a solid grounding in fundamentals and it proves that you can finish. Those issues are important, but when it comes to the specific set of skills we need in a small ISV, you are approaching the point of diminishing returns on your first day of graduate school.
People tend to get terribly offended by these opinions. Please understand that I do have a lot of respect for people who have finished a Ph.D. It takes a tremendous amount of discipline, intelligence, and desire to finish a doctoral degree. I admire those “Ph.D. Qualities”. I seriously doubt whether I could finish a Ph.D. myself.
But I still believe that those “Ph.D. Qualities” are not the same skills that are needed in a small ISV. Shipping a shrinkwrapped product requires a different kind of discipline, intelligence, and desire. These “Shrinkwrap Qualities” are similar to “Ph.D. Qualities”, and yet are very different.
Furthermore, I believe that very rare is the person who has both Ph.D. Qualities and Shrinkwrap Qualities. Some people have the talents to finish a Ph.D. Some have the talents to finish products. Some people have both, but not very many people. When I see someone who has finished a Ph.D., I know for certain that they have Ph.D. Qualities. I will therefore consider it unlikely that they have Shrinkwrap Qualities as well.
Although I do place a high value on the non-coding aspects of software development, the code is important, too. The “very best” developers still ought to be darn good programmers.
Don’t be afraid to look at the code. When you interview developers, ask for code samples. Ask them to write some code during the interview.
One of my favorite questions is to ask candidates how many lines of code they have written in their entire career. The answers vary widely. Some people don’t even know. Some people tell me it’s a stupid question and spout all the research showing that “line count” isn’t a terribly good measure of programmer productivity. Fine, I’ll stipulate to all that, but I still like the question. I believe that people tend to become better programmers as they write more and more code. I want to know how much code you’ve got behind you.
During college I wrote a C compiler, just for fun. It was written in C, entirely from scratch, with a handwritten recursive descent parser. I even did some peephole optimizations on the back-end. It wasn’t very fast, but it could compile itself with no errors. I released it under the GPL, but I was only the person who ever used it.
When I applied for a developer job at Spyglass, I showed my compiler to the hiring manager. I got the job, and my compiler project was one of the factors in his decision. He said he looked at my code and realized that I had already gotten a lot of the bad code out of my system, so my next hundred thousand lines of code ought to be pretty good. :-)
Twelve years later, I think there is some wisdom in hiring people who have made significant contributions to an open source community project. After all, I don’t have to ask for code samples, I can just grab a tarball and read it myself.
Granted, a lot of these coders are driven purely out of hatred for Microsoft. Regardless of your opinions about Microsoft, that kind of motivation is not likely to be a good foundation for success in any developer job.
But a lot of people work on an open source project simply because they have a passion for coding. It’s their hobby, and as hobbies go, it’s not a bad one. Some folks look at projects like AbiWord or ReactOS and all they see are people who are wasting their time by cloning mature Microsoft products. I’ll concede that these projects don’t make much sense if you’re trying to find a business case for them. But the typical contributor to these projects is coding for fun. Watching TV is a waste of time. Coding is not.
People who genuinely love to write code often turn out to be the “very best” developers.
The Very Best
It turns out that the usual advice works just fine, but we have to move from the vague to the specific. To summarize the various points I made in the sections above, here are ten questions to ask yourself when considering a candidate for a developer position:
Can this candidate bring something to the team that nobody else has?
Is this candidate constantly learning?
Is this candidate aware of his/her weaknesses and comfortable discussing them?
Is this candidate versatile and willing to do “whatever it takes” to help make the product successful?
Is this candidate one of those “10X coders”?
Does this candidate have a bachelor’s degree from a good computer science department?
If this candidate has a Ph.D., is there other evidence to suggest that s/he is one of those rare people who also has “Shrinkwrap Qualities”?
Does this candidate have experience on a team building shrinkwrap software?
Does this candidate write good code?
Does this candidate love programming so much that s/he writes code in their spare time?
It’s not necessary to answer “yes” to all ten of these questions. I’m not even going to specify a minimum number of “yes” answers needed for a positive hiring decision. Hiring is all about probabilities, and each of these questions can serve as an indicator to help you predict whether the candidate will be a success for you.
In the end, every hiring decision will be made with your own judgment, and there are no guarantees. However, giving consideration to these issues can help raise the probability of making a hiring decision that you will not later regret.
Eric Sink is the non-legendary founder of SourceGear, a developer tools ISV located in Illinois. Recently, Eric was delighted to hear that his Make More Mistakes column was used by someone on the Microsoft.com Web team as an example of a really bad title. The title for this month’s piece was chosen specifically in the hope that he might earn this dubious distinction once again. 🙂 If you appreciate this kind of warped sense of humor, check out Eric’s weblog at http://software.ericsink.com/.
This article originally appeared on the MSDN website.