The Technical Interview, From both sides.

interviewI’ve been in the computer industry for a long time. Long enough to have both been an interviewer and the one being interviewed. I began to make observations recently about some trends in the process of the technical interviews I’ve been part of.

Here’s the scenario, you make it through the pile of bloated resume’s you create your short list of candidates, or you are one of the candidates. You are called to discuss the position by HR, and they arrange for you to get in touch with someone who is actually looking to hire for a position in their area. The poor soul is overworked, probably not paid all that well, tired of being short handed, and so overwhelmed with paperwork that their technical skills have become a little dull. You make it through the phone call, they seem to like you but they don’t have the technical skills to be able to adequately discuss details of what you need to be able to do for the job.

Here comes trouble, he has his ‘Guru’ conduct a technical interview, They throw every obscure technical question at you they can either remember from their training, or look up in their notes ahead of time. The impression I always get is they’re marking their territory, and they aren’t going to make it easy. They want to be the alpha dog, and no matter what you know, your inevitably going to have trouble. You will either have too little experience or knowledge to answer obscure questions. Or worse, you’ll know all of the answers and then some, inadvertently bruising their ego.

This type of interview outright sucks, you have a technical person who probably doesn’t want to be doing the interview, but their circumstances places them into the position of having to interview people to either take the lead position they wanted, or hire someone with the hopes they will get the lead position. It’s tricky because they need to hire someone, but it can’t be someone too good because it might make them look less competent in the long run.

The best interviews I’ve experienced were the ones that felt more like people having a technical conversation. This is how I generally interview someone. You get to see the level of technical skill they have, without calling them out for not remembering obscure facts. In addition you get to see if their personality and soft skills are compatible with the team and the job your hiring for. You don’t want to hire someone with an encyclopedia of technical skill if they cannot apply it in real life situations, nor do you want to hire a brogrammer or douchebag who is overconfident but lacking in real skill.

When I interview, or feel I’ve been to a good interview, I walk away feeling that I’d really like to work with these people. Their skills are similar or better than mine, they clicked with the team they have to work with every day. They can have a technical conversation and provide examples through an understanding of their training or from their experience, but it’s a conversation, not a test.

It is just as important to look forward to working with someone as it is for them to have the skills to do the job. A barrage of obscure highly technical irrelevant questions that are just something you wouldn’t have a casual conversation about, is just a bouncer at an exclusive club. No matter what you do or say to get in, you just never will.

You need to effectively understand what is needed to solve a problem, creative thinking, and the ability to learn what you don’t already know. You need to be open minded and able to acquire new skills, and accept constructive criticism. You need to be willing to adapt to changing processes and accept that the way you do things, isn’t necessarily the only way, or even the best way. There will always be people you have to work with that know more than you, and many that know less. The key is to be able to communicate what you know in a manner that isn’t going to force someone to become adversarial. This is the same type of skill needed to be able to work with clients or customers. It’s called empathy, you need to be able to put yourself in their position and understand what it is they’re looking for.

From a technical interviewer standpoint, you need to learn to allow the person your interviewing to steer the conversation, they will take you into their area of comfort, you can then ask a few questions about details about how they might solve a problem, make small talk, let them talk fondly about things that interest them. it will give you an ENORMOUS insight into their work process, skill set, or personality. It will be a lot more beneficial than running off your obscure question script. You can easily tell when someone is inexperienced, what skills they have, how they solve problems, and where they are strongest just by talking to them and listening to them carefully. In addition the conversation shouldn’t feel awkward, if it does, then either they’re nervous, or your intimidating them and you need to make them more comfortable.

Hopefully this will be a useful bit of information. I’ve seen companies that are just way too small, or lack way too much skill to rule people out just because they can’t get past those super technical questions. On the other hand, you have large companies where there is an enormous amount of competition in the company, and candidates that you do need to weed out the ones that just can’t cut it in your environment, I doubt a majority of the companies fall into that category. You really don’t want to drive away people with an enormous amount of experience, or great technical skill, just because their unable to answer a question about the difference between a VAR declaration in Javascript or C#, or the difference between an object or var declaration in C#. As a developer, if you don’t know, you can look it up if its relevant to the task.

In the coding world there is a difference between a programmer and a developer. One writes code to perform a task, the other writes code to solve a problem.

Leave a Reply

Your email address will not be published. Required fields are marked *

*