We have reached part three of my "Hiring developer" series, and boy... this is a big one.

Intro

I've been in a management position for the better part of the two decades I have worked with development. From a simple team manager, with little or no influence as to whom and when I would hire somebody, up to actually hiring the people responsible for hiring people.

I'd like to say that I have a 100% record of successful hirings, but that would be a lie. Over the past two decades, both as an employee and as an employer, I've learned a lot about hiring developers, and I'd like to share with you some of my processes and ideas.

In this series of posts, I'll show you how I tackled all these questions and more, over the two decades I worked in advertising agencies.

Disclaimer: This is not a definitive guide on how to hire a developer and I am not saying my way is the only right way to do it. There are thousands of other methods, scenarios, conditions, and so forth, where my processes will not apply.

How to conduct interviews

This is a subject that always generates a lot of controversies and I plan on looking at this topic through my optics. I'll try and explain what I feel is important when I hire somebody, what I feel is essential and what I feel is negligible. Again, this is not a cake recipe that you must follow exactly, it's merely my way of doing things.

Getting ready for the interview

Resume (CV)

The resume can tell you a lot about a candidate if you know what not to look at. I know it sounds strange, but I've seen too many times in my life, people dismiss potentially great candidates for the strangest of reasons such as where the person lives, age, horoscope(?!), gender, and so on.

Work history is the first thing I look at. What has this developer done in the past and for whom? How is the text written? Spelling mistakes? Correct use of grammar and language? Is it overly formal or informal? Does it sound authentic? Grab a phrase out of the CV and google it. Is it a copy & paste off somebody else's CV? (You'd be amazed at how many times I've had positive hits).

If the work history sounds credible and in line with what you are looking for, what is the age of the developer? I mean, if he has 15 years of experience, and he's barely turned 19, you've got either a friggin genius or...

Finally, depending on the level of the job offer, I'll look into references. It is always good to have a good long hard look at these. Whenever possible, try to cross-reference the details. What I mean is, if he says John Doe was his boss at Acme, try and lookup John Doe on LinkedIn and double-check to see if his work history actually corroborates this. I've had developers put neighbors, friends and, relatives as references, with no work history what-so-ever. Double-checking references can point out some useful things.

I seldom look at anything else. Some companies have policies for only hiring people with degrees. I don't particularly like that policy, but there are times one can't really go against company policies all that much. If my company has that policy, I don't really mind where they got their degree from... I have seen people coming out of high-end universities who barely knew a line of code, and people out of really obscure and poorly rated colleges be great at anything you threw at them. I find it important to note that a CS degree is useful and I am in no way stating that going to university is a waste of time and resources, I am just saying that it may be a tad over-valued at times.

I really shouldn't have to say it, but just in the hope that this paragraph will clear up any silly ideas... You should have absolutely no restrictions, biases, preferences, likes or dislikes with regards to gender, color, religion, sexual orientation, culture or political beliefs. There is absolutely no justification of treating anybody any different because of any of these details.
If you are considering restricting your development team in any way based on any kind of discrimination, you should step down from a management position and get some help.

Getting in the mind of the developer

I have some things I rank high on my value scale. Among the top ones are loyalty, professionalism, honesty, and commitment. These all count a great deal when I'm looking at hiring somebody, especially because I want people working with me who can be trustworthy and accountable.
Even before I sit down to talk to somebody, I already try to extract some information about them. How quickly can they schedule an interview, what time they can schedule the interview, the language they use over the phone and how they respond to questions over email are just some of the things I look at.
Communication skills here are a great thing to look at. How much does the person you spoke to sound like the resume you read? How formal or informal are they? How articulate is the person?

If a developer is working a full-time job at a company, how will he sit down and do an interview? Will he, in his current company, call in sick? Will he schedule a time that does not conflict with his work hours? How quickly can he start working for me? These are all things I take into consideration even before the interview is scheduled.

An example: if a developer tells me he can't schedule an interview in working hours because he has a full-time job, I consider that a reasonable request on his behalf. I prefer somebody to tell me that rather than just skip a day at his current job.

Other things include: How quickly he can begin? If he's ready to drop his current job, what is his role in the company? What are his attributions? What's still on his plate where he works?
I've had interviews with developers who were in the middle of a project as lead developers and say they'd start in a day or two, all because of a salary bump of a couple hundred.

