Technical interview tips: From assignments to finishing the interview

There are a few important technical interview tips we want to share with you. This is a rather extensive topic and we need to cover a lot of aspects. So without further ado, here is a list of technical interview tips you should always bear in mind when conducting such an interview.

Conversational style

One of the very common things that happen during the interview is that the interviewer simply starts throwing question after question at the candidate. Now, of course you must ask questions. You need to assess the candidate’s level of knowledge after all. But you also need to be aware of how you do this. If you go too far, the interview can look like an interrogation. And this can be a very unpleasant experience for the candidate. 

I have always believed that the best technical interviews took the form of conversation. It’s not only about asking the questions, but also giving the candidate room to explain their reasoning (and that is also something that’s being assessed!). Such conversations will open additional discussion topics and can provide insight into specific areas of the candidate’s knowledge (or in some cases, raise red flags) – something that you might not be able to do otherwise. Not only that, but the dialogue between you and the candidate can make them feel more relaxed. And that can have an impact on the answers they provide. 

So, to help you be on the right track, here are a few technical interview tips when it comes to the conversational style:

Aim for conversation with occasional bursts of questions

If possible, this is the ideal scenario. This usually means that when a particular topic is mentioned, you focus on it and dig as deep as possible

Let the candidate explain things 

You want to assess the way they think about various topics. Open-ended questions might be a good way to accomplish this (and you will have more opportunities to ask questions)

Take breaks

If the interview is long (or the discussion is heated) – make sure to take regular breaks.

Aim to be more human 

Do your best to not appear merciless or artificial during the technical interview.

Coding assignments

Coding assignments are a major part of the hiring process. They are also a very controversial topic, because there’s a lot of different opinions on coding assignments. In general, there are three main types of coding assignments:

Live coding session

Live coding session is a type of assignment where the candidate works on a problem (or several smaller problems) as part of his on-site interview. This can take anywhere from 45 minutes to several hours (depending on the complexity of the task).

Take-home assignment

This is a task in which the candidate works on a predefined coding assignment in their spare time but must submit the final solution before the deadline. The deadline is always previously discussed.

Online coding quiz

An assignment where the candidate needs to solve a series of coding problems using one of many specialised tools that provide quick feedback regarding their solution.

Assignment challenges and how to overcome them

Every single one of these options has some issues – in fact, people argue about them most of the time. Some people hate all of these. Because of that, some companies offer multiple types of assignments, and some companies have no assignment at all. I have even seen online resources that provide lists of companies that don’t have them. 

One thing is obvious: people have very strong opinions on this topic. And there might be some very good reasons for that). Let’s briefly discuss potential issues with each of the assignment types and then we will give you some important technical interview tips.

Live coding assignment challenges

For live coding sessions, the main issue is usually the pressure. The time constraints, the presence of the interviewers (especially if a live coding session involves pair programming), the general feeling of unease that can be present during the interview – all these factors put the candidate under a lot of stress. Also, these are not the normal working conditions. So you should take that into account when you need to pass judgement on someone else’s coding skills. Not to mention that the attitude of the interviewer can also have an impact on this type of assignment.

Take home assignment challenges

Take-home assignments are disliked because a lot of people don’t enjoy working on something like that in their spare time. Some even see this as a sign that the company does not respect their time. Also, some companies tried to use take-home assignments to get some free work done. So some candidates became suspicious whenever the hiring process required something like that. But there is the other side of the story as well – the interviewers are often afraid that the candidate will submit a solution that wasn’t written by them or will simply have someone to help them with the assignment.

Other challenges

There is one more problem with many coding assignments regardless of their type – that they do not reflect the reality of the job itself. Sometimes, they are completely disconnected from the job or way too complex. If you are building microservices that expose REST APIs and use relational databases or message queues – there is very little point in giving a candidate the task of building a small video game. Sure, you will learn something from that example, but you want to be able to gather as much information as possible before deciding on a candidate. And that information needs to be relevant (and indicate whether the candidate can do the job or not). 

You can also lose the candidate, because some of them will also wonder how this assignment is relevant for the position they are applying for. So, if you really want to do something like that, you better be ready to explain the motivation behind giving such an assignment and why you think it is relevant. The same is true for just copying the assignments or coding challenges that other (usually very popular) companies are using. Just don’t do it.

Possible solutions

