The Art of Hiring Great Javascript Developers

Hiring good JavaScript application developers is not easy. Whenever the recruitment team sets up a proper funnel, only 5% – 8% of the applicants reach the final interview. If recruiters focus on wrong things, they reject their best candidates. Even worse, many developers learn how to “fake” the interview and land at a job they are not qualified for. It is your interest that your team consists of competent people who get things done. I find it very important to spread the message that there is a way to raise your standards when it comes to recruitment. I will also share my funnel with you for the purpose of giving you ideas on how to implement your recruitment strategy.

What is the problem with JavaScript experience?

During my university years, JavaScript was the toy language responsible for small animations on the web. Graduate IT engineers end up landing at jobs using other programming languages. In my first job, I mainly used Java, while a high school graduate was taking care of JavaScript development.

Many universities and colleges innovate slower than they should. A lot of university professors out there still treat JavaScript as if they were in 2004. When I met a PhD student a couple of years ago, I saw the scorn on his face when I told him that my main responsibility was client side development using JavaScript. He interpreted this message as if I used my IT engineering degree to become a taxi driver. When I told him JavaScript was booming, he did not believe me. Today, he may be one of the instructors educating people about programming languages.

One of my friends is an excellent JavaScript developer without formal education. He decided on going “back to school” to learn software engineering. When we talked about the role of JavaScript in his university, his experience matched mine.

JavaScript will eventually take its place in formal education as well. Until then, recruiters have to accept that seniority in JavaScript is achieved through the following two paths:

  • Learning by doing: JavaScript is attractive. Many people write JavaScript code even without getting paid. Some of these people figure out that their passion is also worth some money at the job market. These people may be excellent problem solvers, they may learn new technologies rapidly. However, most of them lack experience and knowledge about principles of software engineering, making their solutions more fragile as complexity increases
  • Software engineers transitioning from other technologies: Many JavaScript developers used to be Java, .NET, PHP developers. These people know why refactoring code is important. They know what MVC is. They also know how to write robust software regardless of the language. They just have less experience when it comes to the dirty details of how JavaScript works. These people are also fast learners and may be excellent additions to your team

If you are in a position of assembling a great team, pair JavaScript wizards with good, experienced software engineers. Knowledge transfer will do miracles.

Some candidates “fake it till they make it”: they claim they have JavaScript experience while in practice, all they did was writing some jQuery widgets and reading some articles to sound competent in an interview.

Trainee and junior developers are easier to find. All they need is good problem-solving skills and an affinity to study any technologies they use.

Hire T-Shaped Professionals

Both generalists and specialists have their role as software developers. Most career gurus suggest developers to specialize. Generalist knowledge is undervalued.

Unless a role requires deeply specialized knowledge, I strongly believe in hiring T-shaped professionals. The horizontal segment of the T symbolizes generalist knowledge, while the vertical segment drilling down stands for specialization. The T-shaped profile may not be as good as a true specialist of a specific field, but he will still be good enough for 99% of the tasks. Generalist knowledge will offset for the time lost researching the remaining 1%.

The Application Package

Given that I receive applicants from all over the world, quality of the applications vary. Some people just want to try their luck, while others are well prepared. In order to avoid dealing with the absolute worst applications, there is an HR pre-screen. Resumes that don’t even pass the HR department should be the ones that you would reject almost 100% of the time. These applications are mostly rejected on the basis of English skills, motivation or personality. If a developer with less than two years of experience applied for a position requesting 5 years of relevant experience, I would ask HR to let me decide if we reject him or not. I personally don’t believe in “number of years of experience”, and whenever I have the chance to delete this condition from a job post, I go ahead.

The main purpose of checking the application package is to decide if you would like to give the applicant a chance for the first interview and the task. The strengths and weaknesses of the applicant influence the interview questions and tasks (s)he receives.

The cover letter reveals if the English of the applicant is not good enough. A software engineer has to have at least relatively good English skills for the purpose of writing documentation, opening GitHub issues, communicating with other team members. Coding is just one part of the equation.

Unfortunately, many cover letters contain clichés. Some people write that they believe they are excellent assets without supporting the claim with evidence. Others claim they are excellent communicators while they cannot write a sentence without at least 3 grammar mistakes. Clichés never make an application better, but they can signal lack of integrity as soon as a counter-example is provided. Instead of clichés examples taken from the past of the applicant is advised.

Demonstrated experience always speaks for itself. Code examples, a GitHub account, a portfolio, a blog or a StackOverflow account reveal a lot more about your skills than a resume. JavaScript code speaks for itself. Any material revealing the thought process of the applicant improves my chance of determining if (s)he would cope with the responsibilities.

Online presence is not a must though. I respect that everyone has a life. Excellent developers having no online presence will still have a chance to prove themselves during the coding task.

There are many other factors I could write about, but I think I already transmitted the basic idea of this phase. Be as objective as possible and look for evidence assessing how well the applicant would solve real-life problems.

Once the application is evaluated, the following decisions can be made:

  • Go: the applicant deserves a chance. I also guide the next steps with advice based on the advantages and disadvantages I identified
  • No go: it is very unlikely that the applicant would get hired. Even at the expense of rejecting a good applicant from time to time, I tend to save time by rejecting applicants I am objectively not satisfied with
  • Transfer: other teams may be hiring. If you know what they are looking for and the application is a better match for them, you can simply ask another team lead to review the application

Interview on Personality

This interview has the purpose of checking if the candidate is a good cultural fit for the position. What do I mean by that? Some people fail because they cannot express their ideas. Others fail because they lack integrity. I don’t suggest using the popular HR questions, they sound like clichés. This interview should rather be a friendly conversation, finding out as much from the other party as possible.

