iOS coding interviews can take a number of forms, including your typical algorithms assessments that aren't even done in Xcode.

In this blog, I won’t be talking about those. I'll be talking about the kinds where you're asked to build some actual app functionality (typically with an emphasis on UI) using the iOS SDK.

I've given hundreds of these interviews, and I've noticed certain behaviors that tend to correlate with a lack of experience with the native tools and frameworks.

Don't get me wrong. No single item here is necessarily definitive. The pressure of interviews can (and does) make even the most experienced iOS engineers forget their good habits. On top of that, this list isn't exhaustive. Interviewers will be looking for other skills, depending on the role, that aren't covered here.

Rather, these mistakes tend to be fairly common for one reason or another. And if you make enough of them, your interviewer is likely going to at least question your relationship to the platform.

Here's what they are, how to avoid them, and how to give yourself a leg up – especially if you're applying for a junior role but don't want to look junior.

Don't rely too much on SwiftUI

Your goal in a native iOS coding interview is to demonstrate strength with the platform. And not infrequently, interviewers will let you choose exactly which tools you use without much guidance, in order to gain insight into your go-to choices and habits.

Unless you're applying for a role where SwiftUI has been called out as the tool of choice, you probably shouldn't rely on it too much in your implementation.

It's not that SwiftUI is inherently bad. It's just new, and, in a not insignificant number of cases, not yet suited for production development. As such, most iOS roles will still primarily or entirely be relying on UIKit to build out their user experiences, so you'll really need to know its ins and outs for at least several years to come.

Besides, I've found that those who have chosen SwiftUI in my interviews tend to be candidates who are just learning iOS development, which makes sense. Certain basics, like throwing together a list of items on screen, is trivial to implement in SwiftUI compared to UIKit, so they choose the path with which they are most comfortable.

All that said, there are still two big things to consider about your use of SwiftUI:

Fully understand delegation (and data sources)

The use of delegates and data sources is a cornerstone design pattern in iOS. They're everywhere, and not fully and intuitively understanding how and why they work they way they do can lead to train wreck's in an iOS coding interview.
For example, I've had candidates spend nearly an entire hour session struggling to make sense of how to use the delegate and data source of a table view to properly display sections and headers, ultimately getting some really wonky results finally displaying on screen.

Utilize platform-specific helpers

Few things scream "amateur" more than trying to reinvent the wheel when you don't have to. And that of course goes for all of software engineering, not just iOS. It's a waste of precious (and expensive) dev time, not to mention typically introduces bugs.

In iOS interviews, this usually manifests as not utilizing some extremely well-developed and feature-rich API Apple provides in favor of rolling one's own naive solution, one of the most common examples of which is formatting data.

It's best to familiarize yourself with basics like this prior to the day of. They're not that hard to understand, but the pressure of the interview makes everything harder. Take a little time to refresh your memory on helpful tools like this, and you'll find yourself coasting and signaling a solid embrace of the tools at your disposal.

Don't ignore cost and performance

iPhones and iPads just keep getting faster, with the line between mobile devices and the Mac diminishing with each release and custom silicon improvements. On top of that, many iOS apps only deal with a limited amount of data on device at any point in time, so iOS engineers aren't always thinking about asymptotic performance as a front and center concern like other kinds of engineers may be.

But as iOS engineers get more experienced, they start to pickup on a variety of performance concerns and quirks specific to mobile development that novice engineers tend to ignore.

For example, let’s imagine we decided to use a date formatter to display a string in one of our table view cells. This happens a lot:

override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        
        /// Dequeue the cell
        let cell = tableView.dequeueReusableCell(withIdentifier: "reuseIdentifier", for: indexPath)

        /// Format the date
        let formatter = DateFormatter()
        let today = Date()
        formatter.dateStyle = .short
        let dateString = formatter.string(from: today)
        
        /// Apply to the cell
        cell.textLabel?.text = dateString
        
        return cell
}

While this works, it's a bad look, and many of you know why.

Formatters are expensive. All that magical, internationally-compatible functionality means there's a lot going on internally. And in this code, we have a new one being created every single time a cell is being configured! Instead, you want to create the date formatter once and store it somewhere it can be merely accessed repeatedly. Like so:

private static let dateFormatter: DateFormatter = {
        let formatter = DateFormatter()
        formatter.dateStyle = .short
        return formatter
}()
    