Ideally, you will offer the candidates several options and they can choose the one that they prefer the most – for example, live coding session or take-home assignment. Alternatively, you could instead provide the option of refactoring assignment. This means that you show the candidate a working code sample – but a badly written one – and then discuss with them the ways to improve it, maybe even implement some small changes on the spot. This type of assignment can be a bit less daunting for the candidate because they do not need to submit a fully working solution.

At Neon, we use take-home assignments, and we had a lot of success with them. For take-home assignment to function properly, a few requirements must be met:

• The assignment needs be relatively small (should take a few hours to solve at most) and very clear in scope
• It needs to be related to day-to-day work
• The assignment needs to allow the candidate to show some extra skills (at Neon, this is mandatory for senior positions and clearly communicated to the candidates. They can enhance the solution however they see fit, but they must add something)
• The candidate should have a lot more time than required and the possibility to extend the deadline
• The interviewers should have a clear list of expectations when it comes to assessing the assignment: what is mandatory, what is nice-to-have and what are pure flex points/extras
• Always have a discussion with the candidate after the take-home assignment (you can also let the candidate present the solution)

Knowing when to stop

There is one more important aspect of the interview that we haven’t discussed or shared technical interview tips – the flow of the interview or knowing when to “shift gears” and when to stop or take a break.

Let’s look at the following examples:

The candidate is a perfect fit

Sometimes, you simply know that you have found the perfect candidate. It is usually obvious when something like this happens. If that is the case and you think the candidate is answering all your questions with ease, you can either close the interview and proceed to the next step in the process, or you can pick one of the topics you discussed and try to assess the depth of his knowledge.

The interview is an utter disaster

This is the opposite of the previous case. Sometimes, the candidate will be so bad that you will very quickly realise that there is no point in asking any questions and it is very unlikely that the candidate’s answers will be any better as the interview goes on. It is OK to politely close the interview in such a case – this will make things easier for both you and the candidate.

The candidate needs a nudge

Sometimes, you have a good candidate, but they might get stuck with a specific question. If you feel this is the case, you should give them a small nudge to point them in the right direction. You can provide some additional information, ask if they would consider a different approach or discuss the solution together. You should always do this if you believe that that candidate has the potential (especially if everything up to that point was good) and you should not let the candidate stray too far because that can easily lead to an awkward situation. 

However, there is also a case where the candidate cannot answer any of the questions without you giving them a nudge or helping in some other way. Usually, this means that either the candidate doesn’t have the expected level of knowledge or that they have lost focus (because a lot of people don’t feel too comfortable during the interviews).

The candidate has lost focus

As previously stated, the interview can be a stressful experience. This can have a very big impact even on the best of candidates. If we add some external factors (for example, feeling tired) it’s easy to see why (otherwise promising) candidates might struggle to provide good answers. If you feel that this is the case and that the candidate is “stuck”, it’s OK to suggest taking a short break. You can maybe offer a glass of water if it is an interview in person. Or if you believe that the candidate is under a lot of stress, give the person some time to recover. This can be done by having a brief conversation about some interesting topic (some cool project that the candidate worked on, hobby, etc.).

Unfortunately, sometimes the candidate cannot recover because their focus is totally shattered. If that’s the case, the only option you have is to close the interview.

Conclusion

As you have seen from this 2-part article series, technical interviews are a complex topic. There are multiple approaches and people can hold very different opinions on what is the best approach. We tried to point out some of the common issues with technical interviews and provide technical interview tips on how to avoid them. 

However, remember that regardless of the approach that you choose, it is important to try to create an interview process that is best suited for your project and your company. Otherwise, you may end up with a process that will reduce your chances of detecting relevant skills. Also (in the extreme case) lead to losing the candidate altogether.

If you need help getting the right candidates for your project, get in touch with our team providing IT staffing services and let us do our magic.

---

Author

Miroslav Lazovic is an experienced software engineer from Belgrade. Over the past 15 years, he worked on many different projects of every size – from small applications to mission-critical services that are used by hundreds of thousands of users on a daily basis, both as a consultant or part of the development team.

Since 2016, he is focused on building and managing high-performing teams and helping people do their best work. He likes discussing various important engineering and management topics – and that’s the main reason for this blog. Besides that, Miroslav has quite a few war-stories to tell and probably far too many books and hobbies. There are also rumours of him being a proficient illustrator, but the origin of these rumours remains a mystery.

– Backend TL@Neon and Dev. Advocate @Holycode