Interviewing iOS Devs — Hunting Unicorns

Out of the 12 years I’ve been programming professionally, I’ve spent about 7 of them interviewing new hires. For 3 of those 7 years I’ve been interviewing iOS candidates. I have to say I find it very hard to interview iOS developers. The techniques are all the same but the subject matter is always different. It can feel like looking for the most basic of skill sets is a hunt for a unicorn.

However I have learned some things to make it easier and from talking to colleagues and friends it seems like this information might be useful for other people when their boss lands them with the job of hiring their smarter, faster, stronger replacement.

Why is interviewing an iOS developer so hard you ask? It’s down to a number of factors. Apps are as different as chalk and cheese. A developer with 2 years experience in using core data might not have the same knowledge as one with 2 years of consuming restful APIs or one who has spent 2 years creating kick ass 3D games. Someone working in a big company might get silo’d in to a specific skill set or someone working in start up might be a jack of all trades and master of none.

As of June 2015 there are 1.5 million apps on the App Store.

Combine this with the 70+ different frameworks contained in the iOS ecosystem and there are a lot of silos for people to sit in.

Finally add in to the mix a knowledge of Interface Builder, build automation, languages, analytics, security, usability, push notifications, design patterns, source control, ticketing systems, Instruments, ASO and on and on and on. It starts to become very clear that it’s hard to learn everything you need to about a potential new hire simply by talking to them for one hour in a relatively stressful situation.

Where to start? Decide the level of developer you want and the experience you want them to have. Next do the job specification and highlight anything in it that you want to be a requirement and anything that would be nice to have. Nice to haves are things they might know but if they don’t they could learn to do it. Unit testing or GIT are things that can be learned and are therefore nice to haves.

Next check with recruiters or your HR department how much of a budget you have and then compare that to market rates. You can easily get market rates in your city with a simple search on the internet for something like “salary review 2016” or “salary survey 2016”.

Now you have a good understanding of the type of candidate you’re looking for and the cost, start working out some questions or topics that you can discuss in the interview process. The main goal of the interview is to determine the candidate’s experience, their level of knowledge, their capacity to learn, how they work and if they are a good fit for the current team.

Questions can start out general and then get more specific. You’ll develop your own style of questions after you’ve done a couple of interviews. My preference is to ask open questions and then drill down to more specific questions from the open questions. For example instead of asking someone the difference between bounds and frames I’ll ask them about the last project they worked on, how did they organise the project, what was the most difficult part of it, what did they learn from it? As the candidate is answering the open question you can ask specific questions about coding like did they use protocol orientated programming, or how did they implement size classes and autolayout.

This open-to-specific questioning allows you to really split out candidates. It’s very hard to waffle in depth about something you haven’t done and if they can’t talk about the most recent project they worked on in depth then something is up.

Judging and comparing people is hard. Remembering how you judged and compared them is harder. In order to get around this I keep track of all the things I ask people in a spreadsheet and use this to compare them. If you don’t ask everyone the same topics you can’t be sure that one person is better than the other.

If you think judging people is hard wait until you start judging if they can code by talking to them and trying to assess the level of knowledge they have by that alone? This is where the practical test or hands on white boarding makes an appearance. You can quickly judge someone’s skill set and how they work from this. Bear in mind that people are busy and have private lives so keep the task as something basic that everyone can implement at different levels but with enough scope to allow them to shine.

I find this the hardest part to be fair. I’ve recently come to the conclusion that all developers should just be dumping all their toy apps and research projects on GitHub and then this can be used as a portfolio for interviews. I’m being a slight hypocrite here as I don’t do this but I hope to rectify that over the coming months.

In summation these are some of the basic rules I try to follow when interviewing:

  1. Don’t be a dick
  2. Don’t waste the interviewee’s time
  3. Cultural fit doesn’t mean they have the same interests as you

As well as this I follow a basic structure for the process:

  1. 15 minute phone call to explain the role
  2. Take away project to be done in the candidates spare time
  3. Face to face interview

You will get better with every interview you do and the more developers you work with. Just remember to keep your mind open and don’t judge people by their colour, creed, sexuality or gender and you’ll end up hiring stand out colleagues.

Show your support

Clapping shows how much you appreciated Peter Lafferty’s story.