That kind of behavior does not inspire confidence unless it is backed with some serious reasoning. Again, it's not a conversation killer but rather a point I'll probably try to bring out during the interview. Something I would like to understand and contextualize before hiring.

I like to have an idea of who the developer is, his principles and general outlook towards work before we sit and talk. There are literally hundreds of little details you can pick up from emails and phone calls. I usually make note of the ones I feel might need some digging into and keep them as conversation topics for the interview.

Rapport (is it psycho mumbo-jumbo?)

Rapport is one of those things that a lot of people frown on. Some think it's psychology-mumbo-jumbo, others think it's a technique used by shady business owners and pick-up artists. I'll later write something on rapport since this is not the main topic of this article, but a TLDR; version for this context would be:

Rapport is established when both parties feel comfortable at exchanging ideas without the feeling of being judged or looked down on.

Where the operative word of this definition is comfortable.

I have a strong feeling with regards to my intuition. I guess in an unconscious level I do all sorts of body language analysis (I did do a lot of studying on the subject back in the day), which helps me guide the conversation.

Your posture matters

It is your job to make the developer comfortable. From how you welcome the interviewee down to how you sit at the table, it all portrays a message. A great part of that is achieved by paying attention to what he is saying. People like being listened to. If you're going to sit there with a laptop and type away when he is telling you something, you're off on a wrong foot.

Phones

There is no justifiable reason to keep answering your phone or texting people during an interview. It is disrespectful and plain-out rude to your candidate. If you do need to answer a text or a call, it should only be in an extreme situation.

I usually leave my phone on mute and face-down on the table. I also block my calendar leaving it clear I will not be answering calls or texts during interviews.

Computers

Computers can be a great tool if you want to discuss something that your developer has produced or if you want to show him some presentation or technical issue. That is it. You should not have your e-mail client, your instant messenger, WhatsApp web or anything that will potentially call your attention away from the interview. I'll say it just because... Once you have used the computer, put it aside. You are here to interview somebody, not fiddle with the notebook.

Breaking the ice