override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        
        /// Dequeue the cell
        let cell = tableView.dequeueReusableCell(withIdentifier: "reuseIdentifier", for: indexPath)

        /// Format the date
        let today = Date()
        let dateString = Self.dateFormatter.string(from: today)
        
        /// Apply to the cell
        cell.textLabel?.text = dateString
        
        return cell
}

Ignoring details like this can signal one of two things: Either you're too inexperienced to know that there's a problem or you're experienced but careless. And while you may be trying to save time in the context of the interview, your interviewer may or may not give the benefit of the doubt.

It generally benefits you to not gloss over details like this in your implementation, unless you at least verbally explain that you are doing so to save time.

But if you happen to be on the junior side, that's ok. Interviewers don't necessarily expect perfection, particularly if you're applying for a more junior role. That said, if you're junior and able to demonstrate awareness and effort around at least some of these nuances, that can help you stand out as a generally thoughtful engineer who's ripe for growth. Do some research, talk to senior engineers about common junior mistakes, and you'll pickup most quicker than you think.

Know the quirks of your UI paradigm

If you're asked to build some native iOS UI, there's five ways you can do so at this point:

1. Purely in code using UIKit
2. A combination of code and nib files
3. A combination of code and storyboard files
4. SwiftUI
5. A mix and match of any of the above

Whichever you choose for the interview should be very familiar to you, including all of its little quirks and gotchas.

For example, I've interviewed candidates who were most familiar with building UI in code with UIKit but wanted to use storyboards for the interview to "save time." Seems like a reasonable idea, right? Not necessarily. Those same candidates ended up running into unexpected (and really basic) hiccups that actually burned more time than they otherwise would have, while also making them appear weak with the tools.

Consider the differences in the way you register cells with a table view:

If you misuse any of the above, your cells are not going to show up in the table view. And if your interviewer is not allowed to give hints, it could take you the entire coding session to notice a really sneaky issue like this that you may or may not have ever run into in the past because you don't have experience with the allegedly "faster" paradigm.

Here's the thing. Since I've interviewed hundreds of candidates, I knew stuff like this happens, and I was sure not to give it too much weight. But you're more likely to have an interviewer whose performed an order of magnitude fewer interviews, and you could find yourself being harshly judged for what is ultimately a total fluke.

In short, don't make last minute decisions about UI paradigms based on erroneous data about what's "faster" or "better for interviews." If you choose a paradigm, get fully up to speed before using it in an interview or go with what you know.

Make some effort to separate concerns

Coding interviews can be contrived, and it can be confusing how much effort you should expend applying best practices, especially when there are significant time constraints.

While you should definitely check your perfectionism at the door, you shouldn't go to the opposite extreme.
That is, some candidates think it’s a good idea to completely disregard any semblance of project structor or organization in favor of shoving everything in a single file to save time.

This is usually not the way to go.

On one hand, I'm a big proponent of taking shortcuts to be strategic about time so long as you verbalize your rationale. For example, it's totally reasonable (from my perspective at least) to tell your interviewer that you'd normally have a separate view model for your view controller but that for now you're going to lean on a simpler MVC pattern to save time.

On the other hand, there’s entirely forgoing model classes, creating massive view controllers, and declaring every class in a single file borders on chaotic. Even if you give your interviewer a heads up about what you're doing, too many verbal exceptions makes it hard to follow your code and make a positive holistic evaluation. It might also backfire in terms of saving you time as well. It actually requires effort and conscious thought to go from writing readable code to rushed- through slop.

The idea is to strike a balance. And if you can, use a combination of verbal comments and actual code to communicate to your interviewer that you understand and appreciate foundational architectural patterns like MVC, MVVM, or whatever flavor you think is appropriate for the problem. Disregarding this completely can give the impression your production code might also be like the wild west, which is not something you want to be aiming for.

Next steps

The above examples are just some of the things that can give the impression that candidates lack experience with the native iOS tools and lead interviewers to question your performance and ability in production. That said, I want to emphasize that these are just signals that may or may not ultimately lead to giving such an impression. I've had candidates do things like this while also blazing super fast and revealing other advanced techniques, making it obvious they were competent and merely optimizing for speed. On the other hand, I've docked candidates points early in an interview for getting stuck on something insanely basic for a large chunk of time and make little progress only to discover they're great at later parts in the interview. The goal with these tips is to simply help tip the scales in your favor and avoid giving negative signals that are fairly avoidable with a little prep. You shouldn't obsess about being perfect, but a little awareness (and prep if you're junior) can go a long way to getting the interview results you want.