How To Beat The iOS Developer Interview

By Aasif Khan | Last Updated on June 27th, 2022 6:41 am | 5-min read

Are you getting ready for the iOS developer interview? In this tutorial, we’ll discuss how you can best prepare yourself for the iOS developer interview and how to increase your chances to get hired.

Here’s what we’ll get into:

How you can best prepare for the iOS developer interview
Getting comfortable with the live coding interview test
Different interview setups, combos and components
A killer technique for answering dialogue-style interview questions
How to practice for the live coding test

What’s the Developer Interview Process?
Developer Interview: The Phone Screen
The In-Person Developer Interview
Developer Interview: The Live Coding Test
Further Reading

What’s the Developer Interview Process?

First, let’s discuss the interview process itself. How exactly does the iOS developer interview take place? The interview isn’t always the same, so it makes sense to find out more. That way you’ll be better prepared for what an employer might throw at you.

Most job interviews for developers consist of:

Phone Screen: A hiring manager gets on the phone with you for a 15-minute chat. This way, the hiring manager can filter out developers they want to interview in-person.

In-person Interview: You’re invited to your future employers office for a formal job interview. They’ll ask typical interview questions like: “What’s an interesting project you worked on recently?”

Live Coding: This is unique for developer jobs. You’re asked to find a solution to a programming challenge. There’s lots of variations: online, in-person, live or take-home, coding with a senior dev, whiteboarding, etc.

Test Project: It’s literally an iOS app project, so you can show your skills. Test projects are becoming more common, because they often better represent the job you’re interviewing for.

In the field, you’ll find many variations of the above interview components. Some employers will skip the phone screen and the hard-core coding interview, and will merely ask you questions about past projects. Some companies pre-filter with an online application process. Other companies, especially larger ones, will designate entire days to vetting job candidates!

What should you make of this, when preparing for the interview? It’s smart to focus on the in-person interview and the live coding interview. A phone screen is kinda a small in-person interview, and chances are – if you’re fit for the job – you’ll ace the test project anyway.

Quick tip: In interviewing, focus on getting comfortable with answering interview questions (coding and non-coding). You’ll find a bunch of them at the end of this tutorial!

Developer Interview: The Phone Screen

Imagine you’re a hiring manager at a large software development firm. You’ve got a new job opening for an iOS developer. Your firm is quite popular, so you’ve got hundreds of online applicants. How do you find the developers you want to interview in person?

In this scenario, the developer interview starts by vetting candidates. Here’s how:

The hiring manager reads through résumés (Curriculum Vitae, or “CV”) and makes a shortlist
Many companies allow developers to apply online, and the software they use can sometimes vet candidates automatically (experience, location, etc.)
Some employers will quiz you on written language skills (English, etc.), which can be quite inpersonal, and it’s uncommon for smaller firms

Next, a hiring manager plans a phone interview with the developers on their shortlist. We’re down from hundreds of applicants to a dozen, or just a few. This can be quite vexxing for you, the developer for hire, because you’re in the 80% that gets on the “Don’t call” list, without a second thought.

Quick Note: Not getting called back is the no. 1 frustration for potential hires. You can help yourself by asking a hiring manager or recruiter when you’ll hear back latest about the position, and not worry about it until then.

Preparing for The Phone Screen

How do you prepare for the phone screen interview? Here’s how:

Look up common phone screen interview questions online. A typical question is: “What made you apply for this position?” Answering questions like those is 50% of the phone screen. (We’ll discuss a question technique later on.)
Do research into the company you’re applying to. Find out what they’re working on, what the company’s aims are, and think about how you’d fit in. Incorporate these insights in the entire developer interview (and not just the phone screen).
In typical phone screens, a hiring manager will ask for “red flags”, such as gaps in your résumé and changing employers often. It’s smart to be prepared for such questions, but bear in mind that résumé gaps and changing employers often aren’t necessarily bad.

It’s also a great idea – if not a must – to make your CV and application stand out. You don’t have to be novel or unique to stand out. What about a video cover letter? It also helps to emphasize skills and achievements for a specific job, and customizing your CV for different industries or skillsets.

You can also ask questions to the interviewer. That’s a great idea, actually! It shows you care, that you’re engaged in the process, and that you’re genuinly interested in the work at hand. It also gives you an opportunity to get process-related questions out of the way, like “When do I hear back about the position?”

Two questions that are guaranteed to make a good impression are:

What are the most important things you’d like to see a new developer accomplish in the first 100 days on the job?

While you’re interviewing other candidates for this position, what are topics or technologies I should look into – to make a future transition as smooth as possible?

Pro Tip: Build an online showcase of your work. Like a portfolio, but better. Focus on presenting your work in a way that shows its benefits, qualities and value to future employers. The best way to get hired – still – is to get hired for your kind of work, instead of trying to get hired as a generic code monkey. Don’t have work to showcase? Start working on that, and keep the 2×3 Rule in mind: develop 3 professional projects, and 3 related projects that show who you are (experiments, try-outs, open source, etc.).

The In-Person Developer Interview