I usually start interviews with a simple introduction and asking candidates to talk about themselves a bit, and give them some pointers like: what can you say about your work? Tell me about your latest jobs, or something to that line. (I've had experiences early on where developers would tell me stories about their pets or how much they enjoyed surfing - even though some stories were even fun, they were hardly objective).

Sometimes, depending on the candidate's initial behavior (some candidate really struggle with interviews and become excessively nervous and/or insecure), I'll give them some context of the job offer, company, and me in order to make them at ease. Creating a safe initial environment is key to a productive interview.

Establishing a communication exchange

Again, I'll look at posture, general articulation, signs of nervousness and other little tell-tale signs. If I feel the developer is still insecure or worried, I'll take charge of the conversation every now and then to try and make the candidate feel more comfortable. Some respond to humor, others respond to knowing things about the current company. It's a question of feeling your way around the conversation.

With a quick back and forth of exchanges, your goals are to give your candidate an assurance that things are OK and make him comfortable enough to open up to you in a franker and less mechanical way. There are few worst things that having a candidate answer mechanically and as if he's memorized answers. In my opinion, these kinds of responses beat the purpose of interviews.

How technical to go?

I don't tend to go all geeky and technical without a context. I like to ask about past experiences, something that's on the candidate's Github (if there is one) and things like that. I refrain from pulling out a "questionnaire" full of trick questions on the languages I'm hiring for. If I cannot use any of the past experiences to validate initial technology vetting, I'll create a couple of scenarios our candidate can try to wiggle his way out of.

Usually, the higher the position, the more tech vetting I'll do, yet, I am not a fan of code challenge tests. I particularly think that a developer who can solve a problem by suggesting three or four options is usually better suited for my needs than one who can recite an entire "node js" book by heart. Again, this is my way of thinking and fits within the team profiles I usually build, where adaptability and problem solving usually far out-weigh specific technical knowledge.

Code Vetting

I usually do some sort of code test during the interview. For more inexperienced candidates (for junior positions or interns), this is usually something that will give me some insight on what the candidate knows and does not know.

When we are talking about mid-range positions, where your developer needs to know certain things, I do tend to give them a couple of scenarios to work on. These are usually tightly related to our business. I tend to keep them short and simple. The idea is less "code an answer to this" but rather, tell me how you would solve this issue. I seldom use computers during these interviews.

Test Jobs

Yes, this is a thing. I personally hate it and would never really do it, but it is something that is becoming more frequent.
The concept is: you send a briefing to a number of candidates, the one who performs the best job gets hired.
What actually happens is that companies are abusing this concept. I have had friends who did challenges like this one trying to get a job, they never got the job, but after a couple of weeks, saw their work published for one of the companies clients.

Technical aid

You are probably a manager of some sorts, and you are probably no longer obliged to know every little dirty secret of the languages you are hiring for. If you need to hire for a very specific technical position, take along a technical aid with you. Bring in one of your lead developers, properly prepped for the interview. Also, sometimes, it can help to create a better dynamic in the interview.

The same applies if you have an HR department in your company. HR is somewhat designed to excel in these situations. They can bring invaluable insights, questions and help guide the conversation, especially if you are not used to interviews.

An added benefit, you'll have somebody to bounce off ideas with once the interviews are over.

The money issue

As a candidate, I used to hate sitting down for an hour-long interview, only to find out that the company wanted to offer me well below what I was expecting. It is actually worse when you feel that you like the company because it seems that they don't value you. I also have faced situations where I was unofficially offered a position at a value, and after the interview, they tried to play down the value saying that the value was never set in stone.
Since I know how horrible it is to be in such situations, I'll make sure that the interviewed knows, beforehand, what he is applying for and how much we are willing to pay.

Money usually comes up early in my interviews - when I confirm that we are on the same page of work conditions. If there is any negotiation, it better occur sooner than later. Once I feel both candidate and I have sufficient knowledge of each other, I'll bring up money and work conditions. If the candidate is put off by anything, this gives them a clear chance of breaking free early. If they banter for more, I usually already have sufficient knowledge to know if it is worth negotiating or even if it is worth continuing with the interview.

References

For more specialist positions or for senior devs, I will always reach out to previous employers or co-workers. I usually like to do that a couple of days after the interview. This is something that can be easily achieved with Linked In.
References are, in my humble opinion, one of the best ways to learn about your potential employee. With the right questions and conversation steering, you can validate a lot of information about a candidate. This takes into consideration you've already double-checked the references in the resume.

Keep your eye on the prize

What it is you are hiring for is something that you must always keep in mind.
You must think of where the developer will be working, will she/he be part of a team? Work solo? Will there be requirements to talk to suppliers or other teams in different areas? These things are often overlooked and can lead to disastrous results.

Ending the interview

Who has never sat down for an interview and seen it's going nowhere really quickly? Or worse? Who has had such a good interview, it could go on for hours? Knowing when and how to end one is a fundamental part of interviewing. I've had developers say they thought they were not getting the job because of how the interview was ended, and I've heard people saying they were sure they were going to get hired because of how the interview ended (even though they were nowhere near getting hired).

Signal that the interview is near the end. Ask them if they wish to add or ask something that has not been covered or something to the line. Don't end the interview abruptly. It is not considered polite and respect is in order.

One thing I try to do is to end my interviews in a neutral tone. I don't like to get hopes up or down straight away. Since I probably have more people to interview, I leave it clear that there are other people being interviewed and give them a realistic idea of when they can expect an answer.

Feedback

This is something most companies are horrible at. As a candidate, you went to an interview, you got worked up, you are hopeful, waiting for what seemed to be a great interview, and then, you wait...

Answer every single person you interviewed. Starting off with the person you plan to hire. Once he is hired, get each candidate and thank them for their interest. Explain in a polite manner that unfortunately the position has been filled. If possible, write each email out individually and personally. One of the worst things is getting a generic email that is mass-mailed to you stating that the job offer has been closed. It shows no respect and consideration! Remember, you called the person for the interview, the very least you can do is be respectful.

Conclusion

OK - That was a long one. I could probably write articles on each of the main topics here, but I think I got the basics covered here. The next and final article will give a brief overview of how one should get ready to welcome the newly hired developer.