Recently, a student at Nashville Software School asked me about what employers truly look for in a junior software developer. Of course, the response is inevitably: it depends. Different people have different expectations. Then the student, intelligently, rephrased the question to ask what I looked for in junior developers when I was leading a team.

I've always had a short, two-item list.

Strong commitment to personal growth.
Puts the team first.

Now, obviously there are other traits that are desirable, but if the person did not have those two, it was a deal breaker. Two things that often get spit out in conversations about hiring are "problem solver", and "smart". These two items never came close to even making it on my long list.

"But Coach," one might ask, "how can you possibly assess those traits during an interview process?"

That's a great question. To answer it, allow me some room, your Honor, to phrase the response into a larger conversation.

A broken hiring process

Over the last few years, there’s been a simmering, persistent voice in our community that hiring is broken. Haven’t seen any significant solutions put forth - other than general platitudes of stop whiteboard interviews and don’t be sexist - and I’ve thought about what the root causes are. Through all the chatter I think I’ve identified some patterns in what everyone brings up.

Not knowing what traits to look for.
Or worse, knowing what to look for, but discovering they were wrong.
Not having time to spend interviewing correctly.
Having the right assessment tool(s) in place.

Ok, let me talk about these four points.

Not knowing what traits to look for

I posted, via several social channels, the question...

List the two core skills that you want in a software developer.

The results, after just one day of feedback, of what people truly want in a teammate are shown below. There was a reason I restricted the feedback to two, because it forces people to truly think about what’s most important to them.

Only once is Problem solving mentioned, which is encouraging because that’s often the fall back attitude of interviewers who don’t put in the necessary time to properly assess candidates. As human beings, we are capable of solving problems. It’s kinda what evolution made us extremely competent at. Saying that you want to see how a candidate solves problems is like saying you interview pet fish on how they can swim.

It should be a given that someone with enough skills to even be sitting across the table from you at a software developer job interview is adequately capable at solving problems. If you believe that's not the case, or have actually interviewed someone who was incapable at problem solving, then your initial candidate screening process is deeply, horribly flawed.

Humility
learn how you learn best, and embrace that method.
Taste for Simplicity
Ability to communicate about complex topics
Humility
self-motivated
open to growth
no assholes
no Prima Donnas
Persistence
belief in continuous improvement
Integrity
persistent curiosity
Disagree
Commitment to Kaizen
Ability to communicate effectively
Passion for problem solving
Team player
impatient to ship useful software to customers
effective communicator
curiosity/commitment to learning
communicates with their teammates proactively
enthusiasm/positive attitude
Asks questions -> learns from answers
commitment to improving skills
checks ego at door when working on a team
passionate about helping people
Committed to quality

Discovering the criteria were wrong

Ok, so getting people to be real about what they want may help dispel some of their faulty, perhaps lazy, assumptions that they have been operating with for years. I'll be optimistic and say that everyone learns from their mistakes, and strives towards emphasizing the above traits during the hiring process.

The next step is changing your entire process for recruiting people. It's scary. It's time consuming. It's expensive. Luckily, it's necessary in a knowledge based society so your return on investment will be high within 2 years time, likely, because you start attracting the right talent.

One of my favorite stories about this is Google. Their interview process used to be rife with pointless whiteboarding exercises about esoteric computer science problems, brainteaser puzzles, and pointless exercises that gauged "how someone approaches a problem". Well, around 2010, they started to change that process because when they started collecting data on who the best performers were, they found out that the process they thought was hiring the best, was actively keeping the best people out of Google.

"One of the interesting things we've found, when trying to predict how well somebody we've hired is going to perform when we evaluate them a year or two later, is one of the best indicators of success within the company was getting the worst possible score on one of your interviews. We rank people from one to four, and if you got a one on one of your interviews, that was a really good indicator of success." - Peter Norvig

Not having time to spend interviewing correctly

