Interviewing without wasting anyone's time

Finding the right person to hire is tough. You need a process that is thorough enough to satisfy you that you are making the right hiring choice, but also quick enough to ensure that you don't let the best candidate slip through your fingers to more nimble companies.

This post will guide you through a 4-stage interview process and demonstrate how to strike a balance between thoroughness and efficiency.

The interview process below is designed to hire a domain expert, rather than a general software engineering interview.

4 Stage Interview Process

This interview process has 4 stages:

1. Introduction Interview
2. Technical Interview
3. Coding Challenge
4. Wider Team Interview

At each stage, the candidate should only proceed to the next stage if there is certainty that they have passed the current stage. It is better to discard potentially good candidates than to hire a bad one.

At each stage, remember to leave some time for the candidate to ask questions - they are assessing the company as much as you are assessing them.

Let's examine each stage in detail.

Introduction Interview

Time: 30-45 mins
Purpose: Checking for any immediate red flags
Interviewers: 1

The Introduction Interview is the first opportunity we have to speak with a candidate. Ideally, this interview should be light. The first half of the interview should involve asking the candidate to walk through their CV, highlighting any experience that is especially relevant to the role. The second half of the interview is our chance to discuss the interview process, sell the company as a great place to work and answer any questions the candidate might have.

Technical Interview

Time: 90 mins
Purpose: Checking that the candidate has the relevant technical and communication skills
Interviewers: 2

The Technical Interview should cover a range of topics related to iOS. It is an attempt to gauge a candidate's proficiency with the technology and also gain insight into the candidate's broader software engineering knowledge. Rather than aiming for the candidate to hit predefined correct answers, a worthwhile technical interview should have enough flexibility to allow the candidate to delve deeply into what they know best.

Potential topics to cover:

• UI
• Networking
• Data Persistence
• Multithreading
• Testing

I always ask the candidate to treat me as if I were a junior developer on the team. Framing the interview in this manner puts the candidate in a chatting mindset. We aren't just assessing the candidate's technical expertise here, but also their communication style (especially when discussing trade-offs) and their ability to handle being challenged on different approaches. It is magnitudes easier to help someone fill in a gap in their knowledge than it is to change someone's personality, so interviewing only for technical expertise isn't enough.

Below is a sample of the types of questions that could be asked for each topic - this is by no means an exhaustive list of topic questions.

UI

Reason to ask: To our users, the app is the UI.

Potential question to ask:

• Do you use Storyboards to build your UI?
• How would you populate a UITableView?
• What does the responder chain do?
• Contrast MVVM against MVC?
• How would you ensure the UI is accessible to all?

Do you use Storyboards to build your UI? is a great question to get the candidate speaking about trade-offs.

Networking

Reason to ask: Networking is key to the functionality offered by most apps.

Potential question to ask:

• What is HTTP and how does it work?
• How can you use NSURLSession to make a network request?
• What is OAuth 2.0?
• How does certificate pinning help to keep our users safe?

What is HTTP and how does it work? is a great question for assessing the candidate's wider software engineering knowledge and can often lead to questions about other communication protocols.

Data Persistence

Reason to ask: Users expect an app to be usable regardless of their network connectivity.

Potential question to ask:

• What options do you have to persist data between app launches?
• How can you store sensitive user data securely?
• How could you cache an image?

How could you cache an image? is a great question to get the candidate to discuss how they would design a component/service that could be used app-wide - there's a lot of opportunity here to critique and challenge their solution.

Multithreading

Reason to ask: A non-responsive app feels broken. To prevent this impression, work needs to be shifted off the the main thread.

Potential question to ask:

• What is the main thread?
• How does GCD work?
• If the iPhone only had one core, would everything need to run on the main thread?
• What issues can occur when accessing shared mutable state from different threads?

What issues can occur when accessing shared mutable state from different threads? is a great question, as you can do a remarkable amount of iOS work without ever grasping the dangers of having non-thread-safe state. This type of nuanced question provides excellent insights into how experienced the candidate is regarding system design.

Testing

Reason to ask: Nothing is more effective at turning your user into your competitor's user than your app misbehaving.

Potential question to ask:

• What is a unit test?
• How does writing automated tests affect how you structure your code?
• How does dependency injection support unit testing?
• Is TDD worthwhile?

How does writing automated tests affect how you structure your code? is a great question to get the candidate to discuss concepts like decoupling code, encapsulation and test doubles.

Coding Challenge

Time: Max 6 hours
Purpose: Chance to see if the candidate can walk-the-walk as well as talk-the-talk (the Technical Interview)
Interviewers: 1 (to assess the Coding Challenge when completed)

If you are unsure how long the Coding Challenge will take, complete it yourself. If it's taking you more than 6 hours, considering your extensive knowledge of the domain and lack of pressure, you can be sure it will take the candidate much longer and needs to be reduced in scope.

When designing your Coding Challenge, avoid ambiguity as this will cause some candidates to overcommit while penalising the time-poor. Instead, provide clear instructions on what you want the candidate to do. For example, you might ask the candidate to:

"Build a single-screen app that fetches data from www.example.com/codingchallenge and displays it in the UI shown above. This project should be designed to be unit testable but there is no need to implement the unit tests."

This small app would allow you to assess:

• UI building and which architectural pattern was used.
• Making a network request and handling its response.
• Handling multithreaded code.

An important consideration with the Coding Challenge is that while it provides invaluable insights into the candidate, it is a time-sink (especially for candidates interviewing with other companies). So I always give the candidate the option to share a Coding Challenge they've already completed for another company or an open-source project that roughly covers these areas I want to assess. The best candidates are snapped up quick, and we don't want them having to complete another Coding Challenge to be what puts them off joining us 🐊.

Wider Team Interview

Time: 60-90 mins
Purpose: Assess their communication style, especially in terms of being able to frame their responses to fit the interviewer's domain
Interviewers: As many as required

A round-robin style interview where the candidate gets to meet the wider team (one at a time). This interview stage gives the candidate a chance to share their experience of working within a wider team and also allows them to gain insights into how the iOS team fits into the wider company.

At the end of this interview, each person who meets with the candidate should have the opportunity to express their views on the candidate and vote on the hiring decision.

Closing the loop

Throughout the process, it is essential to respect the effort the candidate has put in - you are not owed their time. The best way to show this respect is by providing detailed, actionable feedback on their performance, especially for candidates who don't receive an offer. We should aim for every candidate to have a great experience, as you don't know how someone will develop, and a candidate who came up short this time might be the ideal candidate next time. If they didn't get something from the interview process, they are unlikely to reapply.

As well as providing feedback, it is also helpful to ask for feedback on how the candidate found the process. Be cautious with this feedback, as people who have just been rejected/accepted are not always the most clear-headed; however, trends can still be extracted from even the most damning/gushing feedback.