When it comes to front-end development, it is a relatively new job title. The advent of responsive web design or as the hipsters call it RWD, meant more emphasis was placed on making coherent front-end user experiences across different devices and mediums.
Even though web development has been a thing since the nineties, you once upon a time called yourself a web developer and it was rare you specialise in just the front-end aspect.
As front-end development evolves and becomes increasingly important, it is especially important companies hiring front-end developers learn how to evolve their interviewing and hiring processes and for front-end developers to also reciprocate.
How to NOT interview a front-end developer
- Whiteboard problem solving: Front end developers do NOT solve problems using whiteboards. Front-end problems need to be solved using code and sometimes through trial and error, there is no set formula or way of doing things that a whiteboard test can account for. And I cannot ever recall a scenario where I was given 15 minutes to solve something. If you require for this a front-end developer, you’re going to be disappointed with the results. In all of my experience, truthly most problems have been solved thanks in part to reading the documentation and StackOverflow.
- Don’t assume they can design: I see this common mistake being made. There are two schools of thought on this: people who believe front-end developers should design and code, and those who believe front-end developers should only code and leave the designing to a qualified designer. A front-end developer with experience working with a designer or design is an added bonus, but don’t get caught up in the hype of believing it is common for someone to be both.
How to interview a front-end developer
- Ask them to detail their workflow: You can get a very good idea of where a developer is at experience and skill-wise by asking them how they work, what tools they use and how they are tied together. If a developer mentions Dreamweaver, you can almost guarantee they are junior level (and there is nothing wrong with that).If a developer lists Grunt or Gulp, SASS/LESS/Stylus, LiveReload, AngularJS and other tools that require a bit of front-end knowledge, you can be rest assured they probably know a bit more than a junior. Having said that, it is possible for a junior to know and use these tools as well.
- Define responsive web development: Ask a developer what responsive web development is and why it is so important.
- Ask for their story: You can gauge the passion a developer has when they speak. If they love what they do, they won’t find it difficult talking about how they found themselves as a developer.You can tell if someone has passion or if they’re just trying to pay off a student loan when they speak to you about something.
- Pair coding: To properly see if a front-end developer is a match, invite them in for a day or so and let them help work on real problems in your code base. Pair them with a designer or another developer, and you will immediately see where they are at and how well they work in your team.
- Ask relevant questions: I have heard horror stories of front-end developers going to job interviews only to be asked questions about algorithms and other non-applicable things for front-end development jobs. Don’t be one of those interviewers who do not understand the job position they are advertising for, it’s a waste of your time and the candidates time as well.
- Detail browser quirks: This is a good one. Ask the potential developer to list some common issues you might come up against when building a responsive website (bonus points for mentioning memory/graphical constraints on mobile devices). Questions about browser support for things like HTML5 Video and audio is an added bonus.
- Trick question: What is your favourite feature in Internet Explorer? (bonus points if they can name an actual favourite feature in Internet Explorer)
Preparing for a front-end developer interview
As a front-end developer, you are going to find yourself in a wide variety of interviews, each different from the last. As far as I am aware, companies are still interviewing front-end developers like they’re wearing both hats, so you need to be prepared to stand up for front-end development and steer the interview in the right direction so you better your chances.
- What does front-end development mean to you? This is your chance to help rectify and clarify any misconceptions the employer might have about front-end development. Explain where you see the field going, the responsibilities and where you see yourself in this picture. For example: “I want to help break down barriers and build applications and interfaces that are accessible no matter the device like TV’s, watches, phones, tablets, laptops and more.
- The tools: As mentioned previously, it is a good idea to detail your workflow and tools, if you’re up to date on what is happening in the way of front-end tools, this will work in your favour. Mentioning experience with package managers like Bower or Component, task runners like Grunt or Gulp and other tools will bolster your credibility.
- Know the buzzwords: I hate buzzwords as much as the next developer does, but sometimes you have to use them in situations where the interviewer or company might not be on your level. If the job listing details experience in HTML5 or CSS3, you can almost guarantee dropping the use of words like; Responsive web development, CSS3, HTML5 and other buzzwords will make you more appealing. Know when to use them though, they won’t apply in every interview or context.
- Ask for help: If you are asked to do whiteboard/paper and or verbal problem solving, if you are unsure, make sure you ask questions. It isn’t a sign of weakness, a developer who asks questions when they get stuck is actually a good thing. In the real world, you aren’t expected to have all of the answers, your colleagues might know or StackOverflow might be your friend. So relax, if you do need to do some problem solving, they’re looking to see how you go about solving a problem, even if you don’t solve the actual problem, it isn’t the end of the world.
- Prepare for FizzBuzz: There is a high possibility you will be asked to do a FizzBuzz test. Make sure you know how to write a FizzBuzz test as well as being able to explain how a FizzBuzz test actually works. Chances are it will be the old variant of every 3 print out “Fizz” every 5 print out “Buzz” and every 15 print out “FizzBuzz” from numbers 1 to 100. But be prepared for any combination of numbers.
- Prepare examples of your work: As always, a portfolio of work is an added bonus. Pick a couple of sites you deem to be your best work so far, but not only that, a trick I like to use is to explain the project in a little detail. Explain the things that might not be noticeable, like the thought process for how something works or a particular line of code you’re proud of that does something cool.
- Detail side/pet projects: If you have any side or pet projects you are working on, be sure to mention them. Most employers will see this as a sign of commitment to your field and will appreciate that you code outside of working hours (it shows you are always learning and have a vested interest).
- Create a Github: Most developers have Github accounts. It is not a requirement, but I equate it to a code resume. Contribute to some open source projects, put some of your own code out there for show and show potential employers what you are capable of. I’ve seen job listings that have Github in the requirements list before, so it pays to create a free account and put yourself out there.
- Ask questions: This is something that applies to any job interview, when they ask at the end if you have any questions, ask something that you know wasn’t clarified in the interview. If you can’t think of anything try some of these; How big is the team?, Does the company have plans to grow the team or keep it the same size?, Where do you see my position within the company in X years?, What is the culture like here?
Thanks for this. I’ll let you know how my interview goes.
This article is fantastic just shared on linked in and twitter. What happened to me (and what you could add to the list of no-noes):
– instead of being tested on my own laptop in my environment I have been put to make a timed code test on a Windows machine with an unknown editor. It took twice as long of course.
– I have been given online tests on third party websites that were wrong, and have been put in the situation to try to understand what the correct problem would look like.
– I have been tested by who was supposed to become my future colleague. Of course not knowing that from the start made me demonstrate aptitudes too good to be hired.
– I’ve been at an interview where I’ve been tested on writing code with pen and paper, and failed because I had a different opinion on frameworks and WordPress.
– I failed a test because I have done a version of a page compatible with everything from IE6 but I did not use HTML5(!) and another version using latest technologies, but that did not work with an older browser!!! I was suppose to do only one page with technologies at my choosing.
I have the feeling that this unhealthy practice became standard since the start-ups boom, since companies founded by 20 years old started to decide how the hiring process should be.
Thank you again for this wonderful article and for showing me that there is still common sense somewhere in the world.
Thanks for this article. I am a developer and designer for 20 years (being, hiring and firing teams) and never had or did a FizzBuzz test. Why do you think people in Oz think this will help to identify? I always assumed my guys learned the 101 or algebra at school.