The only thing I can think about this is that adage, "You get what you pay for." If you think hiring is easy, then you shouldn't be hiring. Hiring the right people for the team is so critical that, next to making sure that the business stays operational, I can't think of a more important responsibility than hiring.

Make the time.

Having the right assessment tool(s) in place

If the first thing you asked yourself was, "What's an assessment tool," let me provide some ideas.

Codility - A tool to provide objective feedback on a candidate's capabilities.
How to Hire a Programmer - Step 5 is about giving candidates an audition project that involves a discrete, short, but challenging task to be completed.
Better yet, provide real-world code from your system, take out a method or two, and discuss it with a candidate during the interview. Have them write some code to see if they can fill in the missing pieces.

<div id="car-part-container">
  <div class="car-part part-01">Timing belt</div>
  <div class="car-part part-02">Spark plug</div>
  <div class="car-part part-03">Hub cap</div>
  <div class="car-part part-04">Dip stick</div>
  <div class="car-part part-05">Headlight bulb</div>
  <div class="car-part part-06">Roof rack</div>
</div>

<div id="selected-parts">
</div>

function selectCarPart() {
  // Determine which car part was clicked on

  /* 
  Add the name of the car part to the selected-parts HTML 
  element. The numeric identifier must be added to the 
  beginning of the part name.
  */
}

document
   .getElementById("car-part-container")
   .addEventListener("click", selectCarPart);

If your team builds interactive web applications, this is a simple, but effective, scenario that a candidate should be able to solve. If they can't, that doesn't mean they are a horrible developer, it just means that they are not right for your team.

This all goes toward the concept of actually assessing candidates on their ability to develop a solution to a small, but challenging problem. Assess them on what they would actually be doing on the job.

Please stop Googling stupid questions 10 minutes before the interview that provide no real assessment. It just make you look incompetent, and it's disrespectful.

The resume needs to die a horrifying death

Seriously, nuke it from orbit. Kill it with fire.

It's hard for me to imagine a more outdated, worthless, unproductive mechanism than the resume/CV in a knowledge based industry recruitment scenario. I stopped even looking at them years ago. A chronological list of previous jobs tells me absolutely nothing about that person that matters.

It's my opinion that any organization that requires you to submit a resume with a cover letter, instead of just a LinkedIn and/or Github profile URL, has completely stopped giving a shit about hiring great people. Now they're just busy hiding behind a completely antiquated system that has simply always been there and no one has the desire to change.

Assessing the important skills

Ok, so we've discussed how to focus on what you want to look for. There's techniques for assessing someone's technical capabilities that are needed for your team. Let's get back to the original question before I diverged.

How do you assess the critical skills that will determine a candidate's true success on your team? Basic technical skill opens the door, but since not a single response to my question dealt with technical prowess, let's discuss how to assess some of the most popular traits.

Communication

I've found a great way to assess this. Ask each candidate to have a prepared chunk of their favorite code, written by the candidate, for an interview. Then have one of the existing team members sit with the candidate and have it explained to them. Tell the candidate that their goal is to have your teammate state that they comprehend the code.

Look for a few things:

Does the candidate mention how their code solved a real problem for customers, or delivered true value to a client/company.
Does the candidate make sure your teammate understands / comprehends the code, or do they simply rattle off a quick, high level explanation.
Prepare your teammate to ask a challenging question or two about the code - improvements or changes - and watch how the candidate responds. With defensiveness? With excitement?

Continuous Improvement

To be honest, I don't know how you can accurately assess this during a typical interview process with a stranger. It's a trait that has to be observed over a period of time. However, this trait will quickly emerge during the first few weeks of the new hire being on the team. It may impact your decision on whether or not the new teammate stays on your team.

I've always relied on my instincts here. I ask a candidate what has piqued their interest in their tech stack of choice over the last year or so. Then see what, if any, steps they took to learn new ways of doing things, or new tools they have tried to use.

I would very much enjoy hearing your thoughts on how this can be assessed during an interview process.

Hit me up on Twitter and share your thoughts.

Assessing Core Software Developer Traits