Ace your next software interview

Introduction

I’ve flunked software interviews more times than I can count with just two hands. The worst experience was when I got so embarrassed that I apologized and left midway through that interview.

It took me three years to finally find the answer to the technical question asked during that interview. Three years of gaining experience, working diligently every day. And when I asked some very senior colleagues the same question none of them could get it.

This is when I realized that having a bad interview isn’t always on you, sometimes your interviewers can throw you an impossible question as a junior as a way of messing you up. But let’s take a look at a few ways to avoid falling into the pit of regret.

Practice the fundamentals

Working with React for the past few years now, I’ve had the chance to do a lot of technical interviews with some very senior people, and one common trait that makes me say no to a candidate is that they don’t know the fundamentals of Javascript.

I’d ask them, what’s a closure, what is scope, they wouldn’t be able to tell me, and yet they know the in’s and out’s of react hooks. Without understanding that under the hood hooks are simple scoped functions that return a state scoped to that function.

Have solid examples

This is one that you will come across time and time again, one question that is always asked in most interviews “What was your biggest mistake” and then people think, and then they make stuff up. Don’t do this. Your biggest mistake isn’t something that you need to be ashamed of.

This question is there to test your capacity for calm reaction, learning from your mistakes and seeing if you’re the type of person who will try to pass blame onto someone else. Mistakes happen, fix it, learn it and forget about it. But do not make this up.

It doesn’t have to be anything major, it can be something like “I used a rusty razor to shave my beard and now I’m bleeding”. The calm reaction, apply tissue, the learning, buy new blades, blame… yourself for not looking after your shaving equipment.

Practice, Practice, Practice

Where?

  • Leet code
  • Codewars
  • A notepad
  • Your own brain

There are a lof of places to practice.

Code something and practice. If you’re having trouble understanding a concept go code something with it and learn how it’s working.

Show ownership

This can be a college project, school project, home cooking project, showing that you decided to do something and you owned something that made a difference to someone. Ownership is one of the most impressive qualities that a candidate can show as it shows that they are willing to do the work.

Be coachable

This mainly tends to be an issue with more senior candidates, in your current position you’re probably the “creme dela creme” on that project. This won’t be the case in a new company so never come in with the attitude of, “oh this is easy I can pick this up no issue”.

This is going to make the interviewer think that you’re just going to come in, not listen to instructions, not allow yourself to be taught how things are done at your new company and as a result, break something in production.

Be collaborative

This is something that everyone loves to see, how did you collaborate with your past colleagues? but also, how did you argue with them? How did you get your co-workers to agree to things that probably not everyone agreed with? When I say be collaborative I don’t mean go with the flow for the sake, I mean show how you have tried to make the best product even if it meant having disagreements.

Research the company

Many companies are going to have a ton of data online about them, probably even the interview questions. You should try to find out as much as you can.

Explain your solutions

Researching the company and its questions can be a double edged sword, if you do find the technical tasks, be prepared to go deeper than just the answer. Be able to explain how it works, why it works, and what the complexity of it is. Never stop with the answer, always consider the edge cases and how to potentially solve for them.

Code out loud

When I’m interviewing a candidate the worst thing that happens is the candidate goes quiet. An interviewer will want to know what you’re thinking, they want to know how you got to a solution and they want to know why you’re going for that solution.

This way even if you provide a really ugly answer, that works, is fast, that solves for all use cases an interviewer can see why you did it this way and you’ll get the marks.

Realise it’s not personal

In the vast majority of interviews I’ve done I’ve had a scoring sheet. It’s not about what I think about you as a person, it’s sometimes just how you do on the technical assessments. This means that this can be standardized across the board and ensure that all candidates are treated the same and scored at the same level.

Conclusions

Even with these tips we’re only scratching the surface of the multitude of things that can go right or wrong for you during an interview process. Not all interviews are going to be the same but with practice, preparation and confidence you can make them go a little bit better.

If you’re worrying about an upcoming interview you can book 1:1 interviewing preparation session here.