Let’s move on to the in-person interview. You’re past the phone screen and you’ve been invited to your future employer’s office. Don’t worry! You’re about one-third through the developer interview. What’s going to happen next?

In the in-person interview, you typically discuss your CV, the job at hand, the company and the team (“cultural fit”) and typical interview questions. Most of these things are thematic, i.e. there’s no structure that defines that you’ll first discuss your CV, then the job, etc. It’s more of a mix, so you’ll want to be prepared as best you can.

Most in-person developer interviews roughly consist of two components:

Small talk (seemingly aimless)

Dialogue-style questions and answers

Wait, what!? Seemingly aimless small talk? What’s that about?

Small Talk

Imagine you’ve just arrived for the interview. You walk up to the receptionist. “Yeah, I’m here for the interview at 9.” You wait for a bit, and Emma, a senior developer, comes down to meet you.

“What have you been working on recently?” she asks you. You start talking about a project you did with Flutter. You’re interviewing for the iOS developer job, but you figured it’s smart to showcase your affinity with learning a new technology. Emma and you get a coffee, and before you know it, you’re discussing how Flutter and SwiftUI affect iOS development.

This is seemingly aimless small talk! It’s incredibly important in any developer interview. On the one hand, you get a chance to connect and to show your skills and passions. On the other hand, you can get comfortable with getting interviewed and being “on the spot”. You often also get a chance to check out the office.

The hiring manager, or senior developer who’s hiring you, gets the opportunity to see what you’re made of. Don’t assume the interview starts when you’re sitting down in an office somewhere – it starts the moment you set a foot in the door.

“Why should we hire you?”

The next phase in the interview is what we think of when we think “job interview”. It’s the question-answer dialogue that you’ve prepared for, with nerve-racking questions like “Why should we hire you?”, “What’s your greatest strength?” and “If you were an animal, what animal would you be?” (OK, maybe that last one is a myth.)

How do you prepare for this part of the developer interview?

Practice with answering direct questions, such as “What makes you perfect for this job?” The goal here is to not give a wanted, expected answer, but to give a genuine view of your work, skills and strengths.
Don’t focus too much on practice questions and the answers you want to give, but focus on the way you answer them. Get comfortable with answering, up to a level where you can play with what you want to get across.
Do a mock interview, with a friend or with a specialized service like Codementor. Simulating an interview scenario is a great way to practice, get comfortable, and to get better at interviewing in a risk-free environment. It also helps with anxiety!

Before we move on, let’s discuss a strategy for answering dialogue-style questions. We’ll focus on the typical “Why should we hire you?” question.

Your first reaction might be: “Well, I’m out of a job, and I saw this job advert, and now I’m here.” But that’s really not what an interviewer wants to hear when they’re asking this question! The emphasis is on why they should hire you. So… why should they?

The ACA Method

A great technique is the so-called ACA Method. It stands for Advantage-Claim-Advantage, and in short, you effectively pad a claim with two advantages. You first give an advantage, then a claim, and then finish with another advantage.

Let’s say you’re good at iOS development. You can’t just say “You should hire me, because I’m good at iOS development.”, because without evidence that sounds unbelievable. How can you convey that you’re good at iOS development, without outright saying it?

Here’s a few ideas:

“In my last job I worked on a large-scale iOS project, with thousands of customers. It taught me how to engineer iOS projects well. I’ve incorporated these insights in smaller projects since.”
“I started to learn about Flutter a few months ago. I’m already fluent in iOS development, so I used Flutter to learn more about app development from a different perspective.”
“As a side project, I created this app in the App Store. Throughout the process I became an expert at iOS development. I got this wonderful email from a customer last week.” (Show email with praise.)

Do you see how each claim (in italics) is wrapped in two advantages (ACA)?

You’re using the large-scale iOS project to give weight to your expertise in software engineering. You’re using Flutter as a stepping-stone to show your expertise in iOS development. And you’re using a customers email to give the value of your iOS app – and your skills – momentum.

Whatever you do, don’t say “perfectionism” is your greatest weakness. Everyone says that! If you find that you tend to give wanted, unoriginal answers, see if you can get the help of a professional to find your strengths and weaknesses. It’s not as black-and-white as that, but it may help you to get an outside-in view of what you’re good at (and what not).

Developer Interview: The Live Coding Test

Most developer interviews have a live coding test. Some developers dread it, others love it. And why not? You get to work on an interesting challenge, show off your coding skills, and hopefully land a gig in the process.

Here’s how the live coding test works:

A live coding test is a challenge that you need to solve by programming. The challenges are usually related to Computer Science’s Algorithms and Data Structures disciplines, such as time complexity, binary trees, searching, sorting, hash tables and linked lists.
Live coding tests can take place online, on platforms such as Codility and HackerRank, via teleconferencing like Zoom, or in-person. How a test is conducted determines how you can best prepare for it.
You’re often asked to explain your solution to a challenge, either after you’re done, or while you’re coding it. Especially the latter can be incredibly stressful, because you need to be able to talk and code at the same time.
A subsection of coding tests revolves around whiteboarding. When you’re whiteboarding the problem, you’re essentially working out your code on a whiteboard – without a computer or code editor. In some cases, you may actively work together with a senior developer to solve the challenge.

