A Take on iOS Developer Interviews

If you’re on the prowl for an iOS developer position, you’re bound to come across a wide range of interview styles. If you ask around, you’ll probably hear about how terrible most of them are. It’s widely agreed upon in the software development industry that interviewing generally sucks. Most of us have probably walked away from an interview in our career feeling frustrated, unheard, or simply written off as not good enough — not getting a fair shake.

Interviewing is challenging on both sides of the table. As the interviewee, you may be full of angst and unable to think as clearly as you would in your preferred working environment. As the interviewer, you need to respect the time of the person interviewing while making sure you’ve covered all of the topics you want to cover. As the interviewee, you might be juggling multiple potential employers and spending a significant amount of time on each. As the interviewer, you are probably considering multiple candidates, with limited time to figure out what sets each person apart.

While the interview process for a developer includes many aspects, such as “culture” fit, compensation, benefits, etc., this article focuses on the technical screening portion and offers advice for both interviewers and interviewees.

Our Process

We at MartianCraft have spent a considerable amount of time fine-tuning the interview process over the years, and through this constant evolution we have come up with a fair approach that we are proud of. We’re not going to describe our process in its entirety here, so that you can come in and knock our socks off with your inside knowledge, but we do want to highlight our approach to the technical portion of our interviews.

The overarching theme of our interview process is “having a conversation.” This happens remotely, as we’re a fully distributed team, using a service like Zoom that provides audio, video, and screen-sharing capabilities.

All candidates who make it to our technical screen are asked to bring some piece of code or a project to discuss. This can be anything the candidate is familiar with: a personal project, a real-world project they’re allowed to show us, a few snippets from a project, or even an open-source project they’re familiar with. On our side, our lead and secondary interviewers come prepared with a checklist of topics we’re interested in seeing the candidate’s experience with.

Once we get connected and introduce ourselves, we dive straight in, letting the candidate lead the conversation — walking us through what they find most interesting about what they chose to share. The interviewers are both on the call, diligently taking notes and marking off items on the checklist. The lead interviewer will often ask clarifying questions and sometimes direct the conversation to a part of what the candidate is sharing that sticks out to them as interesting.

This conversation generally takes up 20 to 30 minutes of our allotted 1 hour time. The intent is to provide the candidate with a way to showcase their abilities and expertise in — we hope — a lower-stress environment than what we’ve found ourselves in when interviewing in the past. “Live coding” or “whiteboard coding,” where we watch you write code on the fly, is not what we’re interested in seeing. None of us do that as developers at MartianCraft, therefore we have no interest in seeing how good you are at it.

As mentioned, during this conversation we are marking off topics of interest that we feel have been sufficiently covered. When we feel a topic has not been covered, we may follow up with high-level questions to gauge experience. This is not a perfect way to assess someone’s experience with what are often wide-reaching topics, but we are trying to respect the candidate’s time.

As we hope is the case in all interview processes, we make sure to end the conversation with time for the candidate to ask questions. Given that this is a technical screen with individuals who would likely be peer developers, this gives the candidate an opportunity to get a feel for the day-to-day life of a developer at MartianCraft. We also like to gauge what is important to the candidate through the questions they’re asking and get a feel for how interested they are in the position and MartianCraft. We welcome any questions the candidate may have and do our best to answer with as much transparency as possible, though of course it’s not always possible to answer client- and project-specific questions.

Depending on how our conversation goes, we decide after the interview whether to ask the candidate to complete a brief “take home” project, where they’re instructed to add a feature or two to an existing codebase. This is done without any supervision and in their preferred working environment; once it’s complete, the candidate submits a pull request to an assigned GitHub repository.

At the end of the day, we are most interested in talking about the technology the candidate will be working on — no tricks, no gimmicks, no puzzles. While we don’t believe there will ever be a perfect interview process, we certainly don’t want to create a bad one. Admittedly, our process is not perfect and has failed us a few times. More often than not, however, the process succeeds and guides us to exactly the candidate we’re looking for. And it’s an ever-evolving process that we constantly re-evaluate and check ourselves on — we are always hyper-aware that the process can (and will) fail, and we know we have to account for those failures in the process itself.

We are extremely conscious of the time and emotional commitment that candidates put forth when interviewing with us. While we feel that our process is respectful of a candidate’s time, we recently started compensating any candidate who completes the take home project with $200 — whether we hire them or not. This is a small way for us to thank candidates for their efforts and a practice we hope to see become more common.

