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.
Software 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’ (en.wikipedia.org/wiki/Engineering), 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.
