Diving into the Technical Evaluations: Different formats you’ll encounter in your job search as a software developer

The longer your job search drags on, the more you’ll be exposed to different variations of technical evaluations offered by companies. Here are some of the different formats I’ve encountered as well as some tips & resources to prepare for them

There are countless of companies out there looking for new team members to join there team. However, while there are ample opportunities for job seekers like me, it also creates a frustrating process in having our technical skills evaluated by prospective employers.

Never before have I ever encountered such a varying process. Every company has their own process in evaluating applicants and believe their process should be the standard in the industry. However, some companies admittedly say their process is broken, but say that it’s just how it is & the standard way in weeding applicants out.

I get it. If I was on the other end & I was receiving hundreds (even thousands) of applicants, we need a way to narrow that number down quickly. If I was part of a smaller company, perhaps the technical evaluation would be a bit more involved, but it would similarly weed out applicants as we look to hire the perfect candidate that has the personality & skillset to join our team.

But I’m not on the other end — at least not yet. And it’s frustrating to not know what to expect at each company. When you don’t know what to expect, it’s also difficult to prepare for these evaluations as anything can be thrown at you. There’s no standard test with a list of potential questions that it could ask (well not exactly — we’ll get to that in a bit).

As a job seeker (and many others in a similar position as I), it’s frustrating and demoralizing when you encounter something during the evaluation that you’ve never encountered or studied. All that preparation, hours spent honing your craft goes down the drain for that specific evaluation, and you’re deemed too junior by the evaluators and they move on to other applicants.

After about 7 months on the job hunt, that’s unfortunately how I feel. Have I improved? Am I focusing on the wrong areas? Why do I keep failing at the same steps?

It’s a constant feeling that we must all deal with & conquer, and the best thing we can do is push forward, keep failing, and hope for the best in our next attempt. The stars must align at some point, right?

But enough of my rant — as I mentioned, this is the reality that developers must face. We must play this game and the best thing we can do is prepare to the best of our abilities.

Here are some of the formats I’ve encountered (and failed) this past year:

Take Home Assessment

Here is a traditional approach that companies take to weed out applicants. You’ll likely encounter a take home screening from larger companies and more established tech startups and it generally arrives via email even before you make any contact with someone at the company. In other words, it typically comes right after you apply.

In my opinion, this is the least forgiving of all the options. You’re going up against the clock and the computer. A standard format I’ve seen is a 3 question test and a 90 minute time limit, but I’ve also encountered different variations that had more & less questions asked and time given.

It’s challenging because there is no human feedback. If you’re stuck…well, time to dig into your bag of tricks and see if you can pull something out. There are typically about 10–20 test cases you’ll need to pass in order to get full marks for each question.

Evaluators will look at the efficiency of your solution (time & space complexity) as well as the quality of your code (Is your code clean? How’s your naming convention? Is it easily understood?). My guess is they’ll skip this part if your score doesn’t reach a certain benchmark as they have many challenges to evaluate, but that’s just a theory of mine.

Some of the popular platforms I’ve seen used are Codility (www.codility.com) and HackerRank (www.hackerrank.com).

How to prepare?

There’s no other way to put this — repetition. It takes time, but the more questions you attempt & solve, you’re that much closer in unlocking that logical problem solving side of your brain. Leetcode (www.leetcode.com) and CodeWars (www.codewars.com) are great resources to get your repetition in.

Everyone operates a bit differently, but my recommendation is to come up with your own approach. Try not to start coding immediately, but instead take 5–10 minutes to think & write down the steps you’ll take in solving the problem. Chances are you may not know how to solve the problem right after the bat — taking a step back and laying out a game plan could help you get closer to a solution that you may not have thought of initially.

If not, well, at least we have some partial work to show our evaluators :).

For some examples, I recommend reading some of my other blogs that uses this approach.

Live Coding Challenge

Ah, the dreaded live code challenge. You’ll most likely encounter this after a HR screen with a hiring manager or a recruiter from the company. You impressed them enough with your personality, your projects, etc. to make it to this round. It means that they believe your personality is a good fit for their team.

But what about your technical skills? Well, you’ve made it far enough where they’ll invest the time & resources to test your abilities. Typically, you’ll be assigned an engineer (or two) and they’ll sit with your for 30–45 minutes.