We hope that by exposing some of our process we can inspire other teams who are shaping their interview processes to rethink the traditional exam-like process we all know too well. Not every company will treat interviewees correctly or fairly in their process, and our advice to those interviewing with companies like that is to never give up. Just because you get a bad interview doesn’t mean the next one will turn out the same way. Take what you learn in each interview and use it to improve your process, strengthen your skills, and tackle the next interview.

Topics

Now, on to what you should probably expect as far as the topics that will be covered when interviewing for an iOS developer position. These will of course vary based on projects and development team preferences.

Language

The first will of course be the language. By now, it’s safe to assume that most places have adopted Swift, and you’ll be expected to know it very well depending on the seniority of the role. You may find that some teams have gone all-in on Swift and avoid writing any new code in Objective-C. On the other hand, you may find a team that has decided that Objective-C is still their preferred language.

This can be one of those “make or break” moments for both the interviewee and interviewer. As a job seeker, you’ll find that most companies are pretty upfront in their job listings about this, so be sure to apply for what suits your preference and experience. For those writing job listings: Ensuring that your requirements and all the details in the listing are up to date and exact will save both you and your candidates time and frustration from the very start of the process.

SwiftUI

The next hot topic is whether the team is using SwiftUI and, if so, whether you have experience with it. You’re likely to find that most teams are now starting to consider SwiftUI as a viable alternative to UIKit — and potentially as a wholesale solution for the app lifecycle. It can go many different ways, but you should anticipate at least being asked about SwiftUI. A reasonable team will understand if you haven’t fully embraced SwiftUI yet, but it would be within the realm of reason to expect that a candidate has at least watched some WWDC sessions about it. Again, job listings should definitely mention if experience with SwiftUI is a hard requirement.

Platform-Agnostic Concepts

There are certain concepts that apply to all platforms, and candidates should be familiar with them. These include:

Persistence
Networking
Concurrency
Memory management
Design patterns
API, library, and framework design
Dependency management
Version control
Continuous integration and delivery

Each of these is a vast topic on its own, but you should feel comfortable having a conversation about a majority of them. On iOS, there are multiple approaches defined by the platform and community for many of these.

iOS Frameworks

As of this writing, Apple lists 259 frameworks/topics on their Technologies Documentation page. While it’s impossible for anyone to have a working knowledge of all those frameworks and topics, there are some that could be considered “must haves.” A short list of the ones you should definitely be familiar with includes:

The Reality

Interview processes can vary wildly, and some companies will forever put candidates through arduous multiday processes that quiz and attempt to trick them along the way. Someday, you might find yourself standing in front of a whiteboard, holding a marker and feeling like you’ve never written a line of code in your life. Some candidates excel in these situations, while others do not. The reality is that no single interview, good or bad, will ever fully and accurately portray your abilities as a developer, and this is something that all interviewers should bear in mind when performing any interview.

One key to successful interviewing is to always walk away gaining something more than just an offer or rejection letter. The process will both tear down and build up your confidence, much like physical exercise tears muscles that then heal to be stronger — it is difficult and painful, but worth it. Take the time to retrospect on the process and determine what could have gone better. This will advance you in your career to a point that you’ll become a better interviewee and maybe even some day a better interviewer.

Wrapping It Up

After all is said and done, there will always be candidates who feel satisfied with the process and those who don’t. Unfortunately, there’s simply no perfect interview process, and the industry will constantly evolve to find better ways to gauge knowledge and experience through these brief interactions.

Here are some parting thoughts for both job seekers and hiring teams.

For those looking for a position: In the event that you receive a rejection letter, it’s never a bad idea to follow up and thank everyone for their time. A rejection is not a lifelong sentence, and you may hear from them or apply again in the future. Still, it can be easy to dream of working for a specific employer and then become discouraged and upset if you don’t get the offer you were hoping for. Keep trying your best, and you’ll ultimately land a position you find rewarding — the software industry is huge, and people with software development skills are in high demand.

For those looking for a developer, some takeaways for making the interview process better are:

Don’t write off candidates as “never candidates” — just because they may not interview well once doesn’t mean they can’t develop the skills later, reapply, and be able to successfully pass an interview.
When you hire people, collect their thoughts about the interview process: What did they think about it? What did they like or dislike, or what would they like to see changed or added? The people who complete an interview with you can help shape future interviews for the better.
Revisit your interviewing strategy frequently to see if it’s adequately serving you, your current employees, and future candidates.
Select current employees to randomly run through your interview process, especially after changes, to test the process and evaluate it.

With some thought and attention, you can ensure that your process is running smoothly and helps you evaluate and gauge the skills of candidates as effectively as possible.