Hacking Technical Interviewing

So you’re looking for a good developer, maybe even a great one to join your team. But what is a great developer?

The common answers are usually someone with great potential, good coding skills, agile with a great personality, and I’m sure you can think of more superlatives, But at the end of the day, we all look for someone we would really want to work with.

So how can you increase your chances of finding your next coworker?

Here are some tips to help you improve your technical review process

LET’S GET COMFORTABLE

Interviews are a source of stress for many developers. Most of them just need your help to feel more at ease. Outlining the interview’s steps helps to take the edge off and let candidates know what is expected instead of walking into the unknown.

I suggest avoiding getting into too much detail, since it could prevent you from deviating from your original plan, if needed.

ASKING THE RIGHT QUESTION

I’m a big believer in setting people up for success. Same goes for candidates.

What does that mean in the world of tech interviews?

I’ve got to say, I'm not a big fan of algorithm questions, especially in startups where you want to invest the time to find the right person. A mis-fit developer in a startup can be a huge pain.

Instead, II’d rather suggest a hands on coding question, Preferably one of a sub process in your current system. This way you can give the candidate a glimpse into what you do and get a fair idea on how they write code.

Moreover, choose a question that can evolve into a system design challenge, enter high scale into the equation and see how they tackle system design.

So no need for annoying tricky questions, just let them show you how they write code, How they approach the code, the structure of their solution, proper use of design patterns and object orientation. I always make a point saying to candidates, if at the end of coding your solution, you ended up with a single file then you’re doing something wrong.

ZOOM IN OR ZOOM OUT

In these pandemic times where most of the interviews take place in zoom I personally prefer the zoom in approach.

In an hands-on coding interview I’m all for asking candidates to share their chosen IDE on screen. This way you let them know they are not alone, which is a huge stress reliever.

A plus is that you can see at a very early stage if they’re struggling and if so steer them in the right direction like you would in real life, It will also give you a pretty good idea of how they approach code design, whether they started their solution top to bottom for example.

Another huge part of an interview is to see how the candidates converse with you, how open they are to suggestions and how they react to constructive criticism. Sometimes, it can all go terribly wrong..

Introducing,

THE ELEPHANT IN THE ROOM

Let’s say you realize at an early stage of the interview that the candidate is not compatible. How do you still manage to leave them with a good feeling yet without misleading them?

If it’s a coding compatibility issue or something else that got you to that conclusion, Cutting the interview short will leave the candidate with a clear feel of failure. On the other hand, if you continue on to the scale question, you’re risking magnifying the candidate’s incompatibility.

Remember my suggestion to keep the interview outline a bit vague to allow yourself to deviate? Well, that’s your way out. Instead of progressing to the scale question simply continue to converse on the suggested solution instead of broadening it.

If the candidate is agitated, maybe you said something that got lost in translation, maybe there’s simply no chemistry between you…

In points of conflict I found it most effective to avoid digging in any further, If anything scoping out worked for me, simply because it minimizes the conflict. Furthermore, At that stage of the interview there’s a high probability you won’t pass them so it’s easier to make the time left somehow tolerable for you both.

So if the discussion gets heated, my take is to let it go and move on.

THE GRAND FINALE

To sum up, tech interviews can be extremely informative for us as interviewers. It all depends on how we conduct and approach them.

I’ve been working at Melio for the past year and a half, and have taken an active part in defining the technical aspects of the interviews from a very early stage.

These strategies have really worked for me. They’ve helped me find good people that are also great coders and who are now my coworkers.

I believe that choosing hands-on coding questions over algorithms helped Melio grow rapidly without losing its core DNA. Additionally, we get a lot of positive feedback specifically on the tech interview stage.

Thanks for reading!