Hazards of Hiring
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
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
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
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
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.
But there are no certainties. Sometimes all our indicators are
positive, but the employee just doesn't work out. Last year I helped a
charitable organization hire a new staff member. We found a candidate
with an incredibly solid résumé. Let's call him Wilbur.
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
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
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
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.
Nonetheless, I still sort résumés by educational level. These two
developers are exceptions from the norm. The bulk of my experience has
taught me that a college degree is a useful predictor of future
success. When I hire developers, I want to see a bachelor's degree from
a highly regarded computer science department. Yes, yes, I have two
obvious counterexamples right here among my co-workers. But hiring is
about probabilities. When I see a BS from someplace like University of
Illinois or Stanford, I believe the probability of ending up with a
successful employee in the future is higher.
But Too Much Education Is a Yellow Light
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
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
Obviously, I may be wrong, but hiring is all about probabilities. We
use guidelines to predict the future success of a candidate, but those
guidelines are not always correct. There are exceptions to every rule,
and playing the odds will cause me to miss out on those exceptions.
That's unfortunate, because a Ph.D. with Shrinkwrap Qualities would be
an incredible person. Suppose, for example, that I received a résumé
from somebody with a Ph.D. in computer science and with several years
of experience as a developer on the Adobe Photoshop team. Obviously, I
would want to interview this person. I don't think there is a
shrinkwrap product I admire more than Photoshop. Ph.D. or not, this
person clearly has Shrinkwrap Qualities. The Ph.D. is not inherently
negative. It is merely a predictive indicator, and sometimes it's wrong.
Look At the Code
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
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.
But the availability of code for review is one just minor reason why
I like to see open source experience on a résumé. Working on this kind
of project also says something about the person.
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
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?
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.