One of my former bosses used to tell me that even if you aren’t actively looking for a job, it can be a good idea to go along to a job interview once in a while to keep yourself sharp.
Having very recently changed job myself, I can now see what he meant.
Interviewing for the first time in over 3 years was tough. Although, as front-end developers, we’re very lucky to be working in an industry in which there are plenty of jobs available, the very best roles are – as expected – looking for the very best devs and the interview process can be very rigourous.
So I wanted to share what I have learned from my recent experiences as a candidate and previously as an interviewer. Although my observations come from my experience with front-end roles, some of the points raised could easily be relevant when applying for any technical role.
As someone who has led interviews in the past, I can verify just how difficult it can be to judge just how good a developer is by simply talking to them.
Interviewers only get to see a brief snapshot of you and your work. This is especially true when the first stage of an application is over the phone. This inevitably means that you will be asked a variety of questions to roughly gauge your ability. No matter how good you may be when it comes to writing code, if you can’t answer questions on some fundamental topics, then chances are the interview won’t go very well.
The problem with this is that developers rarely have to explain the basics in their day-to-day jobs, as it’s what could be thought of as implied knowledge . By this I mean that it’s knowledge that all front-end developers should have, but can be so fundamental to the work we do that we simply take it for granted; so much so that explaining it verbally can be awkward or unfamiliar.
For example, how many times recently have you had to explain out loud the difference between using
position: absolute and
position: fixed? My guess would be not very often. This is a fundamental piece of knowledge for any front–end developer, but ensuring you can effectively convey your understanding in areas such as this is key.
Here are a few examples of front-end specific questions that I have been asked during recent interviews:
$represent when using jQuery?
thiskeyword and it’s behaviour in JS.
Questions such as these act as the baseline for any front-end interview, therefore being able to answer examples like these correctly and succinctly is something that you should practice before any interview.
The HTML5 boilerplate team maintains a more exhaustive list of possible interview questions for front–end devs – I highly recommend checking it out.
It may sound obvious, but make sure you are up-to-date with the current hot topics in front-end development.
For example, if you were to go to a front-end interview right now, you would almost certainly be asked a question on the subject of JS frameworks.
Even if you’ve never used one, make sure that you know what’s out there and the type of projects that are best suited to each one. There’s no right or wrong answer to the question 'What’s your favourite JS framework?' (some people may disagree!). If I was asking that question, I’d expect the candidate to be objective and to be to able explain the pros and cons of the frameworks that they knew about.
If you like to keep on top of this kind of stuff – which if you’re reading this post, you likely do – you’ll be in a great position come interview time.
The best interviewers will not only be looking for what you do know, but also what you don’t.
Part of working effectively with others is knowing when to be able to ask for help from those around you when needed. I’ve found that the better the role I have applied for, the more likely it will be that the interviewer(s) will look to explore topics that I clearly have less experience on.
The goal of this type of questioning is to see how far the candidate needs to be questioned before they stop looking for the 'correct' answer – of which there sometimes isn’t one – and concedes that they don’t know and should ask someone else for advice on the subject. Not only does this show more humility towards the candidates own ability, but it also gives the impression that they would be less likely to relentlessly plough on attempting to solve a problem themselves when the best option would be to ask for some help.
A classic example of this was actually during my interview with Just Eat (aka my new employer). At one stage in the process I was asked to sketch and explain how I would structure a takeaway ordering application – right through to envisaging the sort of database structure the system might need.
Interviewing for a UI development role this question was designed to take me out of my comfort zone to see how I would try to solve problems that I wouldn’t have all the answers to. As the conversation went deeper into specifics, the more I struggled to find concrete solutions. I finally concluded that it would be advisable to ask those with more specialist experience to explore some of my assumptions around databases and server scaling. This is completely understandable – I would be working with people specialising in these areas, so trying to solve these problems myself would be pretty futile.
It’s ok not to know things – the best front-end developers in the world don’t know everything about all aspects of the web. If you definitely don’t know the answer to a question, it’s much better to admit it rather than trying to fabricate a solution.
As teams can potentially be remotely located, the chance of having a job interview via Skype or Google Hangouts increases. One tool that has become increasingly popular in interviews is live coding.
The concept is pretty simple – the candidate is asked to live code the solution to a programming question while explaining their thinking out loud to the interviewer. Simple enough, but this comes more naturally to some devs than others. If you’ve ever pair programmed, you’ll probably be very comfortable as the experience can be pretty similar.
If you’ve never done something like this before, make sure you practice it beforehand. Use an online editor such as CodePen or JSBin, as usually these tests will utilise a similar online text editor. If you have a friend who is happy to help you out, put them in the position of interviewer and let them provide feedback on areas you could improve upon.
Companies will likely tell you beforehand if they’re expecting you to live code, so if this does happen just make sure you prepare in the right way.
This is the one facet that I used to look for most whenever I conducted interviews.
Personally, I love working with developers who are passionate about the industry we work in. If I interviewed Developer A with 10 years experience, but they couldn’t tell me anything about future standards on the web, or Developer B with just a couple of years experience but could talk about web components and ES6 all day long, I’d want to work with developer B.
This passion is impossible to teach and so if someone has it, they will always be sought after when looking for new roles. The hard part can be showing it when you’re starting out – make sure you put your projects on Github or CodePen so you can send links in with your application, or blog about the things that you’re most passionate about. The more visible you make your skills, the more you will stand out from the crowd.
There was one final aspect of interviewing that took me a little by surprise – an emphasis on basic Computer Science (CS) knowledge.
Interviewers ultimately want you to be successful – they aren’t trying to set you up to fail. These points should help you focus on some of the key areas that you should prepare for.
I’ve avoided going over general interview advice, but make sure you do the expected groundwork around knowing a bit about what the company you’re applying for actually does – it usually helps!
If you’ve had any recent experiences interviewing for front-end positions which you’d like to share, I’d love to hear from you in the comments.
Article posted on the 1st July 2015