Who to Hire

No one is great at interviews until they’ve done lots of them, and even then there are no guarantees. Unfortunately, the only way you can really assess someone’s suitability to join your team is to conduct some sort of interview. Remember that this should be a conversation, not an interrogation. Different roles may require different kinds of interviews. For example, you may want to give developers some kind of coding test to assess their approach to solving particular kinds of problems; maybe you won’t need to do this if they have provided you with access to their git repositories to review or a technical blog. The problem with many interview techniques is that they test skills that are irrelevant to real working life. You want to hire people who can do the job immediately, are intelligent and motivated enough to continue to learn so that they constantly improve, and who are generally nice people whom your other team members can get along with.

Skills & Ability

Remember that the most important skill for any web professional is their ability to learn. Therefore you shouldn’t hire people based on what they already know. The worst interviews may give candidates outdated questionnaires that ask questions about obscure syntactical features of, for example, JavaScript or PHP or questions about Photoshop tools or filters. If you are looking for JavaScript or PHP or Photoshop skills and they don’t know the answer then you may think it’s a sign that they are an unsuitable candidate. But it provides you with very limited data; you’ve wasted precious interview time collecting a very narrow set of data about the potential candidate, and you’ve essentially only tested what they can remember in an interview room. Don’t over-value present skills and under-value future growth potential. The number of potential candidates with the exact knowledge you’re looking for is smaller than the number of potential candidates who are clever enough to learn what they need to know to do the job well. In a real working environment, people would have access to the web and all its information, which can and does fill knowledge gaps. There’s nothing wrong with hiring someone who takes the initiative to research or ask when they don’t know something.

The question you need to be constantly asking yourself when interviewing a candidate is “Can they do this job?” This is not the same as “Can they do this job right now?”. You have to be confident that no matter what their current skill or knowledge or experience level is, they will get better at the job. So how do you assess learning ability?

Firstly, ensure they can intelligently discuss their topic. You’re not hiring anyone on the basis of any individual nugget of knowledge but rather a complex and understanding of what they will potentially be working on. Try and find out what specific areas they know most about and ask them candidate to explain them to you in detail. Such a collaborative discussion will reveal their understanding of complex concepts as well as their ability to communicate. A designer may be able to create beautiful interfaces and a developer may be able to write complex algorithms quickly, but the job of a web professional is to work as part of a team to achieve something bigger. People who are unable or unwilling to communicate with their colleagues are only doing half their job.

Some good general interview advice is to try and make your candidate as relaxed and comfortable as possible, hopefully as comfortable as if they already had the job and were a long-standing employee. Stressed or panicked answers to questions are not reliable or representative of the candidate’s knowledge or normal state — you don’t want to hire someone who only performs under pressure.

“I am wiser than this man, for neither of us appears to know anything great and good; but he fancies he knows something, although he knows nothing; whereas I, as I do not know anything, so I do not fancy I do. In this trifling particular, then, I appear to be wiser than he, because I do not fancy I know what I do not know.” — Socrates

This well-known Socratic paradox from Plato’s Apology implies that the wisest people are those who are aware of what they don’t know. It encapsulates the scientific endeavour, and you may liken an interview to a scientific experiment. You’re putting your candidates under conditions in which you can test your hypothesis — that they are good enough to do the job.

Through your interview discussion your objective is to discover the length and breadth of their knowledge; that means finding their limits, but not goading them into failing the interview by getting things wrong nor showing off your own superior knowledge, but trying to see how they react when asked a question to which they don’t know the answer. Observing this reaction can tell you a lot about your potential candidate. Weak candidates will try and waffle, make random guesses, or make something up. It’s always obvious when someone is making wild guesses, and it’s also a sign of intellectual dishonesty — they think you won’t notice and that you’ll be satisfied with such an answer. Not a wise move according to Socrates. Better candidates will frankly admit when they don’t know and may ask questions. The strongest candidates will also offer attempts to extrapolate an answer from their current knowledge, or suggest what they would do to research the answer. They’re being honest and also showing you that they like to figure things out. Of course, in order to ensure you can explore a candidate’s limits, you need to ensure that you yourself, or the person interviewing them, surely has a huge wealth of knowledge on the subject themselves!

Experience

As well as assessing the scale of their knowledge, you need to find out how they acquired it. Someone who doesn’t constantly improve is not going to increasingly add value to your organisation. Your ideal candidate is someone with proven ability and desire to learn new skills and then apply them. Ask them about their career trajectory and how they intend to progress. Try and whittle out evidence of increasing responsibility in previous jobs, not necessarily new job titles, because that’s evidence that their expanding knowledge and skill-set have been previously recognised.

So after establishing levels of knowledge and learning ability, you’ll want to explore more the candidate’s personal style and experience level; it’s unlikely you’re going to get that information from a CV or resumé. In fact, you may as well leave such things in the 20th century where they belong. People who are impressed by academic credentials make for bad managers in the 21st century. Nowadays, higher education is more accessible than ever and so the education level of many candidates will often be almost indistinguishable, and it’s unlikely that you’ll be familiar enough with their academic institution, the details of the course the candidate took, or how much they got out of it. All you know is that they passed some exams. Asking them to provide details on their academic career is a waste of time, for a college degree or diploma, even an absence of one, is rarely a good predictor or indicator of ability as a web professional. Academics independently study theories and pass exams that only simulate real-world situations. In contrast real-world designers and developers work closely with others to plan, code, publish, and maintain software. Some people can do both well, but it’s certainly not a perfect correlation.

