How to Prepare for an iOS Interview

In the fast-paced environment of Swift and iOS development, chances are you could be preparing for a technical interview. Many a blog post has been written about surviving the gauntlet of the dreaded whiteboard. Having had the chance of hiring technical resources as well as being an “interviewee”, I’ve easily passed through some experiences and have been totally unprepared in others. This essay will provide some tips to hopefully make your next iOS technical interview a positive experience. 



If you’ve been asked to interview, you’ve probably already met with one or a few members of the hiring team. As with other standard interviews, the goal during these early rounds is determine your “personality fit”. Are you likable, reasonable and provide the appearance of working well with others? The real anxiety begins when your coding skills are assessed. The fear? The potential of being asked something you haven’t heard of, didn’t study enough or have no experience in. This is especially true when it comes to algorithms and data structures



To start, let’s break down the iOS technical interview into its individual components. Building any workable app requires at least 3 areas of expertise. These include an understanding of the programming languages (e.g. Swift, Objective-C) frameworks (e.g. iOS SDK) and tools (e.g. Xcode). In addition, there are many subjects tangential to core development that are considered best practice. Many of these are outlined in my iOS Interview Worksheet. Beyond basic algorithms, additional topics include unit testing, cocoapods, the build process, core data, push notifications, cloud based services etc..



Like with anything new, the best way to tackle a subject is to determine how it can be applied towards a goal. Many readers of the Swift Algorithms Book comment how it helps them reinterpret problems they’ve been stuck on. Working through tough problems is same objective of a technical interview. As a result, anticipate (at least) three to four questions that will review the different areas needed to build an app. The depth and complexity of each problem will vary based on the organization. A good rule of thumb? Plan at least 20 minutes to 1 hour to work through each question. 


If you’re not actively working on a project, stretch your skills by contributing on Github. With thousands of projects available through the open-source network, it's free and easy to brush up on valuable skill sets including Swift and source code management. Since Swift is also open-source, be sure to understand the Swift proposal / review process, API design guidelines and impact of major events like WWDC.



Nervous? Start with the basics and download the interviewing company’s app. This simple step can pinpoint your interview efforts by helping you focus on specific iOS frameworks (e.g, MapKit, CoreLocation, CoreAnimation) beforehand. If the company doesn’t yet have an app, research their vertical market and / or competing services. At the very least, doing your homework will arm you with (intelligent) questions that can be used throughout your experience. 


As the interviewee, a (hidden) advantage you also have is time. It may come as a surprise, but many top-level companies don’t hire based on specific salary requirements or timeframe. As a result, they are willing to grant candidates weeks or even months to prepare for a major technical interview. Use that time to your advantage. 



Regardless of the solution, much of it boils down to being able to present information on a screen. As a result, understand the UIView lifecycle and supporting technologies such as AutoLayout and Storyboards. Knowing the basics of Model-View-Controller, IBAction / IBOutlet, UIViewTableViews, Recognizers and GCD (Grand Central Dispatch) will also demonstrate your proficiency with managing application state and presenting data. 



Without a doubt, the biggest drawback to interviewing is having to endure the process without the aid of a computer. As developers, we know a good portion of our work is dependent on awesome tools like auto-complete, StackOverflow and Google. The workaround? Develop experience explaining concepts on paper.  

As you work through the details, don’t worry (initially) about memorizing the latest Swift syntax. Smart interviewers know this information can be easily obtained online. Instead, focus on what models could apply given a particular scenario. For example, learn when to apply generic models like hash tables and / or graphs versus iOS-specific patterns such as key-value observation or delegation. Finally, know how to express your ideas through Big O Notation as well as UML (unified modeling language), as doing so will remove any consideration to programming language or coding syntax.



How can we use these points to actually solve coding questions? Let’s begin with this common framework:

1. Ask clarifying questions
2. Create a conceptual diagram
3. Express a brute force solution in pseudocode
4. Refine your solution with workable code
5. Check for errors or omissions


Much of the anxiety created during interviews is when candidates fail to immediately see a codeable answer. Before diving in, be sure to take a step back and make sure you fully understand the question. It may seem counterintuitive, but many times interviewers know it may not be possible for candidates to write a coded solution in the time provided. 


As a result, people may be more interested in seeing how you handle yourself when faced with a difficult assignment. Can you methodically deconstruct a problem into its individual components and test your hypothesis before attempting to write production-level code?  Interestingly, the steps for answering technical interview questions can also be used for writing entire apps.



Liked this essay? I'm currently expanding my catalog of iOS resources to include more about iOS technical interviews. This will include hosting a live webinar presentation. If you’d like to be notified when the event becomes available, just complete this quick three question survey

Posted on March 11, 2017 .