The Technical Interview

 

You’ve passed the coding challenge; congratulations! Now, the next step is often a technical interview.

 

The technical interview is unlike any other interviewing stage. It aims to test not only your coding skills but your problem-solving abilities and also your personality. Now I know a technical interviewing process displays a fair amount of challenges already - of course, there is the coding challenge, live whiteboard challenges, potentially a logical test, and sometimes even hours of cultural fit meetings. On some occasions, just when you thought it was complete, there is then one last bar raiser. The technical interview can be intimidating, but to ease your nerves, here’s what to expect:

 

The Technical Interview -  what is it?

 

Unlike any other meeting, the technical interview creates that exam feeling I know most dread. Why is it needed? Well, it’s a chance to show the interviewer your technical skills, rather than just telling them; a chance to speak through your code and tell the interviewer why you did what you did. 

 

Although it may feel like it involves questions that are simply impossible to solve, I can assure you that it does not. It’s not used to test you, rather to see how you will perform in real-life situations, those you will be faced with within the actual job. It’s used to examine your thought process in approaching certain situations, and how well you can communicate this. Companies are merely looking for how well you explain and analyse a given problem. 

 

Your Coding Challenge:

 

In most technical interviews, you will be going through your coding challenge result with the interviewer. As I mentioned, this stage of the process is for you to show your technical skills further. It’s a chance for you to explain your code and explain your thought process when you completed the challenge. 

 

The interviewer may ask why you solved a given part of the problem the way you did, so make sure you refresh your memory on what you did. Go over it in more detail and think about what the interviewer may ask. 

 

Alternatively, think about what improvements you would make looking back at it. What would you include that you did not include before? For example, you may have wanted to include more tests or focussed more on the UI of the application. 

 

Of course, it depends on the task itself. The main thing, however, is to think about it in more detail before the interview.

 

The Whiteboard Challenge:

 

Whilst not too common in start-ups, bigger companies may want to test your technical skills further in a live whiteboard challenge. Before you start, as I discussed in my previous post on how to ace the coding challenge (do check it out if you have not already), read the instructions carefully and ask any questions if you are not too sure. This will ensure you fully understand the task at hand. You may even be able to get a few hints, and who doesn’t love a hint!

 

The whiteboard challenge may involve pair programming, so speak through your code and thought process. This exercise is used to see if you can solve a given problem and how you solve it. It’s often used to test your communication and problem-solving abilities. Some may even argue the solution is not important at all; rather, what the interviewer wants to see is how you get to the end result. How do you articulate your thoughts? Are they providing an accurate answer to the questions? This is what the interviewer will be asking themself. 

 

The Importance of Communication:

 

Communication is key here. Often, in high-pressure situations, it is normal to feel flustered and speak very fast. I am the Queen of this! 

 

As I said, it is normal, so don’t panic if this does happen. However, take a few moments to gather your thoughts before you speak. Try to be as clear as possible. This will keep you on track and calm. 

 

Listen to what the interviewer is asking and prepare your answer before speaking. This will also make sure you don’t waffle in a state of panic (again, very normal) and get straight into the answer. 

 

For this, I’d say to try to avoid ambiguous words. Use language that expresses clarity to your answer showing them you know what you are talking about. This will emphasise the technical depth of your knowledge. 

 

Contrary to this, I’d advise against using those big technical words you do not know the meaning of. Don’t just use such language for the sake of it. You would be much better off using a key and simple vocabulary that explains your thought process clearly.

 

The Next Steps:

 

It’s done; you can breathe a sigh of relief now. Whilst natural to start analysing what went wrong and what you could have done differently, the best thing you can do is simply relax. The waiting game now begins…

 

At this stage, manage your expectations, as you may receive some rejections. Again, this is normal. Each company looks for different things, so what did not go so well in this process, maybe what another company is looking for. Try not to get too emotionally attached to a company’s process and do not view rejection as a personal judgment of your technical ability. 

 

As I said, each company has different requirements. Often, a technical interview is not just for you to show the interviewer your technical skills, but a test against your thought process and how this will fit in with their current engineering team. Essentially, it is a social test. Each team is different and therefore would work differently and expect a specific way of working from any future team members.

 

Whether the outcome is good or bad, look at any experience as a mock or practice run. Take this experience and learn from it. If this was your first technical interview, now you know what to expect and how to better prepare yourself for the next one. 

 

I always tell any engineer I am working with, whether the feedback is good or bad, to take it on board. Being able to take constructive criticism well is an important skill to have in any career.

 

Being able to take constructive criticism is important. As I said, each company will look for different skills, so do not take one rejection as an attack against your technical ability. It simply means you were not the best fit for this one position. As they say, as one door closes, another one opens.