Tech Interview 101

So you want to start contributing to the Hr team and start doing your interviews for the company you represent, this is a big deal and responsibility since you will be part of the process who selects new teammates for your company.

As a tech interviewer, some of your responsibilities are to evaluate the tech knowledge of the candidate, the ability to solve problems, how its handles pressure and so many more.

This is not a guideline for a tech interview, it's just some tips that I found useful over my time doing It, here are some topics we will see in a few.

1. Profile/Context
2. Time of interview
3. Questions
4. Exercise
5. QA

Profile/Context

What we are meeting to this?

Knowing the necessities of the team is the best approach to finding a perfect match, even if the information always comes like “We need a senior dev”, you have to consider something like

Tech stack and leaning curve— We may face a good candidate but he doesn't fit the stack of the project, so we may discard a precious diamond just because it doesn't know React, doesn't like a good choice, so knowing the time of the project if we can hire someone who will have some time to learn the stack can be a turning point, talk with you HR partner for more detail of the project.

Knowing the problems that the project is facing is also a good approach, then you can drive your questions to collect information on how to solve this kind of problem.

Information is power, keep that in mind.

Time of Interview

This is a peculiar topic, we may face interviews that 30 minutes may be enough, and others that may take 2 hours.

Every level may have an interval of time to deal with the interview, and this really on how the interview is split.

In a 1:30m interview, we may split it like this:

1. 5m to presentations
2. 10 ~ 15 minutes for the candidate to talk about himself and about previous experiences.
3. 20 minutes for tech questions.
4. 30 ~ 40 minutes for exercises ( we will talk in a bit ).
5. 10 minutes for feedback and questions.

This is just a sample you may adapt to reduce or increase the time as you like and adjust the steps as you wish.

Questions

Let's fly through this topic because it's not a big deal.
Focus your questions mainly on how you solved this problem that you face in company X, or why you chose this teck stack in company Y.
Now it's time to dry out our candidate on relevant questions about tech, previous experiences, and problem-solving.

Don't waste your time asking questions like What is the difference between Framework A x B, or Can you tell me how to make a binary tree algorithm?

Use this time to make real-world questions, based on actual problems to understand how our candidate thinks and solves the problems, this is the most important thing, don't really have too much in questions that you can find the answer to in Google, is better to have someone who can solve problems than a good copy paster.

Exercise

Almost every company has this fearful step on an interview, the live code/code challenge.

To be honest they are both equally bad.

On code challenges, you have to create a small platform with several things in 2 days, and sacrifice your free time to run this hackathon using top-notch tech in order to cause a good impression, for free, just to be judged by your code right? then what blocks you to copy paste from the net or call a friend to help in this process, so what is the point to send a challenge to be done in 2 days what are the points you want to raise from this? quality? speed? knowledge?

On live codes the idea is even worst, you are already nervous enough and then bang, you have to share your screen to make a palindrome algorithm or some hacker rank exercise, on what purpose? reversing a string? finding the 0 on the array? break a string to manipulate parameters on a request?
honestly? this may not be the best idea.

I know these are unpopular opinions.

But why not a whiteboard?
we can challenge our candidate on a whiteboard, presenting a problem and asking him how he solved this one, no code, only an architectural discussion on how to handle services integrations, you can deep-dive into tech knowledge without writing a single line of code.

Draw a mock interface and start making questions on, how you solve a performance problem on a huge table, how you can handle themes on a complex platform, and how you structure a white-label app or an imagination exercise like how Uber organize their services to run their application, let's draw the architecture together and understand how the candidate thinks and solve problems.

In the end, it's just a feeling that will move your yes/no.

QA

For the last, you may be open to questions, always have some interesting information about the project, and remember it's always a trade, you want the candidate but the candidate also needs to want to work here.

I know looks stupid, he applied for the position, and pass through the interview, how in the world he may fold this?

Sometimes it’s about the contract conditions, this one we can't solve.
Sometimes it’s about the energy the interviewer transmits.

Smile, be nice, and remember you have already been in this position and you know is hard to do it.

Being an interviewer is not rocket science, it’s a journey, you get better every time you do, write down your mistakes, improve your questions, change the process, reduce and increase time, and try to refine as much as possible the process in the order to achieve a satisfactory result.

There is no such thing as a magical formula for the perfect interview.

Grab these tips, mix them with your thoughts, and share them with your company mates hiring process should be collaborative.