Detecting problems with personality is not straightforward. There are other people who are more qualified to write on this topic than me, so I will continue focusing on the technical interview. It is worth mentioning though that most of the advice I gave you for checking the cover letter and the resume apply here as well. In addition, I don’t believe in generic HR questions. A natural conversation is more appropriate than forcing the applicants to answer some of the “100 most common interview questions”.

Coding Task

I suggest creating a couple of tasks that can be done in a couple of hours or at most in a day even if the applicant has never used the requested framework or technology. These tasks should be as close to the daily activities of your team as possible. Reasons: first, the applicant gets a feel of what it would be like for him to work with you. Second, you will be fully competent in reviewing the solution. If you use React and Flux on a daily basis, why would you accept a solution in AngularJs?

When you receive the solution, you should already know your expectations based on the resume pre-screen. People with average or below-average English should prove that their documentation is good enough. If the task is about Backbone and Marionette and the candidate had no prior experience in them, consider the short learning curve. This is where the very best applicants shine: compare the experience of receiving quality code from someone who just learned the framework of your choice to reviewing a motivation letter where an applicant claims he is a fast learner.

Developers who have experience in the framework of your choice are expected to use the framework without rookie mistakes.

The hard part is assessing the quality of the solution. Most companies prefer working with developers who can deliver robust code. Yet, at least half of the applicants settle for a solution I can break in at least 5 to 10 ways. In elementary school, we had a subject where we were asked to assemble a working machine built from building blocks and screws. Once we were done, our teacher came, she started shaking our machine, then smashed it to the table. The best solutions were still working, others completely collapsed. I use her mentality now to check how robust a software solution is. If there is a mistake in the application, I will find it. If I find too many mistakes, I stop reviewing the code and reject the application. Once I had to reject a senior developer writing good quality code because his solution was full of errors. I felt bad at that time, but I soon felt better once I imagined the same developer making some of these mistakes in my team on a daily basis.

While resumes can lead to borderline go/no-go decisions, task solutions are mostly straightforward. If the applicant meets the minimum expectations and his solution is robust, he will receive the second interview.

Don’t worry if you reject 3 solutions out of 4. As you spent a significant time reviewing the task, you can send your reasons to the applicant as well, making him a better developer in the long run. They will be grateful for your help. You can also encourage some of the applicants to re-apply in half a year or so.

Technical Interview

In case of the positions I have interviewed for, one technical interview has been enough. This interview has four goals:

  • Inform the candidate about the position and about the company from the point of view of our team
  • Check if the candidate is a good cultural fit
  • Verify the solution of the candidate
  • Ask the candidate to write code during the interview

At this stage, the first two points should be straightforward.

Verification of the coding task is a must. Although your tasks are normally not uploaded to the Internet, some people still copy-paste code they don’t understand. Others hire friends or freelancers to solve the task. I usually come up with three questions related to the code. If a solution was written by someone else, I would detect it at almost 100% accuracy, unless I was dealing with a lazy genius.

Let me give you an example: suppose I find the class .form__label in the CSS code of your solution. I would first ask the reason behind the __, expecting an answer about the Block-Element-Modifier notation. My next question would be about a class name representing an error label, expecting the answer .form__label--error, where error acts as a modifier to form__label. Although some people just write block elements out of habit without knowing the theory behind them, most likely this question will reveal that there is real knowledge behind the choice of class.

I have never had a case when three of these questions were not enough to determine if the candidate built the code on solid foundations. Backup questions still come handy in extreme cases.

The very last hurdle in the interview process is writing code during the interview. Many people cannot solve simple problems on their own. When assessing problem-solving skills, don’t ask for too much. An algorithm requiring 10 lines of JavaScript code is enough. Don’t build on lexical knowledge. Just come up with a slightly challenging JavaScript riddle. Some examples:

  • Make a small modification in your coding task such as adding sorting or filtering
  • Write a function such as determining the length of the longest palindrome in a String
  • Refactor a code segment
  • Find an interesting bug your team fixed in the past and simplify it

The candidate is allowed to use Google to look up anything. The interviewer should not judge the candidate on looking up how basic Javascript features work. As in real life, lexical knowledge is not important. Only the result and the thought process matters.

Always prepare with at least two tasks in case the applicant has a difficulty with the first one. Make sure the second task can be solved using a different thought process. Preferably, this task also uses different language constructs. You want to give the applicant a second chance, replicating the first task serves no purpose.

While some people are relaxed, others are stressed out in situations like this. The role of the interviewer is to calm the applicant down. Make sure you shift focus away from all disturbing elements. Emphasize that there is no time limit.

This task is for the purpose of proving that the candidate has at least basic coding and problem-solving skills. Presenting a thought process, testing the solution are all important. Don’t hire someone who cannot solve any of your tasks during the interview.

If you think that someone can improve in a matter of months, it is absolutely fine to encourage rejected candidates to apply again. It is your job to create a good atmosphere, so many people will want to work in your team even more after they got rejected.

Hire the Right People

Each step in the recruitment process is there for a reason. By the time you make an offer to someone, there is little room for surprises. The application package and the HR interview reveals if the applicant is interested in joining your team, while communication skills are also demonstrated. The coding task reveals the ability to learn a new technology quickly, or master an already known technology. In addition, the solution can also be checked in terms of robustness. The coding task is usually as close to the daily activities of the team as possible, meaning that there is a correlation between how well people solve the task and how well they would do in your team. Anyone reaching the technical interview has already proven the ability to solve complex problems in practice. The technical interview reveals the thought process of the candidate, and tests problem-solving skills. Writing code during the interview also reveals generic programming skills. I am confident in hiring people passing these hurdles.