The first 5–10 minutes will be quick introductions, but then after you get right into the meat of the interview. It’ll typically be just one question (at least in my experience, but then again, maybe’s it’s because I haven’t gotten past that stage).

Make sure to involve your interviewer & ask clarifying questions off the bat. Even if you believe you understand what the question is asking, I would still recommend asking questions (clarify on the different types of inputs you’ll be working with, the expected output, any edge cases, etc.).

As for the actual solving of the problem, make sure to take the same approach as you would with the take home assessments and lay out the road map to show the evaluator that you’re grasping the question asked (and for the evaluator to make sure you understand the question completely). If you need hints to help you solve the problem, make sure to do so as your absolute last resort as it could count against you.

The last 5–10 minutes you’ll be given the opportunity to ask questions. This would be a great time to ask about the working dynamic within the engineering department as well as receive feedback from your performance.

How to prepare?

In addition to repetition on questions such as Leetcode, CodeWars, etc., make sure to get comfortable with voicing your approach. A great website is Pramp (www.pramp.com) which will match you with other users and give you the opportunity to interview each other for 30 minutes. Each person will be given a problem to solve prior to the scheduled session, and you’ll be responsible for asking that specific question to your partner. The environment is to mimic an actual live technical evaluation.

In addition, I recommend asking your friends to help you with mock interviews. Dig into your friend pool and see if you know any software engineers who interview for their own companies. If not, have a non-technical friend sit with you while you solve a problem and have them give you feedback with your communication skills. Although they may not know what the question asks, a lot can be said about the way you convey your thoughts!

Take Home Project

Although this evaluation will certainly take up the most of your time, I also believe it’s the best approach in terms of evaluating one’s skill.

Similar to the live code challenge, you’ll typically receive a take home project after some sort of HR screen (however, I’ve also been given a project right off the bat). I’ve usually been given a week to complete my take home projects, but I’ve also heard of some due dates in 24–48 hours.

In my experience, I’ve been given tasks to re-create the UI of a website, connect with an API & set up time interval responses, and work with a mass amount of data & create different view pages for certain data.

It’s tough, but you also aren’t faced with the stress of a timed environment or a interviewer staring into your soul as you struggle with solving a problem.

After completing it, you either submit it for the team to review or you’ll be given an opportunity to meet with the team to talk about your approach with the project. I like the latter approach.

How to prepare?

This is where your practical knowledge comes into play. With all the algorithm practice, it’s easy to neglect your project building skills. Make sure you always have a side project you’re working on, or learning a new technology that you could potentially integrate into your project.

Other Technical Evaluation formats

While less common, I’ve also encountered the following type of technical evaluation formats:

Building a feature for the company

Similar to the take home project, but with this evaluation you’ll actually be building a feature for the company (with the company compensating you for the time). This type of evaluation may be more common with very small start ups and teams.

I’m a big fan of this approach. Not only will your technical skills be tested, but it also gives you an opportunity to see how the company operates and whether you could see yourself working alongside them. In addition, the company can go a bit deeper in their evaluation of your personality and see whether you’re fit for their growing team — it’s a win win scenario!

Technical discussion about a past problem the company solved

This one was interesting and was for a back-end role I applied for. Essentially, there was no coding involved, only a discussion over a past problem that the company had faced and ultimately solved.

After presenting the problem, the interviewers would then put the ball in your court and ask how you would approach in addressing the issues. It’s a lot of back & forth, and they encourage you to ask clarifying questions along the way. As you get deeper & deeper into the issue, they’ll introduce new layers that you’ll have to address, making your solution more complex.

I enjoyed my experience with this one because I enjoy talking more than actual coding :). Joking aside, you feel like a part of the team in the planning phase.

At the end of the interview, the evaluators will then share how they addressed the issue themselves.

Conclusion

After approximately 7 months, these have been the types of formats that I’ve encountered as a software developer job seeker. As you can see, there’s a lot, and most likely many more as companies find what works for them and what doesn’t.

I hope this article helps you gain a better understanding on what a technical evaluation would look like. If you have encountered something different, comment below and definitely share with the rest of us!

Until next time.