Technically qualified?

Why technical interviewers are letting competent employees slip through their hands.

We’ve all been there. We arrive to interview for a job and as soon as the questions roll in, we wonder why they are relevant. One of my favorite nonsensical questions is about how many years of experience you have. This question has been abused in so many interviews that it’s effectively become a meme. One great example is the developer who invented FastAPI not having enough experience to get a job using FastAPI. My point here is that even though we know some interview questions achieve very little and tell you almost nothing, we still use them when we sit on the other side of the table. And I don’t just mean this one specific question about years of experience. I believe that if you ask a technical interviewer (or just about any interviewer) if they have ever asked a question in an interview and gotten zero helpful information from the question, the answer will be a resounding yes.

The problem is that even when we have a well intentioned question, we just don’t always get where we expect to when it actually comes time to ask the question. We are human and answers don’t always match what we are looking for or questions don’t actually give us the information that we thought they would. And that is in the best case where interview questions are thought out…but they aren’t always thought out.

Interviewing is, by its nature, time consuming. And that’s a good thing. If you aren’t spending time on determining if someone is a good technical and team fit, then you probably shouldn’t be interviewing. The problem occurs when time juggling between our normal workload and interview preparation or post-interview evaluation.

If we don’t have the time, we don’t necessarily prioritize having the best questions. In the example at the beginning, I mentioned years of experience. Part of the reason that this is a common qualifier for jobs is because it’s simple and verifiable. But in actuality, what we are actually looking for, among a plethora of other traits, is the combination of intelligence and experience — wisdom. I have never ever heard anyone actually use wisdom as a descriptor for a potential applicant, and therein lies a problem — intelligence can easily be omitted when we interview.

If you hired someone to do a technical job, I believe you would expect them to be able to grow and adapt. In technology, tools and software change so quickly that it would be crazy for you not to expect at least a little growth in potential hires. So, contrary to what you would think based on common interview practices, intelligence can be worth more than experience in the long haul. This isn’t always the case, but definitely holds true in quite a few hiring situations. And this means that you need to find a way to evaluate intelligence effectively.

Generally speaking, this means less tool/language specific evaluation. It becomes a question of how applicants think and whether they can demonstrate the ability to problem solve in a way that is conducive to software development, or any field for that matter.

What I’m trying to get at here is that the questions utilized to obtain wisdom metrics can’t be the same regurgitated questions that you see floating on the internet. Yes, asking someone about years of experience can provide a metric. No, it is not the only metric that matters and might in fact be a less valuable metric, at least when taken by itself. And going through a sheet of common Java interview questions isn’t going to cut it either. In the end, you need to find a question that you can gain more insight from than you see at face value. It needs to evaluate candidates effectively and consistently.

One of my favorite interview questions is about having potential hires design a cache. It’s conceptually very straightforward. It’s simply a storage mechanism that you put data in and take data out. But this has the possibility of checking many of the boxes for information that I find valuable when evaluating a potential hire. It gives me insight into their ability to look beyond the current problem and design effectively for future scalability. It lets me know that they can practically translate a rough set of directions into actual code. It shows me that they can think through potential data containers within the cache and evaluate performance and tell me why they would choose one over another. It tells me if they can think through testing effectively.

Notice that while this question pertains to algorithms and formulas, it is not a recitation practice and you can answer all the criteria that I find valuable without any prior knowledge of these algorithms and formulas by simply putting in thought and showing good coding practices. And it shows me that they have some basic programming skills. It doesn’t have to be in a specific language, it just has to demonstrate that they CAN code.

At the end of the day, it really comes down to coming up with a question that works for you. I encourage you to think about what you truly value in your best engineers or even people you’ve worked with in the past, and compile a list. If you are just thinking of items like, “proficiency with tools”, think about whether it’s simply that they knew the tool or whether they invested time to cultivate that knowledge. This list should be core values and thought patterns, not just languages/frameworks that anyone could pick up over time. Once you have that list, devise a technical problem that will provide you with answers to the items on the list. It doesn’t have to answer all the questions straight away. Sometimes getting a couple data points involves follow up questions to encourage more problem solving on the problem you outlined. I commonly query afterwards for information about testing, for example, because it is very rare that someone volunteers that information in an interview that they view as a simple coding exercise.

None of your questions have to be incredibly complicated, but they do need to provide you with answers to the important values/traits you are looking for. And different levels of experience will usually manifest themselves through the course of these problems. More experience tends to lend itself to more answers, more information, higher level design explanations, and less mistakes in answering your questions.

A well thought out question can give you all you need to know to evaluate a candidate for technical proficiency and experience. And once you’ve developed your standard questions, you can just keep using and cycling them as needed so you don’t have to continually invest time in those questions.

TLDR

Technical interviews do need to ask questions about whether they can code, but really should be more concerned with how they think and approach problems. At the end of the day, someone who can problem solve effectively is worth way more to a company and to a team than someone who can reiterate a formula or a trait of a programming language from memory, or who has had a very specific experience with a tool. While those people may provide short term gains, the problem solvers will always be capable of going further down the road by expanding their knowledge and self-evaluating.

Originally posted on https://medium.com/@mcsgroi321/technically-qualified-5afe616d66da