How to ace developer technical interviews

Technical interviews for developer jobs can be difficult. You are sure to fail a few until you grasp what people are looking for.

I conduct many interviews so here are my tips on getting through to an offer.

The take home challenge

Many companies have a take home coding challenge. It normally consists of a written problem and a description of what the reviewers of your submission are looking to see. Some will let you choose what language to tackle the problem in, some may specify what you have to use.

Please, read the instructions. Let it soak in for a period of time and read it again before you start. I have reviewed many submissions where people have only read the first part of what's required and then dived in to writing the solution. I would re-read the requirements info before you submit your solution to ensure you have ticked all the boxes. Failing to meet the requirements will get you cut early.

With submissions I review, here is what I am looking for.

Have you added a well written README?

I will start here and follow your instructions to the letter. You probably should do the same.

Does it work?

Nah seriously, does it actually run and produce correct results? I will run it and verify the results.

Does it have tests and do they pass?

I am going to run the tests. I am looking for green here. I'll probably also notice if there is only 1 test or 300. I'm looking for a good amount of testing to ensure that the program produces the correct results, but not overkill. It goes without saying, you should add some tests!

Have you got a git history?

I'll check that a git history exists. I'll load it up in my favourite GUI tool and scroll through the commits. I wont be looking for what order you work in. Some people go strict "tests first", others do a little coding and then do a little testing. What I am looking for is that you have some method to the way in which you work.

If you tick off these, you will probably pass the first round of screening to see if you can actually code.

As the roles get more senior, I'll pay more attention to the commit messages, the sorts of payloads that are in the commits and try to work out ways of working.

If you want to really make certain you progress, then here are a few tips.

Take it seriously

Treat the exercise like this is your profession. You're coding to land the job. Add linters and code quality to make sure you code looks wonderful. I often open up submissions and it's all over the place. My IDE is set up to highlight trailing whitespace in red, draw lines between the brackets. When you've got your indentation and formatting all wrong, I do see it. It's not a hanging offence, but it can affect what pay scale level is recommended if you receive an offer.

Cheat and prototype your solution

If you can't immediately see how you want to tackle the solution, do a prototype first. Forget testing, just work through the problem, get your head straight. When you've got a prototype solution, start a new project, the one you are going to submit. This way, you can show a clean pattern to match the expectations of the reviewer.

The pairing interview

Photo by Headway

The take home challenge was to see if you can code or not. The pairing interview is different.

What I am primarily looking for is what it is like to work with you. Everyone knows that I am looking to see if you wrote that submission and can code like we saw in the take home challenge. I am also looking to see how you approach a problem. I am looking to see what it's like to work by your side. Are you a decent human? Are you a control freak? Are you doing OK with the pressure of the pairing session? Is the problem too hard to work through?

Here's a few secrets from some of my pairing interviews.

Yes, the problem can be difficult. There is only a limited amount of time to work on the problem. No one has got to a working solution within that time window. Just keep calm.

I have been in pairing interviews where we didn't even get started in the problem because the candidate just got overwhelmed. I will try to make you feel comfortable. I do understand that it's stressful. I will try to help.

In my company, we provide a skeleton application that takes care of the boilerplate work. This is because we don't want to waste your time showing us how to set up a project. We are looking to get in to the problem space and see how you work towards a solution.

Want a successful pairing session? Here are some top tips.

Treat it like your day job

Acknowledge the time constraints and talk to your interviewer like it was your first day on the project. Chat about the ways you want to work on the problem. For my part, I'll make sure that you are aware that I am not looking for all the answers and that it's OK to ask me, Google or Stack Overflow for the answer. Heck, without Google, I'm not much of a coder at all.

Do code

We want to see you code, so don't spend all your time designing the solution or talking about the problem. Remember that I have to check off that you were the person who added the great work in the code submission. So write some tests, write some functions or classes. This really should be your priority.

Chat!

Talk about what you are doing and your ideas as you work through the problem. It helps me understand the way you are working. It's also a great way to pair. I can ask questions and we can discuss ways to solve things. I may not have all the right answers. Sometimes I have the wrong answers and you might even see me Googling the syntax. If things are just rolling along smoothly, feel free to chat to me as a person.

Get a rhythm going

Whatever your normal workflow is, use it. For me, I look at a small chunk of the problem and I write some code. Then I write some tests. Then I fix my code and write a few more tests. I then check in my little feature and move on. Work to a drumbeat that shows how you work, I will notice it.

Be friendly

I'll always ask some question about you as a person while we're coding. Small talk like how far away you live or if you are a dog or cat person. It's a way I can start to see if you would be great on my team. That's my big goal - would I want you on my team? If you can code, problem solve, handle diversity of opinions, ask for help and above all, are friendly, the answer will be yes and you will most likely pass this round.

We're not looking for robots. We like working with nice people.

I work at a place like this now and I trust that the core culture is protected by the people conducting the interview process.

Be yourself, it is really hard to be anyone else. Good luck in your journey.