What I Look For When Interviewing
At a previous job there were a couple of months where I was doing 2 - 3 interviews a week. Even with a bank of questions I would go into an interview and have no idea what to ask the candidate. Finally I realized that I needed a better plan and came up with two basic questions for making a hire/no hire recommendation:
- Do I want to work with this person?
- Can this person do the job?
Do I want to work with this person?
This is what most folks are talking about when they say “soft skills” and “team fit”. I think it is the most important thing to evaluate in an interview. Skills can be taught but personality mismatches are hard to fix and can have a very negative impact on morale. I thought about what I liked about my current co-workers and came up with some questions that I think give a good indication that I’ll enjoy working with someone.
Does this person know their strengths and weaknesses?
I want to work with folks who know when they need help, know when they can be successful, and know when they can teach me something. People who don’t know what they don’t know are a liability.
Ryan Davis taught me a great way to assess this. I pick a couple relevant skills on the candidate’s resume and ask them to rate themselves on a scale of 1 to 10 for that skill. 1 is a complete beginner and 10 is the language/framework inventor. Once they rate themselves I ask a technical question or two that someone at that skill level should be able to answer. If they get it correct-ish I move on, if they struggle I’ll give easier questions until they are successful.
If someone rates themselves highly but struggles with relatively basic stuff I usually attribute the mismatch to Dunning-Kruger effect. Perhaps the candidate is more junior than we realized.
Can I communicate with this person? (explanations are good etc?)
In most coding interviews candidates are asked to explain their thought process they used to solve a problem. A lot of people think that the interviewer is looking for a specific word or answer. Sadly, some are. Good interviewers though, are assessing how well the candidate communicates about their code.
When I ask someone to explain their solution a good answer is any answer I understand. I’d rather work with someone who can explain their incorrect code than someone who came up with a correct answer but can’t explain it. I also like candidates (and co-workers) that understand any hints/corrections that I offer.
Will I be able to work with this person in a potentially high stress situation? (site down, late at night, etc)
Many software jobs include periods where nothing is working and managers or co-workers are bugging you to fix something quickly. Some people do really well in these situations; they prioritize, delegate, and communicate clearly. Other people shut down, become confrontational, or get tunnel vision and spend hours working on the wrong thing. I prefer to work with people who can handle stressful situations with grace and/or communicate what they need to be successful. Most folks find interviews somewhat stressful so I use the candidates behavior during the interview to judge how they’ll act in other stressful situations. It isn’t perfect but I find it more accurate than questions that start “tell me about a time _____”.
Does this person seem capable of learning and adapting?
At every job I’ve had I needed to learn a new framework, language, or tool on the job. I like co-workers who are inquisitive and not intimidated by learning new things. This is hard for me to assess in an interview. The best question I’ve come up with is “how do you prefer to learn new things? books? classes? jumping right in?”. I don’t care what their answer is. Experience says that anyone who can answer this question has learned something new recently.
Will this person fit into the existing team?
This sounds a lot like “team fit” but what I’m really looking for is “team balance”. I like working on teams with a mix of experience levels, favorite technologies, personalities, etc. If my current team has several loud argumentative types maybe a more laid back person will fit in better. If there are several senior developers perhaps we can take on and mentor a more junior developer.
Like many people I used to favor candidates that were similar to myself. After a few unsuccessful hires I thought about what had gone wrong and I realized that our team was out of balance. The more successful folks were the ones who brought balance to the team in one way or another.
Can this person do the job?
Realistically I can’t evaluate how well a candidate knows all the languages, frameworks, and tools that might be relevant for a given job. Instead I get to ask one or two coding questions and form some general impressions of their coding style and how they tackle problems. When I’m watching someone solve a code question, here are the questions I’m asking myself:
Does their code make sense to me?
I like co-workers who write easy to understand code. A candidate’s code should be easy to read with good variable names. It should follow typical patterns for the language and framework. What a method or class does should be easy to figure out from its name. The code should solve a given problem in a straight forward manner without excessive cleverness or obfuscation.
When looking at whiteboard code I’m okay with a couple missing braces or semi-colons. In typed code a couple common rookie mistakes/patterns don’t bug me. If the intent is clear and the code would work efficiently enough I’m happy.
Side note: A personal pet peeve is code that is written in one language but is stylistically another. I’d rather you did your interview question in C# than read a C# solution written in Ruby. Code like is this fingernails on a chalkboard to me.
Am I willing to debug code they write?
Software development is usually a team effort. If we are working together at some point you will have to dig into code I wrote, find a bug, and fix it. Likewise, I will have to dig into code you wrote, find a bug, and fix it. There is a good chance this will happen at a bad time, like when you are on vacation and a bug needs to be fixed today. If someone writes well tested code with clear separation of concerns I’m happy to debug a problem. If someone writes 400+ line methods with inadequate tests or uses obscure language features my willingness to debug their code goes down significantly. If I’m not willing to debug a candidate’s code I can’t recommend hiring them.
Is this person able to figure out what the actual problem/bug/story is?
In my opinion, one of the most valuable developer skills is the ability to read a bug report or a feature request and understand what the customer really wants. Frequently a bug report will say something like “make the widget blue” when the actual problem is “it is hard to read the text on the widget”. It has been my experience that developers who mindlessly build what is requested often have to do multiple iterations before the really customer problem is identified and fixed. Developers who can ask questions and understand what problem the customer is trying to solve are more likely to end up with a happy customer on the first try.
Can this person debug/diagnose problems at a variety of levels?
Debugging and diagnosing problems is part of programming but I’ve met a number of experience programmers who weren’t the best debuggers. I like working with people who can debug/diagnose well at multiple levels and who are logical about their process. Some bugs you catch in a unit test and some only manifest on production environments with real load. Good experienced candidates will have preferred tools for figuring out what’s wrong at both the unit test level and the integration level. Most candidates will use their experience to form a hypothesis about what is wrong. We’re human. We pattern match. Personally I think “this feels like a missing index” is a fine starting point for further investigation but the verification of a hunch/hypothesis is important.
Final Thoughts
This is a high level overview of what I desire in new co-workers. No candidate will be perfect but between these high level questions and list of the types of tasks I do on a weekly basis (usually pulled from pomodoro logs) I feel I can make decisions based on consistent criteria instead of a combination of random impressions and my mood at the time of the interview. Hopefully this helps someone else.