How Not to Hire Developer Bozos

Over the past 16 years working in tech and specifically slinging code I've had the extreme good fortune of working with some awesome and very smart individuals. Some so brilliant they were almost like human compilers who could spot a problem with your code in a blink of an eye; always that darn semi-colon. I've also worked with some folks that well weren't so great. They bogged down the team and really didn't deliver much. In most cases it wasn't because of lack of smarts but a combination of several other factors.

As I moved up the ranks and started managing projects and software development teams more than writing code I started to pay careful attention to hiring. One of the most important things you'll do as a leader and as a company for that matter is hire great talent. An article that I think really distills what I've learned over the last 16 years and one that I consistently go back to is Joel Spolsky's The Guerrilla Guide to Interviewing Version 3.0. An oldie but a goodie that dates back to 2006 but still holds true for me as hiring plays a critical part in my day-to-day. It was so popular that Joel released an entire book about the topic: Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent.

Joel is a straight shooter. In a nutshell you want people who are:

  • Smart,
  • Get things done,

These two together make a lot of sense, but take note that one without the other just doesn't work. I would also add one other principal:

  • And not an asshole

Harsh words I know, but let me explain. An asshole is somebody who is not easy to work with, not willing to help his team improve, or their level of snark reaches a point where it starts to build a toxic team culture. A toxic culture that once ingrained is very difficult to remediate. The more senior the asshole the faster and more toxic the culture can become.

Really that's it. I could probably sit here and list out a 100 different things you should look for in a perfect candidate including great hair and a rad hoodie but we'd be wasting our time since everybody wears the same rad hoodie anyway and great hair so elusive. In the end there is just a few things that help move projects along: it's smart individuals with a bias towards action that help each other succeed as a team. Great software is built by great teams not the Lone Coding Messiah.

Over time a group that exudes these traits over all others will beat a team with a wider spectrum of traits or with none of these at all. Remember you'll need all of these traits together not just one out of three.


Let's be realistic; technology and software development specifically is hard. I would like to say that a hardworking attitude is all you need to succeed but tech is not for the faint of heart. It involves high levels of quantitative aptitude. Most of the time you are not going to be working on things other have done before so you can't just copy everything off the internet, although it has become easier .. thanks Stack Overflow!

Not an Asshole and Get's Things Done, but not Smart - Folks who are nice and put in a lot of effort in getting things done, but just aren't that smart will make mistakes. Mistakes that your team will constantly have to fix. You'll have to spend lots of time teaching them and explaining things. At the pace at which technology moves this person will fall behind and become an anchor for the team. You may like them and they probably have a great work ethic but without the aptitude they'll always be playing catch up.

Get Things Done

Software projects are never really done they are ever evolving organisms that are only done when they die. That usually means nobody wants to use them. You want your software always evolving most of the time extremely fast. According to your stakeholders never fast enough. That means no time for foosball, okay maybe just one game. But after that there is always something to do: update CI scripts, write functional tests, update documentation, review resumes, conduct code reviews, answer customer questions, and of course address Bob's nitpick on your latest pull request. Oh Bob, really?

There is rarely time to waste pontificating and debating for the sake of demonstrating how smart you are. At some point you'll need everybody to shut up and row.

Not an Asshole, Smart, but doesn't Get Things Done - We all know this character. The PhD type who is more interested in explaining theoretical concepts so far off from what you are working on that you are left with a deer in the headlights look. They are wicked smart and probably nice but don't seem to contribute a ton to the repo. Instead they walk around the office with a coffee mug in their hand constantly pontificating about the benefits of Quantum Computing. Dude, we are writing a web app relax. Smart, but not useful.

I know not all pull requests are the same so you can't compare lines of code or PRs submitted but at some point code is currency. You'll need folks to contribute in meaningful ways.

Not an Asshole

