Interviewing without wasting anyone's time

Over the course of my career I've had the opportunity to experience interviews from both sides of the table and my understanding of what a good interview is has evolved with each interview that I'm part of. In my present role I was given the role of defining our interview process so this post is about the process we have settled on - at the moment.

More processes 😔

In an ideal world, a company would ask each candidate to come in and undertake a trail period performing the role that if successful they would fulfil. That way the company could clearly access the candidate's talents and determine if they would be a good fit. This would also allow that candidate to determine if the company was a good fit for their lifestyle. However this process while a nice theory fails in reality due to a number of reasons that I'm sure you good reader can easily think of. So with the ideal solution being impractical we need a way to determine how good a candidate is without actually seeing them in the job - this is were the interview comes in. The interview allows us to relatively quickly determine if we think that a candidate would be able to fulfil the role and be a good fit for the culture of the company - effectively informed-gambling. While it is fairly easy to ask someone questions it is surprisingly difficult to ask someone questions that allow you compare them against your needs, draw out their experiences and assess one candidate against another.

Let's get talking

At my present company we have come up with an interview process that involves 4 stages:

1. HR/Introduction Interview
2. Technical Interview
3. Coding Challenge
4. On-site Interview

HR/Introduction Interview

This is conducted by someone from HR and is part culture-fit and part sales (selling the company to the candidate) call. What's important is you feel that the candidate would be a good fit for the company by having them discuss their past experience, what they learnt from those experiences and what they are looking for in the future. And if it's done way, instil an excitement in the candidate that this would be a great company for them to be part of.

Technical Interview

The technical interview covers a range of topics related to iOS and ideally should be conducted by 2 iOS developers from your team. It is an attempt to get know how prolific a candidate is with the technology and also gain insight into the candidate's wider software engineering knowledge. To this end the content of the interview changes depending upon the candidate's answers however the following topics are where I normally attempt to drive the interview:

• Data structures
• Networking
• Persistence
• Multi-threading
• Memory management
• Design patterns
• QA

(Depending on your requirements the above topics should be different)

Especially important during this interview to have the candidate describe when they used a technology and why they used that technology - detailing the trade offs involved (this is especially-especially important as very few problems have a 100% accepted way of solving them).

Data Structures

The topics that (can) come up here are:

• Arrays
• Dictionaries
• Sets
• Binary Search Trees (rarely)

This is very much a warm up question and what I'm looking for here is to put the candidate at ease and get them to talk about a data structure that they are familiar with (the candidate chooses the data structure to speak about) and at the end, have them contrast that data structure against other ones.

Networking

The topics that (can) come up here are:

• HTTP (maybe even TCP/UDP)
  • Verbs
  • Headers
  • HTTPS
• NSURLSession
• NSURLConnection (if the candidate brings up NSURLConnection we normally also speak about NSURLSession)
• AFNetworking

Networking is such a vital part of an iOS developers toolkit that I would expect even a developer who develops stand-alone, non-networked app to be able to answer the HTTP part of this topic if not have a passing knowledge in the more framework related topics.

An especially interesting conversation can be around adding a dependency like AFNetworking to your project and the trade-offs involved in doing so as well as what tools exist out there to add dependencies.

Persistence

The topics that (can) come up here are:

• Core Data
• NSURLDefaults
• Keychain
• File system

Persistence is a vast topic so I'm focused here on discussing the frameworks provided in iOS rather than e.g. how the disk is organised. I tend to begin by asking the candidate to name some options for persisting data between app executions and then delving into the options and exploring when the candidate would use one over the other.

Multi-threading

The topics that (can) come up here are:

• NSOperationQueue
• GCD
• Core Data (again)
• Multi-core processors

An especially interesting part of this topic can be a listening to the candidate describe when they use NSOperationQueue over GCD and vice-versa.

Memory Management

The topics that (can) come up here are:

• ARC
• MRC
• Garbage collectors
• Retain cycles

I sometimes feel that this topic can be unfair on post-ARC developers who never had to deal with MRC however it underpins so much of what we do as iOS developers that I believe even a passing knowledge in MRC vs ARC is important.

Design Patterns

The topics that (can) come up here are:

• MVC
• Singleton
• Delegation

Similar to the Data Structures topic, here the candidate chooses a design pattern that they are comfortable with and describes what is and when they have used it.

QA

The topics that (can) come up here are:

• Unit testing
• Integration testing
• Manual testing
• Dependency injection

The apps that we produce now as increasingly sophisticated and our user's are increasingly dependent on them, as developers we can no longer ignore QA and as such I would expect all candidates to have at least a passing knowledge in good QA practices.

Coding Challenge 🤖

Depending on the candidate the coding challenge will sometimes come before the Technical Interview however I always prefer to have it after as I can use the questions in the technical interview to cover the topics that the coding challenge will also cover (hopefully to make it easier for the candidate). The coding challenge itself should be as small as it possibly can be but allow you to be able to determine the level the candidate is at. Ideally the completed challenge should be shared via GitHub to allow you to also look through the commit history. The challenge itself should take no longer than 5-6 hours and here I mean 5-6 hours for the candidate. If you are not sure how long it will take, complete the coding challenge yourself, if you find it's taking you 5-6 hours with all of your insider knowledge of the domain you can be sure it will take the candidate much longer. Remember a candidate will probably be interviewing with a number of different companies that you are directly competing against those other companies for that candidate's time. Depending on your requirements the following topics will change but what I'm looking for is an implementation containing:

• Networking
• Persistence
• Multi-threading

This takes the form of retrieving data from HTTP endpoint, parsing it into Core Data on a background thread and presenting it in the UI.

On-site Interview

The on-site interview is a chance to invite the candidate to the office and get them to meet your wider team. Topics covered should contain:

• Cultural fit
• Team working
• Cross platform experience
• Feedback on the coding challenge

Ideally the candidate should meet a range of different people from as many teams as the role the candidate is applying for will interact with. At the end of this interview, each person that meets with the candidate should get the chance to explain their views on the candidate and vote on the hire decision. On flip-side this is also a great opportunity for the candidate to see what the office environment is like: is there a dress code, does each employee have enough space, is it too noisy/quite, etc. As a company you don't want someone to join who then quits shortly afterwards because they can't come to the office in flip-flops (yes, the candidate could ask about the dress code but something like noise level can only be determine when you are in that environment).

Try not to be a pompous ass 😕

It's important throughout this process to only proceed with a candidate if they definitely pass that interview stage. If you proceed with a candidate who you are unsure about you are not only wasting your time but also the time of the candidate. Remember the candidate has given up their spare time to come and learn about your company, meet your team and be quizzed by you so it's important to ensure that at each stage you give the user feedback on how they are doing. I just want to re-emphasise that point: high quality feedback will set your company apart from the other ones that the candidate is interviewing with and give them a sense that coming to work with you will allow the candidate the opportunity to really grow as a developer. This feedback should also give the candidate the opportunity to give their own feedback on how the interview went, remember they are interviewing with a number of different companies so should be able to accurately assess your process (keep in mind that the candidate may be feeling hurt/rejected if you didn't proceed with them and this could cloud their judgement). I'm sure we have all be on the end of a bad interview experience where the interviewer didn't know the subject well or seemed to be more interested in showing how smart they are by asking trick questions - by getting as well as giving feedback we can help to avoid being this type of interviewer. Even candidates that fail the interview should have a great experience as you don't know how someone will develop and that candidate could be ideal for a position in a few years time - if they don't have a good interview experience they won't re-apply.

What do you think? Let me know by getting in touch on Twitter - @wibosco