Sweaty-palmed you shake the hand of the developer who is going to be grilling you today. You nervously make small talk and then sit down on the opposite side of the table to your opponent. Most interviews start this way, however, a software developer interview can generally go one of two ways.

You have the nice interviewer who asks you about your experience, gets you to talk through the technologies you have used and explain your roles on the projects you have worked on.

Then there is the interviewer who tries to trip you up, who will crack out the algorithm questions and get you to code an application on the big screen in front of 3 other developers while they all watch.

During my time as a software developer, I have been to a fair few interviews and have been an interviewer for even more. Generally, there is a pattern to what you can expect when you get to an interview and it often depends on what you had to do to get there.

Pre-screening

There will always be some form of pre-screening to go through. It is understandable, a company doesn’t want to waste the time of their expensive developers going through CVs and asking technical questions over the phone.

Naturally, the pre-screening will start the moment you hand over your CV. The first person to look at your CV will likely be the company recruiter. They won’t be a developer but if they are good at their job they will have a basic understanding of the different technologies and skill sets they are seeking.

However, it is worth making sure that the technologies mentioned in the job description are easy to find on your CV. Now, I am not saying you should lie about the technologies you know, just be explicit about them. For example, if the job description says JavaScript, mention it. Saying you know React or Angular might not tick the right boxes for the recruiter who has your resume.

Judging by the number of recruiters who contact me about jobs that aren’t anywhere close to my skill set, you do have to wonder how much they know about the roles they are hiring for.

If you apply for a job online there is a chance that the companies Applicant Tracking System (ATS) will just filter your CV out if you don’t have the required skills mentioned on it.

Phone Interview

If your CV checked the right boxes and you make it through the first hurdle, congratulations, the second one will likely be a phone interview with the recruiter. Again, not a developer. The point of this stage will be to establish your motivations for leaving your current job and your expectations of the new one.

If the salary hasn’t been mentioned yet, it will likely be discussed at this point, at least an expected range should be brought up. It is just a waste of everyone’s time if the salary isn’t what you expected when you get an offer.

Provided you don’t bad mouth your current employer, be rude or unreasonable on the phone it is difficult not to get past this stage.

Technical Test

Apart from when I was applying as a graduate, there hasn’t been a single developer job I have applied for that hasn’t asked me to do a technical test.

There are generally two different types of technical tests, the online questionnaire and the mini project. I have had several interviews where I have had both. If you don’t get either, then chances are they will get you to do one at the interview.

Online Questionnaire

The online tests I have encountered generally consist of somewhere between the following:

• In-depth multiple choice questions about a programming language. These tests essentially try and grade you on your ability by asking you textbook knowledge questions. Personally, I think they are useless but they are generally used by large consultancy companies.
• Mini functional coding test. With these, you generally have a set amount of time to write a function which does a particular task. Such as sorting an array of numbers or reversing the letters on each word. These are generally just a variation on the Fizz-Buzz test to make sure you weren’t completely lying on your CV. Have a look at HackerRank if you haven’t done one of these before.

Mini project

This is my preferred method for testing candidates, however, it is also the most time consuming, for both parties. Once you have done a few of these you can generally code them up quite quickly. Equally, it could take you a whole weekend. Bear that in mind when you decide to apply for 20 jobs at once.

I once had a candidate who complained he couldn’t finish the test because he also had another 3 tests to complete that weekend.

A friend of mine managed to avoid this part by just pointing his new employer to his GitHub repository which had a bunch of these tests completed already.

The work you do here will likely get sent to a developer to review. It may well be the first time a developer gets to see your code and CV. You should be trying to do your best work here. Write the code as if it was going to be going into production.

Here is some advice:

• Write unit tests, that pass
• Use dependency injection
• Separate your concerns
• OK, just follow SOLID
• Write Documentation

Pay particular attention to the first and last of those points. Your code is going to be sent to a developer, who likely has tight deadlines and plenty of code to write and review. He (or she) has likely blocked out half an hour to an hour of their time to review your code.

If they can’t work out how to get your project up and running and test it then they aren’t going to be happy and you aren’t going to make it to the next stage. So do everything you can to make it easy for them. The documentation should outline how to get the project running, what the endpoints are and what your design choices were. Bonus points if you add in Postman script to run it too.

It is worth adding in your documentation how you would improve the project given more time. It is a great place to show off any extra knowledge you have.

It should go without saying but you should be using source control (preferably git) with regular check-ins. I do look at the git commits when I am reviewing tests to make sure there is more than just one commit. I am sure I am not the only one who does this.

All being well if you have taken the time to write a decent bit of code that is well tested you shouldn’t have a problem getting to interview. If you fail at this point hopefully you should get some good constructive feedback that you can use to improve your next test.

Interview Time

If you have gone through all of the above then chances are this stage is more of a formality.

You may even have a few more hoops to jump through before you get here. I once had to do a phone interview, technical test, video interview and another technical test before getting to this stage. And no, it wasn’t Facebook or Google.

If the developer who reviewed your code is interviewing you then chances are they will already have formed an impression about you.

Either way, a developer would have written notes about what they thought of your code. If your code was that bad then you wouldn’t have got to this stage. There is still a chance though that your code was only just good enough.

In which case you can expect more questions about your technical ability than you may have otherwise have got.

It is the interviewer’s job to try and gauge if you are a good fit for this position. If you are applying for a senior position then chances are there will be a little leeway in issues with your technical ability.

The person interviewing you will likely be a senior developer or technical lead, therefore, they would expect another senior developer to have similar if not more knowledge than them. If the role contains some form of mentoring others then they need to make sure you have the necessary capacity to do that.

For mid-level roles, there is generally a bit of give and take. I understand that some developers can get stuck in roles and as a result, their skills stagnate. However, if you show enough passion and willingness to learn then you stand a good chance.

If you know that most of your experience is WinForms and old ASP and you are applying for somewhere using .Net Core then it would be worth at least trying out a project in your spare time.

It should go without saying but do your research about the company you are applying for. It surprises me the number of candidates who come in without really knowing what the company does.

Lastly, have some questions ready. I have been in the situation where the interviewer has been so chatty they have covered all my questions by the time they come to ask me. In which case make some up.

If the interview went well and you want the job then some questions should come up naturally. Such as, “Tell me about the team I will be working on?”, “What does your typical day look like?”, “What is your CI/CD process?“.

Signs of a Successful Interview

This might not be the case for everyone but I generally know when I am going to get an offer based on how I feel coming out of an interview.

I know it might sound crazy but I have actually enjoyed all the interviews where I have got an offer. Also, those interviews tend to be excessively long, i.e. 3 hours long. The last interview I had I spent 2 hours talking to the then director of engineering about all things tech.

These have been my experiences of surviving tech interviews but I would love to hear about yours in the comments.