I do a lot of interviewing as part of my job. The most common position I’m trying to fill is essentially my own, a software engineer. Specifically, I’m a back-end specialist — someone who develops APIs, works with databases, etc. Interviewing for a role like mine is more of an art than a science. Those that treat it like a science are often focused on the technical aspects of the role. They give candidates coding exercises, and treat the interview like a pop quiz.
But you won’t get the best candidates by putting them through what amounts to a technical certification. What you really need are people who will work well with your team, who will add something of value to it. So, to that end, here are three of the things I look for in an interview.
1. Samplers and Deep-Divers
Developers generally come in two flavors, what I’ll call samplers and deep-divers. When I first see a résumé, I’ll look at how varied their experience is. A sampler generally has a very busy résumé, with references to a wide array of technology. Deep-divers are more focused on something specific.
If you’re a sampler, then I have two concerns. One is that I think this flavor is more of a “flight risk”. If we invest in you, will you still be here in six months? Or will you get bored and move on to the next opportunity? I don’t want to invest my time and resources into someone who won’t stick around long enough to be a return on that investment.
And samplers also tend to be early adopters, who favor the most functionally appropriate solution over one that is more maintainable. This can often result in solutions that are more bloated, with more dependencies and complications. Especially if I think you’re a flight risk, do I really want you to saddle me with additional tech debt before you go?
If you’re a deep-diver, I first want to know if your chosen area of expertise is what I’m looking for. I generally work in C# shops, for instance, and wouldn’t have much use for a Java deep-diver. And then I want to see if you’re actually honing your craft. Years of experience doesn’t necessarily mean anything. Personally, I learned more about T-SQL in my first six months at one position than I had accumulated in the previous ten years.
I’m sure I favor deep-divers a bit, because I am one. But there is a place for samplers as well. This is less about preferring one or the other, and more about identifying what type of contributor you will be and how you will fit into our team.
2. Humility
I like this word, because it often provokes a reaction that gives away how humble a person really is. While modesty, selflessness, or even kindness might be better words, this one tends to elicit a more telling response. Those with little humility tend to view it as a shortcoming. But I think humility is a coworker’s (and especially a manager’s) greatest asset.
So I will throw the word out there and see how you react. And then I’ll also look for other clues about how much your pride may get in the way of your productivity. Will you be able to admit when you’re wrong? Are you open to change? Will you approach your work as part of a team?
Or are you the type of developer who would prefer to go hide somewhere and get your work done on your own and only come up for air when it’s time to submit your 1,000-change PR? Because, if that’s the case, then I frankly don’t want you on my team.
Another way I smoke this out is to ask about peer programming experience. Most people don’t have much, but I’m not asking it to gauge the amount of experience you have. I’m looking for your reaction to the concept. If you’ve participated in it, then what did you think of it? If you haven’t, then how open are you to it? What I’m really answering in my own mind when I ask about pair programming is whether or not you’re going to be collaborative.
I’ve seen a lot of fragile egos over the years in my line of work. I’m sure I’ve even been there myself. It comes with the territory. We don’t want others to tell us that our code is ugly. But it IS ugly. Look at what you wrote six months ago and tell me there isn’t something about it you don’t like. So I’m looking for that contributor who knows that he or she isn’t perfect, that skills evolve, and that they evolve best when we can be honest with each other. And that honesty requires a certain degree of humility.
3. What are you asking me?
Whenever I go into an interview as a candidate, I always have a list of questions of my own. They’re generally in three categories.
First, I want to know what your tech stack is like, what kind of problems you’re having, how you’re solving them, etc. Second, I want to know what your team culture is like, how under water you are (e.g. working nights and weekends), your impression of your leadership, etc. And third, I want to gauge how healthy your business is.
In other words, I’m interviewing the employer as much as they’re interviewing me. So when I’m on the other side of the table, I’m expecting the interviewee to be doing the same thing. And if they’re not, then why not?
So, there’s definitely more to it than this, but these are three things I keep in mind when I’m interviewing candidates. What do you look for?