Some Interview Tips for Junior Developers

In the last two companies I have worked for at one time or another I have been involved in recruiting junior members of staff and I have noticed that sometimes some of them have missed what I would consider key parts of interview preparation.

I think once you have been in the industry long enough you pick up these tips without needing to be formally told, which is potentially why I haven’t seen some of these tips laid out online before.

• Don’t worry about what you don’t know - Junior Developers are almost never hired based on their domain knowledge, it is taken as a given that they don’t have much of that yet.
• If the company produces a product, use it - If the company has a free service (or trial period) then sign up and play about before any interview, if that doesn’t really apply then make it obvious that you have looked around anything you could to do with the product or service.
• Look at any source code you can - This will either be from open GitHub repositories or at a very minimum the companies brochure site. Comment on this in the interview and for bonus points talk about potential improvements to the code.
• Demonstrate a desire for what you do - Show you’ve made an attempt to learn about the industry and want to be in the industry.
• Don’t bluff questions - If we ask you about a particular technology and you know very little about it, say so, and maybe talk about something similar (or ask, is that similar to x, y or z?) DO NOT start waffling about something you know is rubbish.
• Always have followup questions - Even if this is your second or third interview at a company, think of something to ask at the end.
• Try and find out who is interviewing you - This is over-simplifying it but as a general rule; Developers want to hear you talk the tech talk, Marketers want to hear that you will do the company proud, Managers want to hear that you are willing to learn and to rise to a challenge. If you are meeting a non-technical CEO and an Account Manager, explaining you know how to do a binary search isn’t going to impress them much. (Explaining how you love helping customers and trying to understand their requirements would fair you much better!)
• Coding challenges are almost never about the code - They are about how you explain your thought process and how you communicate your code, we would rather hire someone who forgot the need for curly braces and didn’t initialise their variables but can say - “I am called this method foo_bar_baz because I think it is immediately apparent what that means”.

I genuinely hope this helps, and for mega bonus points if I ever interview you, say you read this blog post, the job will be as good as yours! ;-)

I’ve written up some other tips for more junior folk before, which you may appreciate;

• What I look for in a junior developer
• Good backup habits
• Good documentation practices
• Time keeping best practices