How to avoid looking junior in an iOS coding interview

This article first appeared on the Triplebyte blog and was written by Joseph Pacheco. Joseph is a software engineer who has conducted over 1,400 technical interviews for everything from back-end, to mobile, to low-level systems, and beyond. He’s seen every quirk, hiccup, and one-of-a-kind strength you can think of and wants to share what he’s learned to help engineers grow.

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.

Related: Should I use SwiftUI in production. Here's a code-to-code breakdown to help you decide.

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:

• If you are in fact new to iOS, and are only experience with SwiftUI, then an interview should not be the place where you're newly grappling with UIKit and you should definitely choose SwiftUI. Just start learning UIKit asap so you're ready when your next round of interviews comes in a few months time.
• If you're experience with UIKit but just want to signal that you're tech-forward, use UIKit as your foundation and implement one or two component views in SwiftUI and bridge to UIKit. Just make sure you're extremely familiar with UIHostingController so you don't find yourself burning precious minutes wrapping your head around the nuances. If you're not there already, verbally mentioning you might consider doing x or y in SwiftUI and proceeding in UIKit is better than risking getting derailed.

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.

Even if you agree with this WWDC video that says classic data sources and performing batch updates "are old and dead," you should still understand these concepts in case you’re asked to fix broken code or build your UI without the new and improved diffable data sources. That said, you should definitely start learning how UITableViewDiffableDataSource and UICollectionViewDiffableDataSource work since they're far and beyond the better way to feed table views and collection views in 2020.

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.

In iOS, we have these magical Formatter objects that give a million options for formatting numbers, dates, masses, lengths, energy and more — all in a way that adjusts based on the user's international locale settings. Yet, candidates will often attempt to format dates manually as if they're learning about strings in an undergrad CS class. And some who know to use these formatters might still struggle to use them correctly, reasoning through the basics of these classes during the interview.

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're using only code, you'll call tableView.register(CustomTableViewCell.self, forCellReuseIdentifier: "customCell") to register your custom cell class with the table view.
• But if you've laid out your cell in a nib, you'll need to register the nib instead with tableView.register(UINib(nibName: "CustomCell", bundle: nil), forCellReuseIdentifier: "customCell").
• And further, if your cell is laid out in the storyboard, the reuse identifier needs to be defined there.

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.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.