Interviewing Others

The longer I spend in software, the more convinced I become that the two most important choices you can make as a company are who you hire and how you retain them. I think that the right people can be handed the worst situation and succeed, and that bad people can take the best situation and still fail. Consequently, I've tried to be involved with as much interviewing of candidates as the companies I work for will allow. My hope is to help discern the best candidate, but also to try to improve my ability to interview others. I've written before about what I think makes a good resume, but I'd like to spend some time on things that I think are helpful to think about when interviewing candidates.

How We Fool Ourselves

The interview process is like any other skill: something that takes time to develop and is more than a series of facts or techniques. It's something we as developers stereotypically are not skilled at, and often a skill we think we're better at than we actually are.

As people that statistically think of ourselves as 'number people' or 'data people' we often fall into the trap of swapping soft skills for 'hard data'. Consequently, there is an insidious, subtle myth of the "objective interview". We can easily fall into such a deception, and then make a subjective choice while thinking we've been objective.

To start with a bit of shock value, an interview is 100% an exclusive, discriminatory process. At this point, our corporate brains have become hard wired to consider discrimination to mean only one thing: illegal or immoral dismissal of someone. Unfortunately, that means we've thrown the baby out with the bathwater. Just because we don't want to discriminate based on traits that are immutable (and not relevant to the job) does NOT mean that we're here to pick a candidate at random. Our process should very much be to discriminate based on someone's set of skills and even their personality (or soft skills). A current, common (generally unnoticed) bias is to actively fight against our gut because we've conflated bad discrimination with good discrimination. I've watched people unintentionally make clearly biased decisions based on things like race or gender specifically because they were so concerned about being biased that they started to get tunnel vision. (This is like when you're driving or riding a bike, you subtly steer towards what you're focusing on).

While I'm on this more sensitive topic, I've seen good intentioned people actively fight their own discernment on things like communication. If you are working with someone every day, and you can't understand what they're saying, it's going to be hard to build great things. Acknowledging this can make you feel like a jerk, especially if you speak one language and the candidate speaks three. (I also see this problem when people have bad internet connections). It's illegal to ask "do you have a car that you can use to get to work?", but it's important (and legal) to ask "can you get to work every day at the set time?". Having the tools to be able to show up at work (physically or virtually) as well as having the ability to clearly communicate yourself are things that are required to do the job well. A person may have a thick accent or bad internet connection and still communicate clearly, but when you're struggling to understand someone in an interview, don't allow a desire to not seem biased prevent you from making a wise choice.

We have to remember that an interview is not about us. We are acting as a member of a company, and saying no may make us feel bad about ourselves, but that's what's in the best interest of the company. It's much easier to be a jerk in an interview than to manage a developer who was hiding a lack of skill behind a communication barrier.

Going into an interview, you should be a "no" by default. There should be a level of weight behind that no that requires you to be actually excited about a person for it to flip to a yes. If you're not actually excited when they're putting their best foot forward, it's extremely unlikely that it's going to get better later. If you're on the fence, you're a no. (Remember how it feels to be in an interview, you're doing whatever you can to be the best version of yourself. It's unlikely to be nicer, more outgoing, or seem smarter six months into a gig than you were in the interview).

Interviews are incredibly subjective, and when things are subjective, our subconscious mind, or gut, or 'taste' are going to server us better than our conscious mind. This doesn't mean we'll be right, but often trying to rationalize everything will lead to us focusing on some less important detail and moving off of the right answer we already had. It's very easy to be a hard no and then during discussion move yourself into a yes (or vice versa). Rarely does this change of opinion turn out to be correct. Usually our gut has a good direction that we can then turn into a hypothesis and work to prove correct or incorrect.

How We Mistreat Others

I've been in interviews as a candidate that have felt oppressive, and been in others that have felt empowering. I've watched interviewers pull a candidate out of their shell, and other interviewers spend nearly the whole time building themselves up. Any candidate worth your time is also evaluating you the interviewer as an emissary of company culture. We should treat the candidate as someone who inherently has value, whether they choose to work with us (or us with them) or not. We should respect them as people, and as the developer that we hope that they are. We should skip formal speak, sales talk, or corporate mantra. Doing this isn't just the right thing to do, but it also removes walls towards actually getting to mutually know each other. And the goal is not to check boxes but to actually get to know someone.

Instead of "we're here to evaluate you" say "we're here to get to know each other". The former is hierarchical and adversarial, the latter acknowledges them as a partner, and is collaborative.