Another poor indicator of skills and ability is the candidate’s previous employers. Just because somebody worked at a large or famous company like IBM or Ogilvy or Apple it doesn’t mean that they were a successful team member or had any valuable contribution to the company’s most famous products and services. In fact most especially in big companies there are many teams all of which perform and work differently. Perhaps you might be familiar enough with another company’s hiring process that you can be confident that the candidate’s credentials meet your requirements, however in most cases you just need to throw out the CV and focus on the person sitting in front of you and what they are saying.

OK so the CV isn’t all bad; you do need to assess the candidate’s relevant experience. However that doesn’t mean you shouldn’t hire someone with no experience. What if the candidate has no previous experience? What if they’re fresh out of school or what if they’re changing careers or what if they’re a young and enthusiastic teenager? How do you assess their overall value? Even someone with as little as just a year’s experience doesn’t really have enough to show whether they will be any good. In this case a more traditional technical interview may be your only option. The important thing is to first establish exactly what it is that you need to know about the candidate and what they can do, then set up a test that targets those specific skills.

A popular interview technique, especially when hiring developers and people with no or little previous experience, is practical tests…. but please be careful. Writing code on a whiteboard or a piece of paper is far removed from a real-world code-writing situation. Similarly writing code, even if on a computer, within a fixed time limit is also unrealistic and not a useful predictor of style or ability. If writing code under time pressure is part of your job requirements then I’m afraid your company has a bigger problem than staff shortages. If you do need to hold some kind of practical interview, then allow people to do it at home or in their own time prior to the arranged interview. Rather than asking a developer to write some common algorithm or data structure, give them a real-world example — in this case ask them to code up a web page based on some set specifications. It doesn’t matter if they copy code from elsewhere or use 3rd party libraries and frameworks — a good engineer will maximise productivity by using 3rd party code to solve any common problems. There really isn’t any risk of cheating as long as your specifications are suitably specific. Such a test has the added advantage of being able to see their coding style and offer a point of discussion in the interview — why did they choose that library or framework? Why did they take that approach? etc. By asking your candidates to solve unrealistic problems under a time limit while at your office then how do you know they’re not just remembering someone else’s solution? There is no value in hiring someone for what they can remember in an interview room when it could be Google’d in a matter of seconds.

Personality

Lastly, after you know the candidate has the required knowledge, skills, and learning ability, you may ask yourself if they are the right “fit”. You may be tempted to hire friends or family, but this should definitely be avoided because it comes with too much baggage. Existing personal relationships will impact your professional relationships, creating biases and implicit power structures that will obstruct the smooth operation of your team. This compromises both your personal friendship as well as the success of your organisation.

There are no interview questions you can ask to establish whether someone is going to be a nice person to work with or whether the rest of your team is going to enjoy working with them. Personality is very subjective and so you will undoubtedly have an unconscious personal bias. Everyone who’s carried out interviews before will have probably noticed themselves biased towards the happier, more confident candidates, thus risking turning away potentially stronger candidates who may just need time to become comfortable with the new work environment. A common solution is to just focus solely on the technical part of the interview, the exact content of the candidate’s answers, or a standardised practical test. As mentioned above, this comes with its own pitfalls. As well as concentrating on what the candidate says, you’ll also need to focus on how they say it. Asking yourself whether you want to work with this person and whether you want to be friends with them are two different questions. The team you’re building doesn’t need to be a family, a homogenous group of craft-ale-drinking hipsters, and you don’t even need to have anything at all in common — you just need to be able to respect each other professionally and like each other enough to work together without suffering personal conflicts. There is a very small chance that all the best candidates look and behave the same or have roughly the same interests, so lack of diversity hints that your hiring policy is flawed and that you’re not necessarily hiring the best people — this may appear obvious and off putting to the strongest new job applicants. A person who could be good for your team might not necessarily be someone you would chose to be friends with. It’s very tempting to find someone who could be both, but ultimately that’s neither sustainable nor a reliable metric for team success.

While homogeneity can be so disastrous, you obviously don’t want to hire just for the sake of diversity either. You basically just need to have a “no dickheads” policy. You will come across the over-confident technical geniuses, the bitter and cynical bullies and snobs that are usually quite easy to identify in an interview through signs of arrogance, rudeness, or inattention to detail; these are personality flaws that people can rarely keep in check, even if just for a couple of hours. No level of brilliance can compensate for poisoning the morale of your team by people who are unpleasant or demeaning to their coworkers. No matter how desperate you are to hire someone, it will cost you more in the long run.

Finding the Right People

What if you can’t find the “right” person for the job? Maybe you’re not looking in the right places. Where are you posting job offers? Perhaps try a new channel, or increase the profile of your organisation through a blog or social media. Become involved in communities like hacker news or tech crunch, attend and sponsor conferences. It’s important to remember that hiring people takes time. Hiring the wrong person, especially “stop-gap” people when you’re desperate, will be more expensive long-term and wastes more time while you continue to wait for someone better. The wrong person will not only fail to perform the tasks that you require of them, they will also bring the rest of the team down, making them less efficient at performing theirs. A new hire needs training and support, and is thus a huge investment for your organisation. Can you afford to invest in just anyone?

Put time into perfecting and standardising your interview technique and be sure that everyone in your organisation giving interviews is doing them properly. It requires a great deal of thought and creativity; it’s extremely difficult, but that’s HR for you. It will surely pay off in the end when you have a stronger, happier team and can produce better work, for a better web.