The Common Types of Technical Tests

Let's explore common types of technical tests, how you can prepare for them and the pros and cons of each one.

Technical tests do not need to be scary.

A lot of candidates I’ve spoken to feel anxious about the technical test stage, there are so many unknowns and they feel unprepared. But I’m here to tell you, it doesn’t need to be this way.

You can learn and understand common types of technical tests, and put your focus into improving your skills, so that when you get to the technical test stage, they are no longer scary.

In today’s blog post and YouTube video, we will be going into detail on the common types of technical tests that you’re likely to encounter, why they are used, and what the pros and cons of these tests will be.

Disclaimer: This article doesn’t cover all types of technical tests, it covers common ones I and others have encountered in the UK. This may differ depending on your location.

---

1. The DSA Filter

This technical test is typically done as part of a screening process to filter out applicants. You will commonly get questions that focus on data structures and algorithms. Common ones include arrays, hash maps, stacks, queues, linked lists, BFS (Breadth-First-Search), DFS (Depth-First-Search).

This type of technical test is commonly done to assess a baseline level of skill for data structures and algorithms, as well as filtering out applicants when there is a high volume of candidates.

Pros:

• Typically 1-2 hours long, meaning that the candidates don’t have to spend a lot of time on the test itself

• Easy to ‘objectively’ mark from an interviewers perspective as it provides a standardised way to evaluate candidates

• Can be given and graded in an automated way, saving companies a lot of time

Cons:

• Requires lots of practice on things seemingly unrelated to day-to-day software engineering

• Can negatively impact candidates who have performance anxiety

• Doesn’t assess a candidates ability to deliver functional real-world requirements

For companies that are delivering this approach, I find trying to make the questions simulate a real world use case or making the test interactive can be helpful. Advent of Code, for example, is an excellent way of making DSA fun instead of scary.

---

2. The Take Home

You will be briefed on a requirement you need to fill. Typically you will be asked to create a front-end or an API, or even something simple like creating a calculator as a console application. They will usually ask you to complete this test within a couple of hours, or up-to the end of the week. In this interview they are typically looking for code quality, testing and business understanding skills.

Pros:

• You have time to digest and reflect on the requirements

• You are able to work in a way you would typically work

• You have the chance to showcase your skills and knowledge

Cons:

• You could theoretically cheat the test by getting another person to do it

• These tests could easily take hours, if not days, if you aren’t careful

• Difficult to objectively grade from an interviewer’s perspective

For companies that are doing this approach, I would suggest to provide a deadline or timebox for the exercise and to try and focus on a couple of core requirements, rather than a full blown feature.

---

3. The Pair Programming Exercise

Similarly to the take home test, you will be briefed on a requirement and asked to fulfil it. The difference here is that you have to fulfil the requirement with someone working alongside and guiding you, typically a senior or lead, in a time-boxed manner.

This is usually done to assess the way you approach work and to see if you would enjoy working the way the company works.

Pros:

• You have the chance and opportunity to learn from skilled engineers

• It’s timeboxed so you don’t run the risk of going down a rabbit hole

• Is a chance to showcase your thought process for delivering a requirement

Cons:

• This approach typically isn’t inclusive of those who struggle with social anxiety or are introverted, as pair programming with someone who they haven’t met before isn’t the same as with a peer

• Requires skilled interviewers to calm interviewee’s nerves

I would encourage companies that are using this approach to give a brief overview of the requirement that you’re going to ask them to deliver before the interview. This gives the interviewee a chance to digest the information and formulate a plan.

One thing to take note for interviewees, if pair programming isn’t something you typically enjoy, ask yourself whether a company that predominantly works that way is the right thing for you?

---

4. The Prompt

The prompter will use your experiences on your CV and from the conversation to try and gauge your level of skill. For example, they might ask to explain when you've built a product before, how did you get started, did you add tests, what libraries did you use, did you find any issues with those libraries etc.

This is all about understanding your experiences to see whether or not you have the appropriate evidence to suggest you are capable of doing the role in question.

Pros:

• Typically 1 hour or less in length

• Little preparation is needed as it’s all about understanding your previous experience, which is hard to fabricate

• A chance to hone in on what makes you unique and what value you can bring to a business

Cons:

• Doesn’t work well for junior candidates who haven’t yet had the years of experience to discuss

• If the interviewer isn’t very good at prompting, then it can quickly turn lead to awkward silences and an uncomfortable interview

• Interviewers have to be careful not to let any biases get in the way, as they could easily favour candidates who work more like they do

For companies, to caveated bias the best way is to identify three key areas that they find is vital for the role that they want to test candidates about, and focus on finding evidence for those three key areas. Focus on not getting caught up in conversation about a specific area, once you have validated (or not) someone’s experience, move onto the next area.

---

5. The Whiteboard

You will be typically asked to either design a solution or to solve a problem and asked to sketch out your approach on a whiteboard. You may be asked to draw diagrams that showcase your thinking or write pseudocode. This is commonly done to assess the way you think and whether or not you have architecture thinking.

Pros:

• Typically 1 hour or less in length

• Works well for those who have a lot of experience with systems design, as it’s a very natural way to showcase architecture thinking

• Allows interviewers to see how individuals think and put their ideas to fruition

Cons:

• Typically favours extroverted people who are comfortable presenting their work to those they don’t know

• Not a typical way of working for many candidates, so it may be more focusing on their presenting skills, rather than their coding skills

• Writing pseudocode on a whiteboard? Meh.

For companies, if this is your preferred way of testing, it might be beneficial to brief the candidate beforehand what you are likely to be asking them. This can help calm their nerves and be their best possible selves during the interview.

---

6. The Exam

You will be given a series of questions, some multiple choice and some plain text on various programming topics, usually related to the languages they use. This is typically done to assess the level of skill you have on the languages they work with. It’s often also used as a way of filtering out candidates who don’t have the skills they are looking for.

Pros:

• Similarly to the first test type, it’s typically 1-2 hours long, meaning that the candidates don’t have to spend a lot of time on the test itself

• Again, easy to ‘objectively’ mark from an interviewers perspective as it provides a standardised way to evaluate candidates

• Again, it can be given and graded in an automated way, saving companies a lot of time

Cons:

• Can favour those from an academic background, than those who have come from vocational routes

• Can sometimes focus too much on the technical stack, rather than the core skills and competency. Depending on what the company are wanting depends on whether or not this is a bad thing

• Easy to cheat if not done in an exam setting

With tests like these, I would always ask the company “what are you trying to achieve?” In my opinion these are probably one of the easiest types of tests to cheat and give the least indication on the person’s ability of whether or not they can do the role.

---

Final thoughts…

For companies, whilst many of these types of technical tests are valid, it’s important to be aware of the potential drawbacks of each one and determine whether or not that is something you and your company are okay with. I can understand why certain ones are used over the other if you are looking for a specific skill set, but generally I think providing a couple of options isn’t a bad thing, and gives the ability to work to the candidates preferences.

For candidates, if you do badly on one type of technical test, don’t beat yourself up about it. Remember we all work in our own unique way and the way you work just might not agree with that test style. Don’t let this get to you, and remember that each opportunity is a new chance to learn something new.

I’m keen to know of any other common technical tests other’s are familiar with, please share them in the comments section!

If you want to learn more, listen to my latest video which discusses these topics in more detail: