Hiring an iOS developer (or any software developer) can be a daunting task. Usually when a company feels the need to hire a developer, they should already be actively looking for candidates and, more often than not, haven't started doing that. Perhaps one of the core developers has just left the company and management starts desperately seeking a replacement, or the product is finally gaining traction and the team is just spread too thin and starts falling behind on the schedule. Either way, this need for another hire is already being felt and the company hasn't even started looking for candidates.

The search begins

Getting to a single hire is the process of filtering the pool of candidates over and over until a single candidate remains. Some of these filters are, of course, what we can call hard filters. How big is your selection pool to begin with? Can you afford the hire? Is your company attractive enough for the hire? Do you share the same values? Do you require that your employees be physically present at the office? There is much competition nowadays over talented software developers and things can get dire if you are in one of two extremes: somewhere with a lot of competition (e.g. Silicon Valley), or somewhere that does not attract much technical talent. This is partially why we keep hearing more and more about remote first companies.

The whole idea of focusing first on the hard filters is to not waste anyone's time. Neither yours nor the candidate's. Figuring out these hard filters will help you set your expectations.

The selection process

There's much debate of how to effectively conduct the interviewing process of software developers. The industry standard and omnipresent whiteboard coding interview is being put into question. Whiteboard interview might actually make sense if you are hiring a college professor. Even if your candidate enjoys solving puzzles on a whiteboard, you should be testing him for something that will actually resemble the work he will be doing in the company.

Some people may believe that the whiteboard interview might at least be useful to assess their quick thinking and capacity to work under stress, but I'm not certain that would be the case. Different people are affected differently by these environments. There are countless ways for being creative about the interview process without wasting anyone's time.

Companies also have the option to conduct a (paid) trial period with the candidates. This is undoubtedly the best way to evaluate if the candidate is a good match and it also gives the candidate the opportunity to evaluate the work environment and process. The problem is that this is usually only feasible for freelancers. Developers working with other companies might not have the freedom to take a few days off to go through a hiring process.

With that being said, here's a list of some interview ideas that can be used:

Code review

Preparing a piece of code from a small application (small enough to be covered in a 30 minute session) and ask the candidate to describe the code to you and to point out possible improvements. This gives the interviewer the opportunity to see how deep are the candidate's knowledge of the platform, and how well is he able to communicate his thoughts on someone else's code. It also gives the candidate a chance to get a better grasp of the work environment (e.g. if the use of a certain library is expected, or if a certain style / convention is used).

Refactoring session

This is merely a continuation of the code review, but here the candidate takes the opportunity to actually improve the code discussed in the previous exercise. Here the interviewer will evaluate how well is the candidate able to refactor the given code and will see which tools from the IDE he uses. Not only that, but the interviewer will also gauge how the candidate navigates his work environment, what kind of shortcuts he uses, how fast he codes and what is his thought process when refactoring.

Pair programming

This session usually involves a new component or feature being created. The complexity and requirements of the task should be discussed with the candidate in advance. He's expected to bring his own notebook with his own setup (not everyone likes Xcode) and either he or a member of the team drives the session. This session shows how well the candidate is able to think about the problem, how much back and forth he requires and how well he's able to communicate with the team.

App showcase

The candidate presents an application he has created and uses it as a starting off point to discuss architecture patterns and implementation details. This is a good opportunity to understand where the candidate is coming from and how he thinks about a larger project.

Open discussion about the work environment

The candidate asks members of the team about the work process and the work environment. How are issues tracked? What is the development process? How does QA work in the company? What are the policies of working from home? All of these will play a part in the candidate's job satisfaction and giving him the opportunity to freely discuss this with members of the team might save everyone from an expensive mismatch.

All throughout the process it is also important to have realistic expectations. If you are trying to find someone to help build a product for your 4 person startup, you shouldn't expect everyone to already have experience leading a 10+ team and working with million dollar budgets. Conversely, if the product already has a stable team and is not looking to make any architectural changes, hiring an experienced architect will most likely lead to an employee seeking fulfillment elsewhere. Likewise, you might have to ask yourself whether relevant industry experience is more important than years of experience with the tools and frameworks to be used.