Software projects require lots of collaboration across various parts of a system. You'll spend lots of hours engaging in giphy battles on slack, pair-programming, reviewing code, debating design, and deciphering vague product owner acceptance criteria with your teammates. Bottom line you'll need to like who you work with. You are going to spend a lot of time with them in the trenches. You don't have to be BFFs but you at least want people who are not condescending and don't treat you like an idiot when something isn't obvious. Nobody want's to work with someone who is smart but is a total asshole. As your reading this somebody from your work experience is coming to mind: yes you got it, the self-proclaimed genius who is always right and shoots down everyone's ideas. Yup that guy. You are probably clinching your fist and thinking about how your attempt to use recursion was not stupid. Relax take a breath.

They may be able to code but their snark is palpable and depending on their seniority it could lead to building a culture of junior devs taking cues from this toxic individual. Great software is not built by a superhuman programmer who singlehandedly decides that everyone's code is crap and rewrites everything in Ruby on Rails while they were sleeping.

If unchecked from a technical leader standpoint this will become a nightmare to resolve. Most of the time you'll have to cut the cancer at the root to avoid it from spreading and it's not pretty.


But How?

Just as there are several ways to implement a feature there are several ways to find solid hires. What has worked well on my teams has been a combination of some sort of code challenge or real world task, and broad team input and consensus.

Code Challenge/Real World Task

In the end, code is currency and you need smart folks to write it. Also, your teams' time is valuable so you don't want them conducting interviews 30 hours a week. For the last several years our teams have filtered candidates with a simple code challenge administered online. There are several online platforms out there but we settled on Codility. Codility allows you to put together coding challenges of various types from their large library of questions. Anything ranging from algorithms, bug fixes, testing, database, and many more. They are constantly adding questions and expanding their library.

Once the team likes a resume the Codility challenge is sent to the individual via email. Individuals have one week to complete the challenge. That means a deadline. This helps us answer several questions:

  • Can the person code? - Smart
  • Can they manage their time and meet deadlines? - Get Things Done
  • Can they follow directions? - Get Things Done
  • Are they really interested in the position? - Insightful

You would be surprised how many candidates don't submit a response to the challenge. How many folks don't meet the deadline. And lastly how many folks score extremely low. The amount of time saved by administering this type of challenge via a platform as oppose to your team having to do it is huge.

If online code challenges are not your thing giving a candidate some sort of real-world coding exercise relevant to your product and company is a good idea. We support an open source product on Github (Google Earth Enterprise) so assigning an open Github issue to a potential candidate is a great way to observe them going through the motions on a real-world task. You want to be realistic here and not assign somebody a huge module that will crush their hopes and dreams. Usually you want something they can accomplish in a day or two. Give them a week to accomplish it to make it feel real. Again Smart and Get Things Done.

Broad Consensus

In this stage you'll want various people on your team interviewing and interacting with the candidate. You'll want several of the team leads and developers sitting in on the interviews. You want to ask technical questions but you'll also want to ask behavioral questions that help identify their tendency to collaborate and work well within a team.

  • "Tell me about a time when you went out of your way to help a co-worker get something accomplished?"
  • "Tell me about a time when you had to illicit help from someone with specific expertise you didn't have to ensure delivery of a project?"

What you want to do here is get an understanding of how the candidate collaborates in a team setting. If they struggle with these type of questions it probably means they'll have issues working with a team.

Also, look for red flags. When the candidate bad mouths their previous employers or teammates it's usually a bad sign. You want people to keep their answers relevant without pointing blame. There is nothing worse than somebody who is never wrong and always blames management, the stupid customer, or a inept teammate as the reason the project failed.

As engineers and managers you want to be as quantitative as possible by allowing data to drive decisions. Code challenges are great for that, but sometimes you'll just need a gut check from a wide representation of the team to make a decision. At this point you'll want to gain consensus from the team. Interviewers need to assume that this person is going to be assigned to their team. Interviewers should never assume this person is fine for someone else's team not theirs. People are shifted around on software projects all the time so don't pass the buck because you might be left holding the bag. Also, keep in mind that hiring somebody is a lot easier than letting them go. It sounds easy to just fire someone but in practice it's actually hard. Look at hiring as a long-term relationship.

So that's it. It's not anything ground breaking but three factors that I look carefully at when making hiring decisions. Ultimately your process should help you identify folks that are Smart, Get Things Done, and aren't Assholes.

Happy Hiring!

- Andres Terrazas, CTO

← Back