In the old days…
I remember the time when software engineers, to be taken seriously, had to know C, and later C++. A good dose of Assembly was a plus, and a must in some cases. Some niche segments, like banking, standardized on technologies such as Cobol and Fortran. Borland was able to extend the life of Pascal with their groundbreaking Turbo Pascal and Delphi products. In 1991 Microsoft came up with Visual Basic, but it was more of a toy than a development tool for real products. A few years later, in 1995, Sun Microsystems released Java, but for a long while, it was an interesting concept more than a real production language.
In those days, interviews for software engineering jobs were very low-level and CS heavy. Technical questions often involved pointers, memory management, buffer overflow problems and bit twiddling puzzles. There weren’t many frameworks at that point, and web development and scripting were not considered serious programming.
Cranky was ok
At the time, the image of a developer was pretty clear: smart, cranky, introverted, opinionated, lover of darkness and junk food, no particularly clean, with no life nor an expectation that playing well with others was important. (Oddly enough Steve Jobs was not a software developer.)
Agile methodologies were unheard-of, and engineering schools taught the basic waterfall approach to software development: gather requirements, design the solution in great details, implement the design, verify the implementation, release the product, and support it. Projects were always late and over budget.
Formal software QA and bug tracking were relatively new. Software was regularly shipped without rigorous testing performed by dedicated engineers.
Writing code was an arcane practice, the people involved were hard to deal with, the development processes were inefficient and quality wasn’t considered a real discipline. Developers did what they wanted in the time they needed, holding businesses hostage to their artist approach. Discipline in development was weak, coders were difficult to hold accountable for their performance and were inflexible in their approach. “It’s done when it’s done” was the standard answer to questions about an ETA.
In that environment, the tech industry created a job interview practice that resembled how it developed software: rough, unfriendly, unforgiving and abusive. Developers that were wickedly smart, rough, unfriendly and unforgiving did well. More delicate people struggled to get in the industry. Hiring “smart assholes” was normal and expected. Women had a very hard time finding their space in this geeky-testosterone loaded environment.
Today, cranky is not acceptable
Today things are different. Numerous technologies and languages were developed over the years, and software engineering branched into countless paths, each with a different flavor. Each flavor attracted different types of people, and those created different communities and ecosystems.
Fast forward to the present day. Colleges fail to educate CS students on how computers work at a low-level, and many programmers think that “zero and ones” are a thing of the past. Like if computers, somehow, stopped using machine language and binary storage of information. Much of computer science education is very high level, with Java being as low-level as you can hope to get. It is common for new engineers to make fun of C as an ancient technology, even if most of the software they write is based on operating systems and technologies built in C. (I often wonder if they know, or if they are like a flea making fun about the dog it lives on.)
Even if technically we probably regressed, the way we build software evolved. Agile development allows companies to gain visibility and more control over the process and the investment, essentially paying-as-you-go for fully working results. Today, developers need to push consistent usable value out of the door, and cannot simply disappear in the dark for months or years, taking forever to get projects completed.
With this new reality, development is now a less arcane and a more transparent team sport. Today software engineers need to be team players and work well with others. Technical skills are still very important, but transparency, communication skills, and teamwork are also necessary for their professional success. Smart “assholes” are no longer universally acceptable, and their presence in a team is a costly pain point; no longer business as usual.
Simple topology of hiring compromises
When you need to hire new engineers, under pressure to deliver consistent value to customers, you might be tempted to rush and compromise on your hires.
There are two main types of compromises: technical skills, and “cultural fit”.
Technical skills compromises come in two flavors:
- Hiring a developer who doesn’t know the technology you use, but is smart and can learn (hurts the short-term, and benefits the long-term.)
- Hiring a developer who knows the technology you use, but can’t or won’t learn new ones later (hurts the long-term and benefits the short-term.)
The “cultural fit” compromise is what you make when choosing to hire someone if they have the technical skills you need — fully, or compromising — but their personality or values are incompatible with the team and the company. Cultural fit compromises rarely improve over time, and you should expect them to hurt both in the short and long-term.
Poor performers kill teams
Poor performers take teams down, hurting everyone around them. By definition, the value they bring is smaller than the value they take away, creating a negative sum equation. If you choose to make a compromise hire, you’ll lower the productivity of the team instead of improving it.
When a new hire joins a team, you must expect a short-term learning curve and its associated costs. However, you should not accept a long-term cost due to a poor fit. A bad long-term hire will cost your business money and will decrease the quality of the work environment. It’ll hurt the productivity of the existing team and likely alienate solid contributors. “A” players do not accept to work with “B” players. If forced to, they’ll eventually quit.
Even if you compromise today, but have a plan of replacing the employee with a better long-term fit later, you must consider the cost of firing a team member; even a bad one. Anybody who joins a team requires training, and slowly becomes responsible for some of the work; they acquire knowledge and form relationships with other team members. The longer the compromise hire stays, the deeper their roots will grow in your organization. If you already know that a candidate is not the right long-term fit, do not hire them. Don’t do it, ever! The cost will be higher than the value.
Stories from the field
A couple of years ago I was looking for a strong Java developer to bring technical expertise and a boost of productivity to an already senior team. I needed someone with potential leadership skills, solid technical skills, and strong work ethics. I wanted someone with a history of loyalty for the organizations they worked for. For several months, I spent a lot of my time by single-handedly reviewing more than 1,000 resumes, personally conducting more than 80 in-person screening sessions, and organizing several interviews with the team. In the end, I made a great hire, and never looked back. It was difficult, lengthy, but the value was enormous. The new hire grew into a strong leader and is now running part of my development organization.
At the same time, do not think that all good hires have to be hard to find. About one year and a half ago I opened a key technical management position in my organization. I thought it was going to be difficult to find the right person and was prepared for an another lengthy candidate search. I was stunned when the very first in-person screening for that position led to an amazing hire. It took me days to fill that role, and I couldn’t be happier with the results.
In conclusion: never compromise on new hires. Hire only people who you think will bring long-term value to the company. Keep in mind the team and the position, but hire mostly for the company. If you focus only on the short-term, or the present context, you risk building a very unstable foundation destined to crumble. Do not inject poison in your organization’s blood. If you make a mistake, fix it quickly; however, remember that there are costs associated with firing someone, even someone who the team recognizes as a low performer.