A new job equals a new project, new opportunities, new people, new technologies — all of this sounds super exciting, like something most of us desire. Still, there’s this one little thing to go through to get there: the interview.
The interview is the often feared part of the process of getting a new job, but no matter how scary or hard it may be — it’s necessary. The employer needs to know whether the candidate meets the requirements of the project, and vice versa — the candidate always learns a lot about the company during the recruitment process.
My name is Mateusz, I’m a tech recruiter at Codete, and I’m happy to give you some tips on preparing for a job interview when applying for an iOS Developer role (at any company). This article’s primary purpose is to provide you with some general guidelines rather than particular questions or code samples.
Where to start?
The iOS ecosystem is already broad and it’s continuously evolving. Keeping up to date while maintaining what you’ve learned so far isn’t an easy task. And at the interview you can expect almost anything, right? So how do you prepare in that case?
No matter how silly it may sound, I advise you to ask your recruiter about the topics you may expect during the interview.
You won’t get a list of questions of course, but this is still hitting two birds with one stone. First and foremost, you’ll get some guidance and some confirmation whether your knowledge just needs refreshing or whether there’s something you don’t know and need to learn. Additionally, you’ll get a big picture of the project — language, frameworks, tools, methodologies, and many more.
It’s relatively easy to picture a technology stack at a company working on a single product, but many product-oriented companies have a set of apps they’re developing, so if you know one flagship application, it could be just the peak of the iceberg. And when you think of a software development company like Codete, with many different projects running simultaneously, you can expect different approaches, different technology stacks, different methodologies — all depending on the project.
Everything mentioned above leads to the conclusion that it’s tough to hit the sweet spot during the interview if you don’t know a thing about the project you’re applying for.
Remember, an interview should be a beneficial experience for both sides, so don’t hesitate to ask questions. Here are a couple of typical iOS interview questions for you to consider, along with the benefits you may get from asking them:
- What’s the technology stack in this project? — It’s a general question, not meant to be too detailed, because your interviewer may not be able to share too much information at this point. The vital information you might get is:
- Is this app written in Swift, Objective-C, or a mix of both?
- Is this app written using UIKit or SwiftUI? Does it utilize XIBs, Storyboards, or is everything in the code?
- Is there any layer of caching or persisting data? If so, it may indicate you need to refresh your knowledge about Core Data or learn something about Realm or SQLite.
- What are the 3rd party dependencies? Each project has a set of dependencies that determine how the code looks, and some of them can be really complex and difficult to master, so it’s better to be prepared for such a situation.
- What’s the paradigm and methodology driving this project? — The answer can give you a sense of how working on this project looks like. Do they have weekly sprints or is everything planned upfront for larger chunks of time? Additionally, you should be able to learn about some of their practices like Test-driven development, Behavior-driven development, Continuous Integration, or Continuous Delivery. It’s all crucial to know.
Objective-C is still a thing
We all want to write in Swift and never look back (well, if we’re old enough ), but the reality isn’t always that simple. Since Swift’s release in 2014, a lot has changed — the language has matured, the frameworks now have great Swift support, and there are tons of learning materials. But you can’t forget that even if you’re writing UIKit applications in Swift, it’ll call Objective-C underneath since UIKit is still a framework written in Objective-C. The same applies to many different frameworks you may use in the project.
First of all, try to find out whether you can expect Objective-C questions on the interview and learn some basics if you’ve never used this language before or refresh your memory if you’ve worked with it back in the day. Apple’s not planning to get rid of Objective-C at any point, so knowing the syntax, the language features, and the general approaches can only help you to create great apps and improve your chances of getting hired.
It’s good to remember that Objective-C is a dynamic language that uses messages for dispatching methods. It’ll be beneficial to know a thing or two about method swizzling. We’re all used to ARC, but knowing how manual memory management works is a way to show your in-depth knowledge.
Let’s get Swifty
OK, the bold statement that “we all want to write in Swift and never look back” may not be entirely accurate, but looking at different polls and following the general iOS discussion, we can see it’s a trend. Swift is a modern programming language, a breath of fresh air in the Apple ecosystem. It’s still relatively young, but at this point, it’s fully capable of delivering great apps and putting smiles on developers’ faces.
Let’s make it clear though that Swift is not an easy language. It features tons of great functionalities and amazing concepts already known from other programming languages, and this brings much potential for interesting interview questions. Remember, Swift is only a tool in the iOS ecosystem, a language in which you’re going to express your intents. But most likely, this tool is going to be your bread and butter in your new iOS role — it means you need to know your way around this language. Not only its syntax, but its strong parts, weak parts, quirks, and how to stretch it to the limits.
UIKit and SwiftUI
A programming language is a means to express what we want to achieve in such a way that the computer understands us. Being an iOS developer goes beyond that. Most likely, you’ll have to deliver real-life applications with gesture handling, beautiful animations, and many other visually appealing components. Implementing this all by yourself would be a long and laborious process, that’s why you can find frameworks like UIKit or SwiftUI in the iOS toolbelt.
There’s no way you’re not going to face UIKit questions during your interview, so the majority of your preparation time should go into refreshing your memory about this framework. It’s a vast topic, so again, asking your interviewer what to expect could be a key point.
During WWDC 2019, we saw the introduction of an UIKit “slayer” called SwiftUI. Most likely, the migration process from UIKit to SwiftUI will be similar to the migration process from Objective-C to Swift. It means that it’ll be developers-driven rather than Apple-driven, the company is unlikely to push us to switch and deprecate old tools in the upcoming future.
SwiftUI represents an entirely different approach, and many developers will need recalibration. It looks friendly and easy to use, but it’s a paradigm shift, so expect the unexpected. When it comes to interviews, only a small percentage of companies are using SwiftUI in production already. Right now, developers are just goofing around, getting to know the framework, and testing its limits. Nevertheless, being able to answer SwiftUI questions during the interview would be a massive win for any candidate.
It was a long introduction to the role of UIKit (and SwiftUI) in the life of an iOS developer, but it’s critical to understand the importance of those frameworks. They’re big, packed full of features and potential traps, so you need to know your way around them and be proficient in solving problems — using the frameworks, not fighting them.
What I, as a tech recruiter, find most important is not whether a candidate knows all the API interfaces or whether they have learned all methods from a given class by heart. To me, it’s crucial that they understand the general concepts, such as:
- Application’s lifecycle
- View Controller’s lifecycle
- Passing data around in the application using built-in functionalities like:
- Delegation
NSNotificationCenter- Closures
- KVO
- Target-Action
A good understanding of these concepts allows for having great conversations during the interviews instead of just playing the question and answer ping-pong.
Everything iOS
iOS runs on amazing devices, packed with the latest technologies and lots of impressive sensors and peripherals that give us, the developers, a chance to create genuinely remarkable user experiences. For all of this, we need a programming language and a UI framework to start with, but we also need a ton of other tools and frameworks not to invent the wheel every time we need access to GPS, Bluetooth, or a Camera. That’s not all — writing a great app is one thing, but maintaining it, adding new functionalities, and even debugging it, is a whole different story. For each of these tasks, we have a set of tools as well.
I’ll say it again: the iOS ecosystem is enormous, and trying to digest everything at once to be prepared to answer every single question during the interview is impossible. It’s always best to prepare for a particular interview, but to do that — you should ask your recruiter what are topics that you should read about, and what technologies and tools are used in the project that you’re applying for.
Alongside many different project-specific things, there are a couple of universal topics, and I find it vital for any candidate to be able to talk about them, to share some of their war stories and personal opinions.
Below, you’ll find a few words about each of these topics.
Asynchronicity
I guess that we can all agree that asynchronous programming is one of those universal topics. It’s hard, but at the same time, it’s everywhere. You can’t help but learn how to use it.
The iOS ecosystem has a couple of ways of dealing with asynchronous programming, and even if you fall back to using GCD, you should be aware of things like NSOperationsQueue and know how they are different from GCD (or how they are the same). You should be able to provide use cases for each of them, or explain why one may be more suitable than the other in a given situation. There are many tricky parts of writing asynchronous code, like:
- Executing UI code only the main queue
- The queue doesn’t have to represent a different thread
- Waiting for the completion of many different asynchronous tasks
Knowing a thing or two about Functional Reactive Programming can only rank you up in the interviewer’s eyes (especially with Combine being a first-class citizen in iOS SDK nowadays). To put a cherry on top, you can read about some other approaches like Futures, Promises, and Async/Await. It won’t be a waste of time, trust me.
Architecture
The topic of architecture is a source of many debates and clashes between developers, and you have to know something about it. In recent days, applications are getting more and more advanced, and the structure of the code can play a significant role in the app becoming either a success or a failure. Depending on how the code looks, introducing a completely new feature can be a breeze or total madness.
Even if you’re falling back to MVC (or is it MVP, actually? ) in the majority of your projects, you should know a thing about MVVM, and know that it can play a significant role when you’re using Functional Reactive frameworks. You should be aware of how tedious it is to pass data around and inject dependencies so that many people are incorporating Coordinators' patterns to improve the data flow. What’s more, you should be aware of the fact that SwiftUI represents an entirely different approach to the architecture, and that it’s a declarative approach rather than an imperative approach.
Debugging, tools, and more
No matter what the project’s UI framework or the programming language is — fixing bugs is an inevitable part of being a developer. You should know your tools of the trade and the know-how to use them. You should be able to list some common bugs, ways to trace them, and methods for delivering a fixed version of the app into the hands of the customers.
Since this is not a pleasant topic, it’s often skipped during the interview, but I think it’s essential to know how the candidate would approach typical bugs. Using Instruments, os_log, or proxying device’s network traffic is just a couple of examples.
iOS developer interview: a few words about the attitude
You are probably familiar with the saying that clothes make the man. Keep that in mind while preparing your interview, showing off not only your impressive knowledge but also yourself as an amazing person — all in all, the team consists of people, not only skills.
Remember that you are the one being interviewed, thus you are expected to talk. I've interviewed people who had to be coaxed into saying anything. Which is never good — even if they’ve already mastered their field. Can you imagine how that person would function in a group setting? Or while trying to reassure the client? You should be able to talk freely and professionally. So don't get off track. If you catch yourself repeating yourself, get out of the loop as soon as possible. Take a deep breath and get back to the point.
If you become stuck, say so so that the interview can continue. People get nervous when you stand there quietly staring at the board. So, if you're not writing or sketching something, face your interviewer and simply converse.
Expect to hear a variety of viewpoints (usually referred to as feedback). Handle it gracefully, and let it help you decide if you want to work there. Don't be scared to express your own thoughts, but keep them in check. "Hate" and "idiots" don't go together. Discuss what you like using the voice of reason and positivity.
And if you’re starting to feel stressed a few days before the I-day try to repurpose your negative energy into something good: write an app over the weekend, try out a new tool or library, or learn more about the trends and updates from the industry by reading our blog. Keep the head going.
Preparing for the interview is not a one time job
You can read as much as you want and watch as many great videos as you’d like, but if you’re going to do it one day before the interview, there’s a huge risk you’re not going to give the best of you. What I’m trying to say is that knowledge is not something you can gain overnight. You need to invest a lot of time and effort in becoming a great engineer, and even them alone are not enough. The key to success is consistency.
You should always be learning new things, experimenting with new stuff, and trying to keep up to date with other people’s work (in this regard, the iOS community is something we should be proud of). It doesn’t mean that you need to sacrifice your personal life or any of your other hobbies to get a job, just the opposite. If you’re consistent and make the learning process your habit, you’re more likely to spend less time preparing for your next interview. Your life is the top priority, work should only help you to live a better one.
Good luck! Who knows, maybe we will meet at Codete one day? Have a look at our current job openings.
