How to Hire Developers II
Some general tips for interviewing candidates for a dev team position. Particularly for developers who are finding themselves on the other side of the interview table for the first time.
Be sure to check out part 1 of this series to understand the fundamentals of this approach where I argue that interviewing is a skill every professional developer should have under their belt.
General Interviewing Guidelines
Interviewing a candidate can be as scary as being the interviewee. It requires a little training, training that all new members should go through and have a mentor who they can call upon if they get stuck.
Remember the 7P’s
Proper Preparation and Practice Prevents Piss Poor Performance. Read their cover letter, read their resume, re-read the application. Read any HR guidelines or documents. Prepare questions. Click their links, Google them, check out some of their Github activity, snoop around. Going into meetings without doing your homework is unprofessional and a great way to lose a great candidate to a competitor.
Choose someone equal or better than yourself
Leave your ego and fear-of-getting-fired at the door and if you are the team lead, emphasise that nobody is getting fired. Incoming developers that raise the bar benefit both the less experienced members of the team and the product itself. The new senior devs learn the domain from the junior devs, the junior devs learn the craft from the senior devs… both earn healthy respect for each other AND the company is rewarded with high quality and timely output. Everyone wins.
But jealousy, selfishness and fear are normal, if you ever find yourself thinking, “oh crumbs, this guy is a way better dev than me. If I say yes to him, I will be fired soon after, he will make me look bad!” Don’t panic, this is normal. Understand that you will not be fired, you will be praised for your selection, you will learn from the FNG and he will learn from you. Be comfortable, be confident, be cool, be professional and keep it together. The universe will reward your maturity.
Don’t make stuff up
Don’t know the answer to a candidate’s question? Write it down and follow up.
Be the perfect host
When they are in our office, they are a guest, and shall be treated as such — don’t forget the basics: food, water, toilets, wifi. If they are onsite for a very long time, give them some time alone to organise their thoughts so they aren’t fatigued or overwhelmed.
Don’t be arrogant
Be respectful, polite and kind. Always. The old days where people would beg for jobs are gone. Don’t assume that just because they applied for the job, that they will grovel at your feet and swallow whatever BS you send their way. They are there to scrutinise you just as much as you are them.
Don’t crowd them
Keep the interviews small. Sitting before a panel of judges is intimidating, they aren’t applying for parole so don’t treat them like a criminal. If you code with them, do it one-on-one, on their computer if possible. Coding in front of a crowd is going to give even the most seasoned developer sweaty palms.
Encourage questions
Be mindful that they may have questions, and ensure that you leave time enough for them to ask. Encourage questions, make sure they know that they should not be shy and that questions are, in fact, expected.
Have some fun with it
I once noticed that a candidate had “Table Tennis” under ‘Hobbies’ on his resume, since we were in the middle of an office table tennis tournament, I explained that this was a funky startup and we did things differently — meaning, in order to advance to the next round, he would have to beat me at a game of table tennis. The poor guy was nervous as hell but he put his back into the game. I beat him, though… just. As I escorted him back to the interview room, I explained it was just a joke, handed him a beer, talked about table tennis then began the interview in a very relaxed way.
Give feedback
Ask how they think the round/process went, it’s important that people are self-aware, they may have an inkling that something didn’t go so well, you can talk about it. Recognising their faults is actually a good thing. Let them know when they can expect to be contacted with a decision or update.
Get feedback
Feedback is important, not just to give but also to get. Ask them for their feedback in person, also provide them with the email address of an intermediary HR representative, so that they can give feedback honestly and failing that, encourage them to write on Glassdoor or the like. It’s important for your own development to know how you can improve.
Debrief
With your team, once you have reached a decision, give a debrief. How the process worked, bring up any edge cases you encountered and why you came to the decision. A quick 10 minute round with all the people who came into contact with the candidate and your personalised process.
Learn how to introduce the company
This is the company version of the “tell me about yourself” speech that the candidate has lined up for you when it’s their turn to talk. Just like them, you must more or less rote learn it.
What? Learn the company pitch. What problem is your company solving? What does the product do?
How? The company itself will have some core values it holds dear: diversity, work-life balance, perfection vs getting it done, respect begets respect, and so on.
Summary
Having a checklist like the one above is something you should develop for yourself and it should be a living document. Add to it, review it after each interview, think about what worked, what didn’t, and why.
In the next and final part in the series, I’ll go through some tips for designing technical test.
