A Practical Guide to Technical Tests (For Junior Devs): Part I

Photo by Chris Ried on Unsplash

Let’s set the stage: you’re a junior developer looking for work. You spend a lot of time applying for jobs, building a portfolio, working on side projects and going to networking events. You pass some initial phone screenings, make it through a few culture fit interviews and then comes the real challenge… the technical test.

We have all been there, in the awkward and often intimidating position of having to show off our technical knowledge to a room of strangers so they will consider giving us a job. Needless to say, the whole process can be stressful.

Technical interviews can take many forms and are often designed to expose the true extent of a candidates skill and knowledge. Sometimes the test is administered on a laptop in quiet room with a familiar code editor like VS code or Sublime. In other cases the interviewer might log you into an online platform that is specifically used for technical testing and records your every keystroke. Not uncommonly, they may write out questions on a white board and have you solve them with a dry erase marker.

I even had one interviewer get me to solve a problem with nothing more than a pencil and a blank piece of paper. Freaked me right out…

Regardless of the medium, at some point you have to prove that you can work through problems in code. Sometimes you can get away with solving a problem in pseudo-code if you don’t know the programming language used by your prospective employer. The rationale that is often given for this option is that interviewers really want to assess a junior’s ability to think rather than their proficiency with a specific language or framework. This brings us to our first and perhaps most important point:

You must be able to show (and verbally communicate) your ability to break down a technical problem and solve it in a programmatic way.

This may seem like an obvious point that has been beaten to death by blog posts, articles and books for decades, but this little nugget of wisdom remains true to this day. The secrets to achieving this goal aren’t so secret, in fact, they are obvious and painfully straightforward.

Photo by Tim Gouw on Unsplash

1) You can’t show a skill or communicate an idea you don’t have.

• Technical tests have a tendency to break you down and expose what you know about a specific topic and what you don’t .
• If you can’t answer a question, you have more to learn. Nothing to be embarrassed about, admit the gap in your knowledge and add it to your list of topics to study.

2) If you don’t have a good grasp on the basics of programming you will struggle to break down problems into their logical components.

• Without an understanding of the basic operations (change a string into an array, find a specific piece of data in an object, etc.) used by most programming languages things are going to get rough, fast.

3) It’s unlikely that you will find an efficient solution to a given problem unless you have taken the time to learn about common algorithms and coding patterns beforehand.

• Your technical test experience will be so much better if you have at least a general understanding of how common algorithms and code patterns are implemented in at least one programming language.
• If your first encounter with a Depth-First Search function happens during a technical test (this might have happened to me…), it can not only be difficult to find a solution under pressure, it’s unlikely that your answer will be optimised or robust enough to deal with limit cases.

The Bigger Picture

It’s easy to get overwhelmed and drown in the multitude of topics that you have to know as a junior developer. It’s also easy to focus on skills and technologies that give you immediate feedback. This often happens when developers start working with Front-End frameworks like React, where results are plastered onto the screen in front of them every time they save a new line of code. While this is an important part of progressing, this skill set is a lot easier to cultivate and doesn’t get to the root of what technical tests are really about.

Photo by NASA on Unsplash

Here is a simple example to illustrate my point. If you are given the following instructions and asked to implement them using a framework of your choice, could you do it?

* The instructions are vague on purpose, as interviewers will often expect candidates to ask clarification questions that show their understanding of the problem and its common hurdles.

• take an input
• loop through an array of objects
• compare the key of each object to the given input
• if there is a match, return the corresponding value

My bet is that most junior developers could implement these steps with relative ease. Moreover, you would see some pretty common patterns that are widely used by developers in each framework community.

You might see a for loop, .map() or .filter() function if you are coding in JavasScript, and depending on the input you might need to convert a string into an integer (or vice versa). There are a lot of variations that might be thrown at you, and the crux of most interviews lies in how you are able to deal with those variations and solve the problem as efficiently as possible.

This is the point! By having a better grasp of the details behind a programming language and its patterns, you can produce better code. You can pivot on the spot in an interview and offer a better solution. You will be able to break down something that looks complex into parts that you have seen before and can ultimately solve.

So What Now?

Photo by Olesya Grichina on Unsplash

So you’re probably thinking:

Great. We get it Tom, learn more, study Comp-Sci, use LeetCode…

Don’t worry I’m not gonna leave you hanging in the wind without an actual path forward. In Part II, I layout a straightforward process that will help you determine which foundations will maximize your learning and how to apply this new found knowledge in a real world technical test.