Date Archives

January 2015

On Hiring Techies

I’ve had the good fortune to have worked on some incredible teams. The best teams I have been a part of each had a very structured and rigorous interview process. It took longer than average to hire new team members, but the tenure of team members was high and our attrition rates were unbelievably low. The teams gelled and that collaboration was reflected in the applications that we built.

Having an interview process like this leads to a lot of interviews over the course of my career – speaking with dozens, maybe hundreds, of potential candidates. I started writing this as a single blog post but it grew too large. Here’s what has worked for me, broken into a short blog series.

Evaluate Potential, Not Accomplishments
Coding Challenge
The Team Interview
Hire For Cultural Fit

Other Interviewing Inspiration

Johanna Rothman has some great books, articles and blogs on hiring technical people. She’s also an infinitely better writer than I, so I strongly suggest reading her work.

On Hiring Techies – Evaluate Potential, Not Accomplishments

This is a part of a series on Hiring Techies.

Evaluate Potential, Not Accomplishments

I don’t spend a ton of time reading resumes. Depending on the position we’re hiring for, I may look for a few critical skills but I’m mainly looking for themes that tell me that the candidate has a passion for technology. Do you contribute to an open source project? Do you blog? Do you have a history of attending or even speaking at conferences? Show me that technology is an important part of your life.

Don’t get me wrong. I do not want to read about your hobbies or what you do for fun. The fact that you have been the president of your local Pokemon club for 3 years or that you’re and avid White Sox fan is irrelevant. I want to get a sense of what you will bring to the team.

Does the candidate’s resume only highlight individual accomplishments? Are there any bullet points about past team’s successes? How about any experience introducing new technologies or organizing brown bag lunch sessions? I can typically spot a true team player based on how they highlight their successes and what they are proud of.

I want to work with a team of leaders. I want a team of mentors. There are millions of people who can write a web application. There are very few people who can write a web app and help me build a better team.

I’m looking for technological aptitude. A laundry list of impressive technical languages and tools is indeed impressive but it should never be the reason for hiring a candidate. Worse yet, it should never be the reason for passing on an interview opportunity or turning a candidate down. It took me a long time to realize that I don’t need to find someone with that fulfills every item on my wish list.

It’s important to remember that when we hire, we’re hiring a person and not a bag of skills.

Skills and experience are important, of course, but this should support your decision to hire someone rather than be the basis of your decision. This is probably the most frequent mistake I’ve seen folks make. Teams have missed out on great candidates because they were missing some specific tool in their belt. I’ve also seen very smart people hired who end up being culturally destructive.

I can teach an Eclipse user Visual Studio. I can teach a C# developer JavaScript. I cannot teach someone how to be passionate. I cannot teach someone how to fit into our culture.

Every position is different and the skills that are critical for the candidate to be successful in that position will vary. If your domain requires certain skills or experience then, absolutely, screen for that. I would expect this to be the exception rather than the rule, though.

On Hiring Techies – Coding Challenge

This is a part of a series on Hiring Techies.

Coding Challenge

Of course, if I’m evaluating a candidate to join my team I want to ensure that they know what they’re talking about. There are many ways to do this. Some people slam a candidate with technical questions for hours. Some people choose to do a whiteboard session solving a problem real time.

Like most, my preference is to go first through a short technical phone screen. If it’s obvious that the candidate has the critical skills we need, I’ll send out a coding challenge to be completed within the next few days. This is a short but non-trivial set of acceptance criteria – something that an average developer can complete in a few hours. Some folks balk at this request. This actually tells me a lot about the candidate and is an immediate red flag. Most candidates are happy to be given an opportunity to show what they can do and submit a solution within a day or two.

At this point the team reviews the submitted solution and decides whether or not to bring the candidate in for an interview. We make it clear that the solution that was crafted will be discussed during the interview.

As programmers, we spend considerably more time reading and discussing code than we do writing it. We need to be able to clearly explain our ideas and be willing to listen to feedback. The discussion I have with a candidate about their submitted solution will tell me more about their technical skills than a barrage of technical questions ever would. We’ll review design decisions, the application structure, SOLID principles and clean code, any technologies or frameworks used, and so on.

I also love reviewing the unit tests that were submitted (or having a discussion regarding the lack of tests). We’ll talk about TDD – why it was or wasn’t applied. It’s always fascinating to hear how the tests influenced the design.

I will very rarely challenge a candidate to solve some problem in person. The reason I don’t like to have the candidate code live is because the interview itself is already high pressure. Most of us have experienced this kind of test when interviewing. I want to see what they do when they’re at their best – not when they have a bunch of strangers staring at them. Programming isn’t about memorization. Anyone can find framework documentation online in seconds. Programming is about problem solving and I want to see how candidates think about problems.