Get to Know The Coding Environment

First, let’s discuss the environment you’re doing these coding tests in. Take for example Codility’s online environment:

This editor is totally different from what you’re used to. You don’t have code completion, for example. Code highlighting may not work perfectly. You often can’t run your code in between edits. It’s totally different than what you’re used to!

The best advice here is: get used to the code environment you’re going to use for the live coding test. If you know that Codility is used for coding tests, work your way through their practice challenges and get to know the way they grade tests. If you can use Xcode Playgrounds on Zoom, great! Online coding platforms have a time limit, so take that into account when devising your strategy. Completing 2 of 3 tests is better than 3 tests done only half.

Whiteboarding

Next, let’s focus on talking and coding at the same time. Imagine the developer interview is conducted via Zoom, and you share your screen so the interviewer can see what you’re doing. How are you going to talk the interviewer through your finding a solution to the challenge?

Some ideas:

Think about why you’re doing this live coding test. Is it merely to check if you know how to code, or is something else going on? Most interviewers want to see your thought process; see how you solve a problem. The emphasis isn’t so much on successfully solving the challenge, but on how you solve it. What’s the process you use?
If you can, opt to fully explain your solution after you’re done coding. Work in steps. First, you work out some part of the solution. Then you explain how it works. Then you continue with the next part, and so on. This gives you a structure to hold on to, and it may help you to keep your cool.
Make notes during the test. Did you find an edge case you need to take into account? Some mechanism or subproblem you need later on? Offload it from your mind’s working memory, and get back to it later. Taking notes is especially helpful during whiteboarding, too.

Solving Live Coding Challenges

Next, let’s take a look at an actual live coding challenge. What’s a good strategy for solving it?

Your job is to sort giraffes into groups based on the lengths of their necks. The giraffes get anxious if their group contains giraffes with much longer necks than theirs. So, you’ll need to make sure that the differences between neck lengths in a group is not greater than 2. The input you get is a one-dimensional array of length N, with lengths between 1 and 20. The desired output is a two-dimensional array with groups of lengths.

The challenge is simple: organize an array of numbers in such a way that the differences between neighbouring numbers is less than or equal to 2. You need to transform the array of numbers into an array of arrays of numbers, or “groups”.

Solution: You can best imagine the solution as sorting all numbers, writing them on a line, and grouping them with a pen (by drawing a line between numbers) if you see that the difference with a subsequent number is greater than 2. It really helps if you can picture this in your mind!

Going from a story-based challenge description to something you can work with, such as arrays and numbers, is another skill worth learning. You need to extract the relevant information from the story, and leave the giraffes in the zoo…

What’s a good strategy to solve this problem?

First, think about how you would solve this challenge with pen and paper. Don’t start coding immediately! Workshopping the problem in your head will help you find a solution quicker, because you’re not distracted by Swift syntax. It’ll also help you find edge cases, and it’s a quick win to talk the problem over with your interviewer.
Then, think about time complexity. Your proposed solution, what time complexity does it have? It’s typical to start with a brute-force approach, but they often have a poor time complexity, like O(n2). Some live coding challenges may require you to work with a specific time complexity, such as O(n log n).
Read through the challenge again. Requirements, such as time complexity, may give you clues about what’s needed. For example, a time complexity of O(n log n) can indicate that you need to sort the input before processing it. Likewise, the challenge description could hint at certain edge cases that you may need to take into account.
Get to work on coding the solution. You’ve prepared as best you can. Focus on implementing your pen and paper approach with code. Talk the interviewer through your process. Once you’re done, test your code for edge cases. Many challenges have a few sneaky scenarios that you need to take in account, that aren’t immediately apparent. What if the input is arbitrarily small or large? What if it’s all the same numbers? Or integers below zero?
Submit your solution. If you’re working online, submitting is usually the end of the exercise, and you’ll get emailed your results. If you’re interviewing in-person, you may need to talk your solution over with the interviewer. Take the time to talk them through it. Even if your solution isn’t 100% correct, you may be able to score some points with your workflow and explanation.

Practice, Practice, Practice

The last bit of advice worth sharing, is to practice a lot. This is true for the entire developer interview, in fact. Work your way through the example challenges of platforms like Codility, HackerRank, Project Euler, etc. Get comfortable with a strategy that works for you. Practice really makes perfect!

Here’s a few step-by-step challenges for you to try:

Play With Code: Converting Roman Numerals With Swift
How To: Shuffling An Array In Swift Explained
Playing With Code: Insertion Sort In Swift
Let’s Solve The FizzBuzz Challenge In Swift

Live coding tests in developer job interviews are becoming increasingly controversial, because they may not be representative of the job you’re interviewing for. An interesting story is that of Max Howell. He’s the creator of Homebrew, a package manager for Mac/Linux, that’s used all over the globe. He failed his interview at Google for not being able to invert a binary tree, despite the fact that many people at Google probably use his software…