LumApps — Changing our frontend interview process
At the beginning of 2020, we decided to change our interview process for our frontend candidates by introducing a new frontend test that tries to take away the pressure of coding challenges.
A little bit about LumApps
If you do not know about LumApps, we are a global tech company with R&D teams in France that provides our customers a SaaS Digital Workplace solution, which creates a holistic workspace, integrated with several suites and collaboration tools. Want to know a little bit more about us? Head over to LumApps.com and take a look!
What was our frontend interview process like before?
Up until 2020, our frontend interview process consisted of several interviews that tried to evaluate the technical knowledge of the candidates as well as the cultural fit with the company:
- An initial interview with our tech recruiter as a the initial step of the interview process
- An interview with the team's manager in order to get to know the candidate a little bit more and evaluate their tech background as well as their cultural fit.
- An online questionnaire with technical questions for JavaScript, Angular JS and React. These questions would be quite theoretical (like What is “hoisting” in JavaScript?) or tricky (like what is the output of (function() { var a = b = 5; })(); console.log(b);), or involved specific framework concepts such as digest cycle for Angular JS or explain the reconciliation process for React.
- We then had a live coding challenge where the candidate would have a series of exercises to do while another engineer followed their steps.
- If those tests went well, we then had a final round of interviews with several members of different teams, each of them with a different technical background.
What were things that led us to change the process?
Technical perspective
From a technical standpoint, our technical test was not ideal for either our candidates as well as our company.
- Our online form had mostly questions that tried to evaluate very specific technical knowledge but ended up being questions that were tricky, nit-picky and really did not help us evaluate a candidate. We really did not need to know if a candidate knows what is the output of (function() { var a = b = 5; })(); console.log(b);), it proves little to nothing 😅
- We also asked questions about Angular JS, which is really a technology that we are currently using in our Legacy application, but we are slowly transitioning into full React. Having questions that evaluate Angular JS knowledge will not help us in the future, since what we really want is to have a full React application. And usually when we need to change something on the legacy application, is it basically to fix a bug or add a React component, so we really did not need to evalute a candidate's knowledge on Angular JS.
- Then there was the coding challenge. This is a current subject in the frontend community, with several opinions and perspectives. From our end, we believe that we need to evaluate our candidate on how well they will perform their daily tasks, how they can code using the technologies that we are using, and which are their strengths and which are the topics that they need a little bit more help. A coding challenge does not represent any of those things, since you are not usually coding a binary search (on LumApps frontend at least), you are not usually coding with someone evaluating your every move, and you do not code without Google or an IDE.
- Furthemore, as a company, LumApps grows everyday, with a lot of features under development, some of them with a very important weight on their shoulders. We needed to start evaluating candidates on whether they were capable of leading entire initiatives, or they could be part of those initiatives with more of a contributor role. This meant that we needed to evaluate our candidates on an architectural and long term perspective, and with our current tests, were not able to.
Cultural perspective
As for our cultural evaluation of the candidate, what we were really missing is the fact that the candidate did never encounter other developers from their own team. They had interviews with their managers, and other coworkers from other teams, but they never talked with someone that will be working with them on a daily basis.
Which is our interview process now?
Taking all of those topics into consideration, we decided to restructure our frontend interview process:
- Our initial interviews with the recruiter and the manager are still in place, we found that those steps are quite essential for explaining the candidate what we do at LumApps, what they could possibly do in their team and how the interview process will unfold.
- We ditched the online form, all the technical questions and the coding challenge, and replaced it with a frontend test that each candidate can do from their home. We have a public repository with a base application, with several utilities and scaffolding already in place in order to mimic the tools that we use at LumApps on our daily basis. The candidate needs to fork that repository, and code the provided exercise, which is basically a search results and details page of superheroes from Marvel, using Marvel's public API. The test usually takes around 4 hours to complete, we already provide a developement environment, with no setup needed. Just hit yarn and you are good to go.
- Once the candidate is satisfied with their test (the candidate can take all the time they want to do it, add tests, iterate, etc.), they provide us access to their forked repository and we start the review. In order to do that, we have a series of guidelines and key aspects that we want to evaluate, and depending how the candidate has performed on each aspect, we can have an idea of what their seniority would be. These topics go from code readability, project scaffolding, maintainability, performance, accessibility, usability and user and developer experience.
- After that test, we do three interviews (usually the same day) with that candidate. The first one is a debrief of the technical test where we discuss a few of the implementations and decisions that the candidate took for their test. We want to have a moment to discuss these topics personally with the candidate, in order to evaluate what they wanted to do on the test, how they did it, and what they could add in the future.
- The second one is more of a cultural fit interview where the candidate discusses with two of their future/possible team mates. We try to get someone from the backend team and someone from the frontend team in that meeting, so they we have several different points of view.
- The third one is with our CTO. Our cultural fit is very important and our CTO loves to exchange with the future candidates on this topic, and this allows the candidates to have an exchange with a co-founder, with provides a lot of insights and opportunities to discuss the long term vision of the company.
What did we learn from this change?
As of today, we have already changed for good our frontend test, and all of our frontend candidates from now on will take the new format. From it, we learned that allowing candidates to take the test in a normal working environment, where you do not have someone breathing on your neck and where you are implemeting something cool and fun rather than testing your skills for coding a complex function can provide a set of results that allows us not only to evaluate their skills and how can they work on a daily basis, but also allow candidates to express what they can do, what technologies they can use, and how they can use them.
