Navigating interviews and technical challenges in software engineering

(Note: This picture is of a Vietnamese Pot Bellied Pig performing at the Colorado State Fair. Her name is Petunia Pancake. ❤❤❤)

Take-home coding tasks, whiteboard challenges, and technical interviews are all an inevitable part of getting hired as a developer. I’ve worked as a developer for 15 years, and have done quite a lot of these things from both sides of the table. I’ve collected a bunch of practical tips and ideas for how to best tackle these technical challenges, and how to cope when things don’t go so well.

When hiring developers people are scared. Even though your CV looks good, you have experience, and you come across as a sensible person when they talk to you when it comes down to it, they are scared you can’t actually do your job. They want to check you are very good at coding and also problem-solving. So what do they do?

They come up with technical tests designed to work out whether you can actually do a job or not(Whether they are successful at this or not, is a different matter).

If you apply for an engineering role, there’s a good chance you’ll need to complete one of these technical tests. During the course of your career, you’ll need to complete many.

The first technical test I did was in 2003 — it got me a pretty boring job making bespoke websites as a LAMP developer — and I’ve been working as a developer ever since. Thankfully I quickly moved on from my boring job, and since then I have no idea how many technical tests I’ve done, but it’s probably a lot.

I’ve also been on the other side, giving out technical tests. What do I mean by “technical tests”? Well, let’s look at some examples:

• Take home coding challenge

This is when you are given a coding challenge to complete at home. Usually, you’re given a document describing the problem and what’s expected of you. You then write and return your code, which is reviewed. Sometimes, (but not always), the reviewer then discusses your code with you. It’s useful to know that sometimes the discussion about the code is as important as the code itself.

• Technical quizzes

This involves the interviewer asking you a series of questions with factual answers. Like you’re in a quiz. For example: “what’s the performance of looking up elements from a hashmap vs. a linked list?”, “what’s the difference between final, finally, and finalize in Java?”

• Whiteboard challenge

A whiteboard challenge is where your interviewer describes a fairly chunky problem to solve and tell you to explain a solution on a whiteboard. Your interviewer is there to discuss the problem with you, give you hints, and sound out ideas as you go along. Usually, on the whiteboard itself, you are producing bits of code and diagrams.

• “Pair programming” challenge

For these, you sit at a computer with the interviewer next to you and able to see your screen. They then describe a problem to solve, as they would for a whiteboard challenge. You then solve it by writing code on the computer. It’s kind of like whiteboard challenge, only with a computer instead of a whiteboard — your interviewer is there to discuss things with.

• Technical interviews — conversation style

This is where you interviewer aims to get you to demonstrate your technical knowledge by attempting to draw it out of you as part of a conversation. For example they may ask “I see you’ve done X with technology Y, what would you do if you could make that decision again?” and hope that you start demonstrating your knowledge of technology Y, and its competitors. They’re kind of a blend between a classic interview, and technical test as they’re trying to get more information out of you than just your technical knowledge.

In preparation for this post I asked my fellow Pusherinos about their tech interview horror stories. It turns out a lot of their stories involved simple things like being hungry, or tired, or hungover.

Some common sense tips about interviews. Make sure you:

• Have time — don’t schedule interviews so that you have to rush from place to place, you won’t be in the right frame of mind.
• Eat — hunger stops you from thinking.
• Clean yourself up — sweating seems to come up a lot in horror stories, a well-planned outfit, or wet wipes and deodorant in your bag could be a saviour.
• Are prepared — make sure you know what sort of interview you’re about to have, and how long it should last. Ask questions beforehand if things aren’t clear.
• Sleep — being tired stops you thinking.
• Are not hungover — hungover people don’t tend to interview well.

My next set of tips are about the emotions involved in doing technical tests. The emotions involved in these can be pretty tricky:

• Going into an interview with a negative frame of mind won’t help you. If you find yourself thinking these sorts of thoughts, try and replace them with something more useful. I’d like to suggest a “learning” state of mind.
• Think of your tech test as an opportunity to learn something. You could learn about gaps in your knowledge that you could go home and fill, you could pump your interviewer for information and learn about things you didn’t know about, and you can learn new information about the job that you’ve applied for — even if that information is that the job involves working with a bunch of jerks, that’s good information to have.
• If you do find out that the people you’d be working with would be jerks, please don’t work for them. Life is too short. After the interview, stop the process, give them some polite and practical feedback, and go on to find an awesome job working with lovely people instead.

The difficult thing about tech tests is that as they’re designed to test whether you would be good at a job, this suggests that if you fail them in some way you would be bad at a job.

There are lots of reasons why failing a tech test doesn’t mean you’d be bad at a job:

• Tech companies gear their tests towards preventing false-positives rather than reducing false-negatives. For them it’s cheaper to miss out on employing someone great, then it is to employ someone terrible. In addition to this they receive clear feedback when they employ someone terrible, but they can be completely oblivious if they miss employing someone great.
• Tech tests are often badly designed, and only tangentially relevant to your job. Companies only use them because they lack any practical alternative.
• Nearly everyone, including people who are very good at their jobs, has failed a tech test. It’s a completely normal part of an engineering career.

If you harbour any doubts about your intelligence or ability — and pretty much everyone does sometimes — then the idea of failing a tech test, and the subsequent suggestion that you would be bad the job can be very scary.

This can be a particular problem for people who are near the start of their career, as they don’t have that experience that gives them the confidence that they’re good at their jobs. And it’s a positive nightmare for those who suffer from imposter syndrome.

Have any interesting stories to share about your interview process? Leave a comment below, I’d love to hear them!