The Best Way to Hire Software Developers

There are two major mistakes that managers make in hiring software developers. First, they assume that software development is an engineering discipline, and thus they look for engineers. We’ll debunk this notion. Second, they assume that the current skills a candidate has are important. We’ll also demonstrate that this is a sure way to hire the wrong people.

thank you languagesSoftware Development Is Not Engineering

When the first programmers punched tape (and later cards) to feed instructions into a computer, it was a very hands-on exercise. These short programs didn’t require extensive design or development. By the mid-1960s, software development had reached the state where management realized that a methodology to manage the software was required.

In his book The Design of Design, Dr. Fredrick Brooks provides the necessary references to show that Winston Royce proposed his rational or waterfall methodology as a straw-man and then argued against it. We were never supposed to actually use it – just criticize it. It was known that software development needed a methodology, but no one knew what it was, so “rational,” which is based on well-known engineering principles, was proposed as a placeholder. This is how the oxymoron “software engineer” came about.

Unfortunately this engineering methodology has been embraced for years by academia, businesses and government as the pre-eminent way to run projects. It has led to many, many project failures and wasted billions of dollars.

A while back, blogger Ben J. Christensen wrote:

I have long considered it a fallacy to call software development ‘engineering’. Even though the term technically works for software as ‘the science, discipline, art and profession of acquiring and applying technical, scientific and mathematical knowledge to design and implement structures, machines, devices, systems, and processes that safely realize a desired objective or inventions’ (, this is not how the term ends up being interpreted and therefore misrepresents how software development actually occurs – since engineering has become synonymous with building physical structures such as buildings, bridges, roads.

The issue is that the rational methodology is designed for building bridges, etc., which are 20 percent design and 80 percent construction, whereas software development is 95 percent design and 5 percent construction, i.e., the daily or weekly build procedure. Just as we would not use the term “art engineers,” or “music engineers” to describe artists and composers, we should not use the term “software engineer” to describe software developers, which is the same type of discipline.

When I first joined IBM in 1966, I was surprised that math majors and language majors — and not engineering majors — were being hired as developers. It wasn’t until many years later that I realized that Big Blue had it right. Software developers are not engineers.

Take-Home #1

As a manager, or any person conducting an interview, your take-home is that during the hiring process for software developers, you should be thinking “design,” not “engineering.” Look for the candidates that demonstrate a good history of design and interest in art, music and other similar disciplines, not just technical topics.

Hire for Talent, Not Skills

There is a huge difference between “talents and skills.”  Like riding a bike, a skill is something that almost anyone can learn. A talent is something that a person does naturally, although we may spend years honing it. A person talented in software development can learn a new skill, e.g., a new programming language, in a matter of a few days. This is because they have a natural ability to think in design terms and they can easily use whatever tools are available. Just as Tiger Woods can easily embrace a new type of club or an unfamiliar course, a good software designer can easily embrace a new tool.

Many companies recruit by listing a set of skills that a candidate needs. These are irreverent. On a daily basis this leads to hiring people who know a tool, e.g., Java, but are quickly surpassed by a talented developer, who didn’t know the tool, when the next week the company needs people to develop in Python. Managers should hire for talent, not for skills.

How does a manager know whether a person has the required talents? Asking them to solve problems or having them list their skills will not get you the right employee. So what will?

The first is just to talk to the person. Listen to what they say about themselves, what they do, what they have done and what they like. A good manager will quickly be able to determine whether this person has the right talents for the job, or that they don’t. Notice that the term “a good manager.”  A “good manger,” just like a “good developer,” is a matter of natural talents, gifts and abilities. After talking with a candidate for 10 or 15 minutes, someone with good talent as a manager will recognize whether the candidate has the right talents for the job and if they are the right fit for the organization.

During my career I’ve had the opportunity to start many new projects. Although I had never seen it written down in black and white, I just possessed the talent to build great organizations. Looking back, I realize that as a talented manager I was hiring talented employees. It just came naturally.

Take-Home #2

During the interview process the person doing the interview should “talk” to the candidate. Ask them about what they like, what they have done, what things excite them, etc. However, be sure that the people undertaking the interviews are in fact talented interviewers. They’ll recognize quickly if this is the “right” person or not.

44 Responses to “The Best Way to Hire Software Developers”

  1. R. Emmett O'Ryan

    This is great advice to Software Development managers. As a manager, I always hire for talent and based on where developers passions and interests lie. As for skills, if they do not have the skills today, these are things that can be easily learned. And this is why ALL my software development teams have been SUCCESSFUL at what they do – create innovative solutions and software.

    As for other companies, when I am in a hiring mode, as a software development manager I greedily hope that they do not take this approach. I am in direct competition for the same talent pool. Let the other guys use approaches like those at Google and other places where they emphasize skills over talent. I’ll always go for the talent and the potential for what these employees will do for my organization in the future.

    Now if only I can get my HR and recruiters on board with this way of thinking. This would certainly save me a lot of time.

    • John Teuber

      I wish that more hiring managers thought this way. I’ve always been talented (in my opinion) of working through tasks in my head but I’ve never had the time to develop significant skills in a particular language even though, so far, I’ve been quick at picking things up. It’s really hard to even find an internship as a non-CS but still engineering student unless you have significant amounts of programming experience.

  2. Kimberly Byrne

    I like the more general concept of “talent v. skills”. It is comparable to the concept that I use, which is “architects v. engineers”. Architects are able to look at what the needs are, what the resources may be, and what the general design could be and develop a concept. Engineers take the concept requirements and build the solution.

    As always the dreamer often bumps his/her head with reality. There are often more concrete considerations which managers and recruiters don’t have the choice for more open standards, outside of what the organization has already decided. The choice is, therefore, a matter of standards.

    When selecting higher level or more strategic roles, however, this is where these concepts of talent v. skills or architects v. engineers comes more into play. Or, if an enterprise seeks talent that will grow with the many changes ahead, being able to identify those who are able to consider multiple opportunities are the valuable jewels.

    Remember the old saying, it’s easy to come up with ideas; it’s more difficult to follow through to successful implementation. Find the talent who is also able to use the skills.

    • “Remember the old saying, it’s easy to come up with ideas; it’s more difficult to follow through to successful implementation. Find the talent who is also able to use the skills.”

      I’m glad you added this to the end. I know a bunch of talented people who either have no skills or are so focused in design that they forget that they are hired to actually build things, since this industry is typically “Software Analyst/Engineer”. I think it’s time for these roles to be separated, but we’re not quite there yet in the mind of businesses.

  3. Ken Rahmes

    Wouldn’t it be nice if “managers” actually understood this?

    No doubt, one in ten does. Trouble is: The typical “manager” didn’t go to “software recruiting school.” Hence, the problem persists.

    Just getting yourself in front of the manager these days is virtually impossible as you first have to get past the candidate filtering software, then past the well-meaning HR recruiter who has never worked in software.

    • R. Emmett O'Ryan

      I can’t speak for other software development managers out there but as for the HR recruiter, I would recommend that you find some way to by-pass these people and go directly to the hiring manager. My last two hires did not come through HR recruiters but through personal networking.

      Most of the time, what HR recruiters filter for me does not provide me many candidates to look at and this is always disappointing. I know that this is a problem that I really do not know how to fix this other than to bypass them. The HR recruiter does not work for me but is a company “asset.”

      So my advice, build a network of professionals and use your network. Use your network to find out who the hiring manager is for a position you are interested in and then contact them directly.

      As a software development manager who does hiring, I respond to direct communications from developers. I do NOT respond to head hunters or job shop folks.

        • Bubba Jones

          He says: … software development is 95 percent design and 5 percent construction …

          WHERE is he getting these odd facts and suggestions from? There are major universities that offer degrees in software engineering the same as they do for mechanical engineering.

          So, the author is naively mistaken. He is perhaps, correct, that you can hire a “creative type” to design simple systems and nice interfaces, but for anything of major complexity, hire someone with a computer science / software engineering degree. That’s what they went to school to learn.

          I think I do agree with where the author may be going: don’t hire a software engineer/developer on their presentation/interviewing skills… true engineers are generally not sales types… totally different personality types.

    • To me first it is unfortunate that an author does not explain how he detects the talent from the experience. I see he mentioned this:
      “Asking them to solve problems or having them list their skills will not get you the right employee. So what will?”

      And as a response to that he gives this statement:
      “After talking with a candidate for 10 or 15 minutes, someone with good talent as a manager will recognize whether the candidate has the right talents for the job and if they are the right fit for the organization.”

      And also a short description that he wrote of a discussion that he has with candidates to me do not look like an effective way of detecting a talent, but rather an experience and it will show you candidates current skill set.

      Nevertheless I do agree with HR related problems, that is why we don’t use them for candidates filtering, but rather an online services that are specialised in this area, like this one:

      Also I agree with Bubba and would like to add that it seems to me that an author is purely focused on creativity. Don’t get me wrong, I find creativity to be a very useful skill, but I believe that programmers are primarily a problem solvers and an architects and to me these two skills combine make a software developer.

      PS to TPL regarding his capability to learn a language in few days, what are you actually applying by this? From your responses all I can see is you are mentioning learning a syntax difference in few days. If that is your definition of knowing a certain programming language then I feel sorry for you… if I had time I would gladly wrote you a whole essay why you are so terribly misguided. But I have a feeling you are stubborn so I want even try.

  4. If you can get to the actual hiring manager, many of them do understand this. The problem seems to be the recruiters that are hired to filter out by ‘skills’, which a monkey can do. All they can do is fit square pegs into square holes.

    • I think you’ve accurately described the skill set of most recruiters. Expecting people off the street to be able to hire software developers is insane.

  5. Thank you! As a developer, I try to tell people that I can learn languages in a few days, but its like
    taking a horse to water, but you cannot make him drink. I think the concept of hiring for skills is gradually dropping the available manpower that knows a software language. Eventually, salaries for developers will skyrocket. I am just biding my time…….. Another problem with managers in the software industry is they don’t realize that generally, their employees are a lot smarter than they are.

    • Bubba Jones

      To TPL: What on Earth do you mean by that second sentence? Are you saying that all developers lie and say that they can learn a new language in a few days? Nobody can do that.

        • How long do you think it takes someone to learn .NET? Most employers say it takes at least three years until you are more than a junior .NET developer. What language takes two days to learn?

      • Sorry Bubba. I can learn a new language in a week unless it is completely off the wall. Any developer worth his salt can do this. In two weeks a new language will be second nature.

      • Once you know one computer language, it’s generally easy to learn the next one in syntax. For example, VB uses Sub with End Sub while Java uses void with { }

        Where it becomes more difficult is learning the libraries used by the language to make the job easier, then learning the subtleties of the tools that allow you to do your job more quickly. The language itself probably consists of less than 50 “words” and they are very similar between languages (IF, FOR, assignments).

        This is the equivalent of learning Italian then trying to learn Spanish…not a huge challenge if you’re fluent in Italian…until you hit various dialect like Mexican Spanish where you suddenly feel like you’ve never learned the language at all.

        • This is hilarious — you are explaining it to me as if I’ve never programmed, when it was actually I who brought up the fact that you can’t learn a new language in two days (ie, you can’t convince me). You sounded so confident until you said the following:

          This is the equivalent of learning Italian then trying to learn Spanish…not a huge challenge if you’re fluent in Italian…until you hit various dialect like Mexican Spanish where you suddenly feel like you’ve never learned the language at all.

          • I guess my point didn’t come across right…it was that anyone can learn a computer language in 2 days, but to learn it RIGHT requires time.

  6. I agree with this article entirely. Software tools to software developers are a medium for designing and constructing software. A particular tool is just one implementation of a concept. If someone has mastered it, they can recognize the same concept in another implementation easily and start using it quickly. Further, learning a new concept is often not that much more difficult for a talented developer. The ability to understand complex problems and design a quality application to solve them, regardless of the tools involved, is where the focus of hiring managers should be.

    Personally I think companies would do well to limit the role of HR departments to basic screening (factors other than Tech buzzwords), e.g. verifying educational and employment backgrounds; limit the interview process to whether a candidate is ‘in the ballpark’; then offer a temp to perm approach for 3-6 months. If you commit to someone based on a good interview, all you really know is they are good at interviews. You need to see what they are like on the job after having the chance to ‘come up to speed’ a little to know whether they will actually contribute to your organization.

  7. Bubba Jones

    And by the way, the talent developers/engineeers/whatever dont care as much about money as you think but better working conditions… I see such stupidity in general in corporate America, concerning the people they are paying so much money to work.

    #1 — cram all the developers into one room (or around one table!!) or expect them to write code 8 hours a day all day every day, especially when it’s louder than a library in the environment.
    #2 — give them lame monitors and slow computers so that they spend $20/hour scrolling and waiting
    #3 — either of the two and I wont interview with the company at all…

  8. Dinesh

    I agree with hire for talent not skills argument, writing software as a largely-design (even implementation is design largely which is why those who are bad at design suck at implementation as well) process as opposed to building a bridge which largely involves putting blocks together almost mechanically. At the same time I find his plain generalization that software development is NOT engineering a bit of BS, no offence intended. I strongly disagree with his characterization of engineering as a very mechanical enterprise not requiring the kind of mental faculties programming does. He tends to forget that a good chunk of engineers do a lot of programming as part of their jobs. Another interesting thing he mentions is the connection between software and art. I have always realized this and stated as well that most good programmers – are artsy in some sense which is not surprising since art and software both have abstractness as a key feature & are also a bit unconventional culturally. Also, as we move from User interface development to compilers, drivers, platforms, hardware interfacing software, embedded systems the engineering component increases and the artsy component decreases. I remember reading a while ago about the design distinction between Python and Perl reflecting the background of their designers, Perl by a linguist and Python by a Mathematician, hence one is more exact and precise in expression vs another which is more flexible and abstract with expression. This is an example of good software having a heavy artsy or a heavy engineering flavor to it. Software development is a truly inter-disciplinary field. Nice article to talk over coffee with a fellow programmer or an engineer ;-).

    • Dinesh

      I just realized this webpage allows for formatting your comment in paragraphs, apologies for the large block of text. Some comment boards seem incapable of this little nicety, so got used to ignoring it.

  9. Thank you, thank you! I design custom software AND I am a fiction writer. But I almost never tell prospective clients that I write. It would burst the “geek” bubble for them. Truth is, the creativity involved in BOTH endeavors is not that different. And, I love langage, natural or man-made. I always tell people that when hiring a full-timer, look at what they CAN learn, not what they know. Ask them what was the last totally new thing they learned (whether in tech or elsewhere) and if they like learning new things. I am continually impressed by how much creative thinking is necessary to design software that real people use all day every day and actually like using. If my clients don’t love my software, I am doing something wrong.

    • R. Emmett O'Ryan

      So there are a few of us who do software and write fiction. That is good to know. No, I also do not share such information with my colleagues, customers, and management – about the fiction writing that is. Its not that I want to burst the “geek” bubble – frankly I do not think that is possible – but it allows me to quietly observe and leverage experiences within a novel, teleplay concept, and/or screenplay. I write from what I have experienced and know. It has served me well as a second career… or at least helps contribute to my retirement fund.

      The very best and most amazing stories/concepts I have written have come from what real people do. The actions and words of people are quite often stranger than fiction. Everything else is just a mystery… 😉

      As for this article, I cannot stress more that as hiring manager of Big Data software developers, I look for those individuals who can show talent – talent to think creatively. Everything else are skills which can be learned.

      I think that is also why I disagree with many when they say that it is “hard to find folks who can work in Big Data.” Yes, ready made folks with experience are hard to find, but I look for potential (in software developers) and help create what I need.

  10. What you’re saying is half true, and hiring managers do focus too much on skillset and not enough on talent.

    However, in the short term, skillset does matter. If you’re hiring for a 3-6 month contract, you have to hire based on skillset because it takes longer than that to learn the language, framework, common API’s, and best practices no matter how talented you are.

    For a long term job, however, a talent-based focus is best. But if the hiring manager doesn’t know how to identify talent, then they have to resort to skillset, anyway.

    In any case, no matter what we say in blog posts or forums, 99% of the jobs here on Dice are going to care a lot more about skillset than talent; just read the job post descriptions. I dare you to take 100 random job postings and find a single one that that doesn’t ask for “5+ years of experience in Language X, Framework Y, Technology Z” as opposed to “An ingrained talent for software design”.

  11. Wow, reminds me of my American 9 year old white niece who was born in Zimbawe. She often tells Americans she is African American. The seething looks she receives. Where we could be with our preconceived notions attached to title. This article is bloddy brilliant and long over due. On my site Weblance, I am constantly chasing down developers who sign up to design or vice versa. The confusion is so broad it boggles the mind. Back in the day when I started out as a technical recruiter I used to marvel at the HR team rolling their eyes and saying “engineers”. I would thing to my self how ignorant that were. They are developers miss little cost center. As a former recruiter, yes bypass recruiters . 99% are useless.

  12. I think you’re a bit harsh on the term “Software Engineer”, but you have some good points, I thin the term “Software Architect” is more accurate. The Architect is part engineer, part artist. That having been said, your key point is well taken.

    At our company, our criteria (in order of importance) is Personality, Capability, Skill Set.

  13. Two Cents Worth

    Disagree with half of this article.

    Engineering is about the necessary processes that should be in place to make a project succeed. It’s an extremely rare occasion that somebody studying music gets what is needed to make a large scale software project succeed with hundreds of developers. I’ll take a good engineer over a lit student every day on this one.

    Second, I agree with the major problem that both managers and software ‘filter’ candidates solely based on ‘x years using language y’. That is the absolute worse way to hire, but it is exactly how it is done. I can’t count the people hired at my company I have had to let go or have their work thrown out that had ‘x years of language y’ but never had the real talent or KNOWLEDGE of what is really happening. Give me a grounded CS student over an SE any day on this one.

  14. I would look at them more like Skills after Talent (on a priority list) not as “Talent vs Skills”. Talent is very very important on the long term, just as suggested in the article. We cannot keep hiring for every skill But business success is also making sure the developer brings enough skill with the tools to quickly utilize them and keep the business ahead/successful. So skills are lower on the priority list, but also an important criteria in today’s business which travels at 1200 miles/hr

  15. It took so many years for an excellent manager to come to the fore with this article “The Effective Way to Hire Software Developers” by Mr. Dale Reynolds. Try telling this truth to HR and recruiters, it’s like talking to the wall of foolish ways and waste of resource time and efforts. Big companies seeking software solutions to business problem attracts persons with a lot of academic credentials in computer science and rejects the little guy who works for years in his attic, on his own, from back in the days, who knows how to solve the problem in one sentence. IBM and Intel knows this fact, but say nothing or do nothing. A recruiter or HR personnel must not allow lawyers to manipulate HR in large organizations because their consulting practice dictate mis-prioritizing and budget overruns on development of deliverable. So sad, so sad, the effects of arrogance by ignorance.

  16. Bob Ashforth

    Couldn’t agree more. I’ve observed for years the strong correlation between musical background and software development excellence. Not all musicians are great developers and not all great developers are musicians, but the savvy blending of left- and right-brained skillsets clearly pays great dividends.
    On another note, sometimes typos are extremely enjoyable, moreso than the words that were meant: I’m sure that Dale meant to write “These are irrelevant…” but “These are irreverent” is just SO much funnier. 🙂
    Thanks for the post, Dale.

  17. Mattv

    I have to disagree with this article. Sounds like it was wrtten by a recruiter, not real world experience.

    I run a software company and candidates with CS degrees outperform non-CS employees by a signficant amount. Maybe not so much on simpler projects, but on complex, large scale projects there is just no comparison. There are many other attributes that contributre to developer sucesss, but a CS degree is the single best benchmark.

    As far as learning a language in week, a good software developer should be able to learn the syntax. But, a language shift usually involves a whole host supporting tecnologies and frameworks that also have to be learned before you can do anything useful. Knowing the ins and outs of these frameworks to the point where you can make authoritative design decisions takes years.

    • Jim S

      Spot on in your third paragraph. It’s not necessarily the language itself as it is the environment that accompanies the language which takes significant experience to master.

  18. When hiring, I always look for character. If someone has the initiative to work, then they will get the job done, no matter what the language, database type, whatever. People with a genuine interest in computers know not only _how_ to do something, but also, more importantly, _what_ to do in the first place. Then their initiative will take care of the rest.

    I have to agree that, as a general computer guy (programming, systems admin, etc.) looking for a job, people are always hiring based upon keywords, skills, etc.. I usually skip all jobs posted by recruiters, since they are just another hoop to jump through, although I will respond if they contact me. I will say that I do appreciate the above advice about skipping HR and going directly to the hiring manager. This is not the first time I’ve heard that advice, and while it would have seemed “improper” in former times, these days it seems to show interest and initiative. And maybe the hiring manager will be one of those rare birds who, like the author of this article, recognizes a good computer guy when he sees one.

  19. The thing about HR is that they could not care less about hiring the best person. They just want their butts covered in case the wrong person gets hired. If a hire goes bad, they want to be able to say “but his credentials were rock solid”. If you say you’re hiring a math major who learned programming on the job and doesn’t have experience with the language you’re using, that sets off little alarm bells in any HR manager.

  20. Philip Flesher

    Your talent vs. skills distinction is absolutely correct.

    I’m not sure that I agree on the importance of calling someone a “developer” vs. an “engineer” – I get and agree with your point but don’t think the word itself is important. Fundamentally, you’re correct in that software is mostly designing, not building.

    I wrote a somewhat related post recently on my own blog, which is more geared towards how to find and attract senior engineers: [link deleted]