Here are some of the most common questions you'll be asked during job interviews, along with detailed responses for how I would answer each one. You can work through them one by one if you want, or just pick out specific topics that interest you. Either way, I recommend you start with the introduction video to get a summary before diving in further.
Good interviewers usually start with a handful of open-ended questions to help you relax, and to get a better idea of which areas deserve more detailed questioning.
Getting ready for a job interview is tough work, so I’ve prepared a whole bunch of common questions and answers to help give you a jump start. But before you get into them, let me explain the plan in more detail…
To get right to the point, if none of SwiftUI, Swift Charts, widgets, or SF Symbols interest you, you might be in the wrong career.
If I could make one question required in all iOS developer job interviews, it would be this one, because it’s a fantastic way to help folks relax, and lets them cherry pick whatever code they think will be most of interest.
You can go for a simple “current version minus 1” answer here, but it won’t do you much good – talk about specific features you care about, or perhaps even specific bugs that got fixed.
This question is really two separate things in one: are you the kind of person who actively keeps learning about what’s happening in Swift, and do you try to be part of the community?
This is particularly important in the world of Apple development because all their major operating systems change every year, Swift sees significant changes two or three times a year, and new devices are shipping regularly.
This question comes up a lot, but I’m always wary of it because it places a lot of emphasis on unpaid work out of hours, which particularly affects people who already have extra responsibilities caring for children or elders.
This sounds like it ought to be straightforward, but usually there’s an ulterior motive here: are you able to work well as part of a team?
This is another one of my favorite questions to ask folks, because it’s a subtle way to gauge a number of things at the same time without sounding aggressive – after all, it’s Apple’s bugs we’re talking about, rather than the interviewee’s!
These questions focus on the core Swift language, rather than any additional frameworks.
This seems like a simple question, but a truly great answer means not only knowing the differences, but also knowing why they matter – anyone can remember a bunch of bullet points, but it takes more thought to explain what it all means in practice.
A great answer here needs to follow the same pattern you’ll seen in other questions: give a specific, technical answer first, then move up to discuss how this affects the kind of code we write.
This question is partly technical, partly about keeping up with Swift, and partly about application, and and I suggest you tackle it in that order.
This question is really trying to get a grip on your knowledge of functional programming, without getting into the murkier territory of functors, monads, and category theory.
The technical answer here feels a bit like Swift 101, but as with so many good answers the real value comes when you’re able to describe places where you use them and where they can cause problems.
This is crying out for an example, so once you get the basic answer out of the way back it up with some actual code example where
final is the right choice.
Broken record alert: explain the fundamental technical difference between the two, try to provide an opinion on which you think works better, then provide some kinds of examples of where each might work well.
Swift’s optionals are a real power feature of the language, but without direct compiler support they would be quite onerous. Optional chaining is one part of that support, so be prepared to answer exactly what part it plays.
Anyone with even a modicum of SwiftUI experience can name things like
@ObservedObject, but this question specifically asks you not to mention the built-in ones so this is more about thinking what property wrappers actually add to our projects.
This is the kind of question that helps distinguish between junior developers and intermediate developers, so take your time to answer it and if possible leverage your full range of knowledge to explain any extra details.
The questions here test your knowledge about using popular Apple frameworks, including SwiftUI and UIKit.
This is another example of a question where exclusively picking one over the other makes you look inexperienced – software development is often fuzzy, and acknowledging that complexity is a mark of experience rather than a weakness.
UserDefaults is the simplest way of storing user data, which makes it appealing for beginners, but also useful for even experienced developers who need a sensible place to stash away user preferences. However, it has downsides, and it’s important you’re familiar with them if you want to answer this question well.
Whether you use UIKit or SwiftUI, size classes are Apple’s broad-stroked approach to providing information about the available space for our UI.
NotificationCenter class implements the observer pattern from the Gang of Four book on design patterns, allowing any number of objects be notified when a specific event happens. But to answer this question well, you need to go beyond theory and focus on when it’s actually used.
A great answer should introduce property wrappers, then explain what
@Published does, give some examples, compare it against
@State, then bring in any extra real-world knowledge you can add around nuances or complexities.
Getting observable objects right is one of the keys to having a smooth experience with SwiftUI, but getting them wrong is a sure-fire recipe for massive performance problems no matter what platform you’re writing for.
Although Apple has done a great deal of work to bring these two powerhouse frameworks closer together, they still fundamentally work in entirely different ways, and providing a good comparison might take more thought than you expect.
Here we'll explore bigger questions about the kinds of larger choices you'll make when planning your app design.
As with so many good interview answers, you should aim to provide a succinct summary first, then expand on your answer with some specifics and examples, and finally get into more nuanced territory based on your real-world experiences.
There’s a quote from James Shore that I absolutely love, and I always start with it when introducing this concept to folks: “Dependency injection is a 25-dollar term for a 5-cent concept.”
Try to resist the temptation to get sucked into hype when answering this question: focus on the facts, compare POP with OOP as clearly as you can, then try to bring in some relevant real-world experiences that you have.
This sounds like a trick question because so many people rail against singletons, but the real challenge is actually providing a good answer – places where singletons actually work.
This might sound like a trivial property wrappers question testing your factual knowledge, but really it’s an architectural decision: what are the advantages and disadvantages of each, and when do they matter?
These questions explore your knowledge of testing, profiling, and more.
This is one of those questions that sounds simple, but gives you a huge amount of scope to explore various tangents based on your own area of expertise.
Unless either you or your interviewer is deeply opinionated, this question is not about making you argue the case for one rather than the other, but instead to give you scope to discuss the relative pros and cons of each.
If you don’t already have some experience with this, start getting some now. If you do have some experience, remember to keep your answer pragmatic: there are ups and downs with every approach.
This is a two-part question, and it’s a tricky one because ideally you’ll explain the problem, outline your approach, and provide a real-world example of you doing all that in practice.
Crashes are inevitable, at least when you’re in development, so learning how to find the source of a problem and getting it resolved is a key skill for any developer.
This is a brilliant question to ask, because it gives the interviewee the scope to pick their own area of expertise and delve into it, and it’s also a brilliant question to answer because you’re in control – you get to direct the conversation!