In various jobs I have held I have had to sit in and conduct interviews for a junior developer role. Junior developers by their nature have very little industry experience and very few projects which they can discuss at length.
In those interviews I wasn’t looking for someone that had all the answers, I was looking for someone that I thought the team would enjoy working with and teaching.
What I look for in a junior developer is passion. There has to be a fire in their belly and a genuine desire to learn about things that right now probably seem so unknowable.
Junior developers generally won’t have had too much interview experience, so I would not be looking for a candidate who maintains eye contact at all times and answers everything without first taking time to think.
What I do look for is someone who can communicate – even with my limited experience as an interviewer I feel it is apparent when someone isn’t communicating well because of nerves, or isn’t communicating well because it isn’t in their nature to communicate.
Communication is a massive part of our job, we are telling stories through code and through commit messages and through support emails. I am not good enough to teach someone how to be a good communicator so I would like to hire people who are by their nature communicators.
I look for honesty.
I was once in an interview where the interviewee said they had looked at our website’s source code (we asked). Before putting out the position we had introduced a comment at the very top of the site saying something along the lines of;
<!-- Hello there, if you are interviewing with us and mention that you seen this comment, you will score major points! -->
We asked what they noticed and they had no comment (and clearly looked very nervous). There was no way we could hire them.
It doesn’t have to be this extreme of course, what really turns me off about a candidate is when you ask them “Do you know much about technology y” and instead of answering “No, but I have heard it is like technology x which I know about”, or “No, sorry, is there another name I might have heard it being called”, they answer with “Ummm yeah, I think so, it is like this thing that lets you do this thing that…”
It is honestly better to be honest!
When asked a hypothetical question like “The client is reporting that the email form we built them isn’t working, how would you handle this” we generally aren’t looking for technical answers.
I want to know about how you think about things – being able to think on your feet is incredibly important and I want to know what type of thought process you use.
I also want to know about how you might communicate the issue with your hypothetical teammates and this hypothetical client.
In my experience the questions you get asked at the end of an interview are very telling and say a lot about the interviewee.
First up, have questions. There is nothing worse than asking nothing.
Second up, know that there are no dumb questions – you won’t get marked down for asking something you think everyone else knows.
Good questions I have heard before include topics such as;
- If there is a training budget
- What is a normal day like for a dev in the company
- Who would I be reporting to and what is their role
- Why has a position opened up
- Are there any main projects that I would be spending most of my time on?
If you're a junior developer who has landed an interview, you may be interested in my post interview tips for junior developers.
This article originally appeared on tosbourn.com