Working code is one of the best ways I’ve found to evaluate a candidates technical skill level.

On Hiring Techies – The Team Interview

This is a part of a series on Hiring Techies.

The Team Interview

Who is involved in your interview process? Do a few managers speak to a candidate and then decide whether or not to hire them? There are few things more disruptive than having someone dropped into your team. If the day a new hire comes on board is the first day they meet their team then there is something wrong – not only in your interviewing process but I’d bet that there are probably major trust issues at the organizational level.

I probably spend nearly as much time with my teammates as I do my wife. If I’m spending that much of my life around someone then I need to know that we are (professionally) compatible. It’s not fair to the candidate or the rest of the team if they don’t have a chance to interview each other. I try to give as many people on the team as possible a chance to meet the candidate. After all, the folks on the team are much more qualified to decide who is right for the team than a few distant managers.

This advice goes for hiring individual contributors as well as managers. If your organization is looking externally for to fill a leadership role it’s extremely important for the people who will be reporting to that person to have a chance to interview them. Not only does this help evaluate the candidate from multiple points of view, but it will also establish a rapport early on.

The team must be completely bought in to the decision of who is hired into their team. Assigning a new person to a team can lead to distrust and skepticism. A healthy team knows what they need and will welcome the chance to be involved in the process. And believe me, the candidate will also appreciate being able to meet with as many potential future coworkers as possible.

These interviews can be conducted as a series of 1-on-1 discussions or as a larger group discussion. I’d limit this to at most 3 people at the same time, though. Panel interviews are intense for the candidate. They can also be challenging for the interviewers because inevitably someone will be more outspoken. If you do run a panel interview, practice first. Know who will be asking which questions and make sure that each interviewer has enough time to get through their most important questions. And always account for buffer time needed for the candidate to ask questions.

Once all interviews are complete the decision on who to hire has to be unanimous. If even one person does not agree on the hire then have a team discussion about the concerns. If consensus cannot be reached, pass on the candidate. Again, this shouldn’t be due to some missing technical skill – those can be taught. Find the right person, then worry about getting the right skills in place.

My teams may have missed out on some great people with this approach, but I’m confident that it was the right decision for the team. It is a risk, for sure, but the effect of a bad hire far outweighs it.

On Hiring Techies – Hire For Cultural Fit

This is a part of a series on Hiring Techies.

Hire For Cultural Fit

I said it earlier, but it bears repeating: I can teach someone a new technology. I cannot teach someone how to fit into our culture.

A lot of technical interviewers are laser focused on a candidate’s skill set. I’ve been asked to explain how clustered indexes work in SQL server and I’ve analyzed algorithm run times. Heck, I’ve been asked to provide a high level system design for a hypothetical application. Maybe it’s due to our industry’s disproportionally high percentage of introverts (myself included), but I’ve personally been through many interviews where I haven’t been asked a single question about how I work with others or what kind of environment I thrive in.

It is unfortunately rare that any behavioral questions are included when interviewing techies. This is a big problem that leads to poor performing teams and high turnover. Professional interview training would undoubtedly help. But in the absence of that, my advice is to ask questions that force the candidate to reveal how they’ve handled specific situations in the past. Get a feel for the teams and organizations where they have been most and least successful.

Maybe you know that your team can get trapped in design debates. Maybe your team rotates through presenters in bi-weekly brown bag sessions. You know what makes your team special and you know what challenges your team faces. You know the personalities and quirks of your teammates. Ask questions that reveal how the candidate fits in.

Avoid questions with binary responses. You know, dead end questions like “Do you like the new thingamabob framework?”. Focus on questions that invite the candidate to illustrate a past situation that they’ve been a part of. Ask them to describe a situation that they are likely to encounter at your organization. Ask clarifying questions. Listen to responses and build your subsequent questions upon each other. Circle back to an earlier part of the interview and dig deeper. Again, you need make sure that the candidate that you are interviewing is going to fit in with your team and with the larger organization.

All this culture and team chemistry talk may lead you to believe that the candidate’s tech skills shouldn’t matter. They do, of course, but I’d rather hire a good developer who is a great cultural fit than a brilliant developer who clashes with our culture. If the candidate has some experience that other team members do not then I want to make sure that knowledge will be spread.

The right hire will improve your team, your product and your organization. The right mix of interview questions you should have a feeling whether or not this candidate will do so. Spend the time to develop your interview process. You’ll be glad you did.