Need of change

Last year, during our Front End chapter meeting, we agreed to invest some time to improve our front end interview format, as it was not really fit for purpose and did not really supported us in making the right decision about candidates.

The interview format in use involved a coding test, focused in making an ajax request with some added validation, followed by some adHoc question that were tailored on the individual.

Many people will probably see nothing wrong with the test, as it actually provided both coding visibility and the ability to ask questions. Unfortunately after careful research, me and my colleagues found the test unsuitable for the following reasons:

• It tested mainly javascript when our company looked for a wide range of skills such as HTML, CSS, Javascript, accessibility, Framework ( react, vue)
• It required developers to “work under pressure” and not everyone is good at that, and it was not a “requirement” for our vacancies.
• The adHoc questions where too different to compare overtime, and it was hard to define candidates level on them.

After the above “problems” were highlighted, we started to collate all ideas and change our current process to create something that would fit our company requirements.

The different ideas

The new test required the involvement of everyone, so we opened up a survey to ask people what they thought was a cool test, and what did they dislike about it. The ideas that I received were amazing, most of them interesting.

Some of the ideas that were forwarded were:

1. Create a set of question from 30secondsofinterviews.org
2. Ask candidates to complete the FizzBizzTest
3. Ask candidates to bring a project that they were proud of to discuss during the interview
4. Ask them to complete a test in the house ( replicate a website page).
5. Give candidates multiple tests, allowing them to choose what they knew best
6. Live bug fixing

The ideas above were all great, and choose between then has been a hard and lengthy process. At first all of the above may seem good, but each of them had a problem. Either it would focus too much on a specific skill (2) or have legal complication, because they could not share the code (3), or could really be misleading as people could prepare or cheat (1, 5).

Disclaimer

I would like to start this final paragraph by said that what I am going to share with you is not perfect, and it could actually not fit your company at all, but so far we had great feedback from everyone that has completed it, and has allowed us to interview a wide range of candidates, from Graduates to senior, without to need to adapt it.

The result

The final test was a mix of almost all the above suggestion, and has been carefully made ( and is actively tuned with new candidates feedback). The new test has 3 main parts:

1. Home exercise
2. Interview bug fixing
3. Questions

Home exercise

I think everyone could agree with me, in saying that interview are very stressful. You are all dressed up and uncomfortable and scared of doing anything wrong (eg. using google to search for info) and wanting to give the good impression, that sometimes lead to the opposite result. To avoid this points, we all collectively thought that we had abolish having to complete a full exercise while under pressure.

The new proposed solution has the following information

• Complete a specific exercise ( I am not allowed to give too many details).
• The exercise will include basic requirement ( basic HTML, CSS and JS)
• The candidate is asked to complete 2 more points from a pool of 6 specific topic ( responsive design, Advanced Javascript, Unit test, Accessibility, Advanced SASS, JS library Vue or React).
• The candidate is provided with a ready to use zip ( just need to install node and type npm install).
• The candidates is asked to spend no more than 3 hours on the exercise, and depending from their availability ( full time or unemployed) we give them the “expected” time to be able to fit the work ( a week or a couple of days).

The main point to get from the above breakdown, is offering the possibility to candidates to choose what skill they like most. We had candidates that just wanted to focus on the HTML make the design beautiful and clean, and others that wanted to show off their Javascript skills, by writing the above with full test coverage and completing the Advanced JS request.

Interview bug fixing

All developers know well that one of the most important skills in programming, is the ability to fix bugs. My team has thought that we needed to introduce a step in our interview that would avoid people from cheating ( asking someone else to create the above exercise for them).

We thought to “ask questions” about the exercise to candidates, but we knew to well that they people could “study” the implementation and be able to fool us. So we decided to ask developers to “fix some bugs”, more precisely, we would “break” their own exercise in a couple of places, and ask them to fix it.

Depending from the level of confidence we either do this together with the candidates, or leave them some space to sort it out.

We found this “step” to be very informative for us. It provides us with the “confidence level of the candidates”, it is less stressful that live coding ( as they are working on their own code), and it also show us their problem solving skills. I have to admit that his is probably the part I love the most.

Questions

Unfortunately, until now, candidates test would have been very hard to compare and contrast. We still needed something for different interviewer to be able to “understand” people level, without having to open up tens of projects.

Our final decision was a set of question that we have all build from the group up ( this was the hardest part to agree). The questions are divided in “topics” and “level”.

The topics follow the same distinction of the one provided int he home exercise, plus a few extra (like git, agile, etc..). Each topic has 3-4 questions, all divided by level.

The above distinctions allows us to provide the right questions to the right individual ( knowing their preferences from the exercise and from the “live bug fixing”.

This questions are not really defined, they are just “placeholder” for specific information. For example a JS question could be “ES6”, and a CSS one could be “responsive”. It is the interviewer discretion to ask specific question depending from the discussion they had and the code they have seen. For example what is the difference between “let and const” and “how do you use media queries”.

Each questions are written down by the interviewer, and then the answer level is provided (good, basic, knowledgeable, not know). Writing this single word instead that the complete answer, allows us to be able to “compare” candidates and understand their fir within the company ( I am aware that due to the nature of the OPEN questions, it is not a real comparison, but it provide a good idea of strength and weaknesses).

Summary

As mentioned above, this interview seem to be working very well for us. I have not only used it for external candidates, but due to its nice progressive structure, it has also been used for internal “developer programs” and “graduate training”.

We have now build a pool of over 15 different exercise and responses, that is really supporting us in making “good” decision of the candidates. Since the introduction of the above exercise, we also seem to be able to allocate candidate in the right spot, due to the more defined skills information that the test provide us.

I would be very happy to receive any feedback here by commenting below or on twitter. All feedback both positive or negative are welcome, because our real focus is to make our interview as smooth and stress-free as possible to all our candidates.