As an interviewer it's our goal to get as much relevant data on a candidate as we can. Any time we're talking, we're actively preventing ourselves from gaining more data. To a lesser point, any time a candidate is talking about something that's not relevant, we're also losing opportunity time, though we may still be learning something from them even if it's not a direct question we have. In general, whoever listens most, wins.

While a candidate talks, we should note anything that we 'flag' as we listen. This can be badly formatted or just sentence fragments, and shouldn't include too much time on our opinion of what happened. We just want to take enough down that we can refer back to it later and add our opinion / comment if needed. The goal is to balance really listening with also marking down flags that we can reference as we form our opinion or write a review to stakeholders.

Aside from treating a person with respect and being 'real' with them, the next most important piece is working to provide value to them. Even if someone doesn't get the job, they should walk away from the interview feeling like they got something out of the time they spent, even if that's just feedback on how they can do better at getting the job next time. Remember that people generally grow their skill set and even if they're not a fit for a specific role, it's still in the company's interest to leave a positive impression for the next mutual opportunity.

We should arrive on time or a minute before the interview to show to them that their time is important to us. Leave the power plays at the door if you don't want a hierarchical culture. You should also be as transparent as possible, even regarding things that are not favorable to the company. Displaying honesty makes you more attractive and reduces the risk of someone getting in and then quitting because they were deceived or not well informed.

It's important to leave at least 10 minutes for their questions, and to answer them concisely so that they can get what they need and move to the next question. This should be important enough that we schedule around it and cut our part short if we need to. Our answers to their questions should be focused to actually help them. It's also valuable to preemptively tell them next steps so they feel comfortable with the process. (The process should be static and clear so they don't feel like they have to guess how well they're doing, or feel uncertain about the steps as well as about what you're opinion of them is).

Prepping and having your script down frees you up to improvise as it makes sense without getting side tracked or wasting time. This process is worth preparing for and giving priority to, but once we're in a conversation, we should be able to adapt to the interview without being formulaic. (With the caveats that time should be given for them to ask questions, and changes to the interview schedule should not happen mid flight). When you strike something that they're passionate about, adopt your questions to those things, as that's likely to give you the most insight into who they really are.

The TDD Kata

I'm convinced that the best technical interview involves the traditional TDD Kata. A kata is a simple programming problem that's not got a specific right answer nor is meant to challenge a candidate's "leet code" skills. I think Pencil Durability is a great example.

The candidate uses their preferred IDE and language to work through as much of the kata as they can, while following strict TDD. The candidate writes the smallest test they can, that should need the least code to write. They then write the least code to pass the test. Then they refactor (maybe) and repeat the process.

The goal is not to see how far they get. When I lead the pencil durability kata I've almost never seen someone complete the first story. It's also not about others solving the problem the same way that I did. The goal is to understand how they think and work, as well as how familiar they are with their tools and how ready they are to trade feedback and collaborate.

If I have a developer who is incredibly intelligent and easy to work with, who magically understand new concepts and enjoys their work, I am not going to care at all if they know our specific stack. On the other hand, if the developer knows everything their is to know about our tooling, but can only work their specific way and can't handle feedback or learn something new, I'm not interested. This is why an open ended, technology agnostic kata is so much more important than doing a 'rest' or 'spring' exercise. The latter are essentially knowledge tests. We're also not building highly complex algorithms for search results or limiting our search based on official IQ tests, and so leetcode challenges make less sense as well.

Conversely, it's interesting how often people will say they are familiar with TDD, and then immediately jump in and do a data model, write method signatures, and do everything they can to put off writing a test. Can they correct when I politely point it out? Can they keep that correction going, or do they just revert to their old ways once the pressure is off? How do they handle me giving bad advice or saying something clearly wrong? How do they handle being corrected? How do they handle tools failing on them? Do they blame others, or panic, or work with you to solve the problem? These are all super valuable data points for guessing how someone will work with the team long term.

Doing a TDD Kata interview is more challenging than asking questions. It's first important to have the evaluator(s) be strong in TDD; otherwise the candidate will get mixed messages as well and bad advice can make a clear evaluation much harder. In addition to being conscious of TDD, a good evaluator also needs to balance the tech and soft skills, looking for the right time to challenge, reel in, and explore the different data points of how a candidate responds to different situations. A good evaluator should also help keep the person out of the weeds, while not being overly directive of how the person is solving the problem. We should follow, not direct.