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.
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".
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.
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
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.
- 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
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.