Ace The iOS Interview Sample
Ace The iOS Interview Sample
@aryamansharda
No portion of this book may be reproduced in any form without permission from the publisher,
except as permitted by U.S. copyright law.
https://digitalbunker.dev/
https://twitter.com/aryamansharda
Legal Disclaimer
This eBook is presented to you for informational purposes only and is not a substitution for
professional advice. The contents herein are based on the views and opinions of the author and
all associated contributors.
While every effort has been made by the author and all associated contributors to present
accurate and up to date information within this document, technology changes rapidly.
Therefore, the author and all associated contributors reserve the right to update the contents
and information provided herein as these changes progress. The author and / or all associated
contributors take no responsibility for any errors or omissions if such discrepancies exist within
this document.
The author and all other contributors accept no responsibility for any consequential actions
taken, whether monetary, legal, or otherwise, by any and all readers of the materials provided.
Readers’ results will vary based on their individual perception of the contents herein, and thus
no guarantees can be made accurately. As such, no guarantees are made.
This eBook and all corresponding materials (such as source code) are provided on an as-is
basis, without warranty of any kind, express or implied, including but not limited to the
warranties of merchantability, fitness for a particular purpose, and noninfringement.
In no event shall the author or copyright holder be liable for any claim, damages or other
liability, whether in action of contract, tort or otherwise, arising from, out of or in connection
with this eBook.
All trademarks and registered trademarks appearing in this eBook are the property of their
own respective owners.
Table of Contents
Legal Disclaimer 2
Table of Contents 3
Afterword 307
Sources 308
As I was interviewing for these roles, I was always looking for easy-to-follow explanations of
all the relevant iOS interview topics and iOS-specific practice problems. After years of not
being able to find such a guide, I decided to write one myself.
Over the last five years, I’ve been consolidating every relevant question, concept, and
take-home assessment I've encountered during my interviews. They are all included in the
following pages, along with sample solutions, screenshots, and step-by-step instructions. This
book contains everything you need to know for your next iOS interview. “Ace The iOS
Interview” will help you take the guesswork out of your interview preparation and will
hopefully serve as a practical guide for landing your dream job.
With hundreds of interviews under my belt, both as a candidate and as an interviewer, I know
both what an interviewer is looking for as well as the common mistakes most candidates tend
to make. We'll go over in detail about how to tailor your responses to highlight the specific
criteria the interviewer is looking for, as well as strategies for the behavioral interview portion
and other “do's and don'ts” along the way.
For those of you looking for your first iOS job, I know first-hand how difficult it can be. Learning
iOS development has been one of the most impactful and rewarding experiences I've had. It’s
enabled a lucrative career and the opportunity to work on apps that impact millions of people.
All of that upside is on the other side of making it through the interview and hopefully this
book will help you do just that.
My sincerest hope is that you find this book helpful and that it helps you land your next iOS
position. If it does, I’d love to hear about it. Thanks for reading and good luck!
I’ve also created a free to join Slack workspace for anyone to discuss topics related to iOS
interviewing, mock interview requests, sharing interview questions, job opportunities, and
much more.
If you want to submit a question for inclusion in this book and to help other iOS developers, feel free to
contact me or share it in our Slack workspace.
While all of these questions contain a sample solution, my approach may not be convincing to
you and that’s absolutely fine. The sample solution is primarily meant to offer you a starting
point.
If you come up with an improved implementation or have any suggestions for the answers to
these problems, I’d love to see it. Feel free to share them with me on Twitter or by contacting
me at [email protected].
Over the following pages, I have reproduced the interview questions and take-home
assessments I encountered exactly as they were presented in the interview process.
I recommend spending some time thinking about how you would answer the questions, what
you would ask the interviewer, and what requirements you would clarify before you peek at
the sample solution.
Many onsite interviews are designed to mimic a situation where you and the interviewer are
working together on a project and may need to decide on specifics as you go along. Be
prepared to encounter a lot of deliberately vague questions.
Interviews of this type aim to assess your ability to think deeply about a new problem, what
concerns or bottlenecks you can identify, your ability to ask clarifying questions, and the level
of planning you do before you start writing code. The biggest mistake you can make here is to
jump right into writing code without doing any type of due diligence or planning.
● What did you do when you didn’t have all of the information?
● Does your code have the flexibility to adapt to changing requirements?
● Did you spend enough time thinking about the problem before writing code?
● Did you consider how you’d handle errors?
At the end of the day, the interviewer is looking for a new teammate so demonstrating your
ability to collaborate professionally with others is equally, if not more, important than solving
the problem itself.
Don't be afraid to ask questions, explain your thought process out loud, and remember to be
personable - it sounds obvious, but sometimes we forget when our nerves get the best of us.
I would periodically search for variations of "swift take home assessment" or "iOS exercise" and
would find public take-home assessments submitted by other iOS developers.
You’ll have to do some digging, but you’ll eventually find projects that are both novel and
updated recently. With this approach, you’ll have an inexhaustible supply of practice questions
at your disposal.
Once you begin doing this consistently, you'll start noticing patterns in the questions, and that
can give you a sense of what variations of a given problem are most popular.
If you would like to submit a problem for inclusion in this book, please feel free to contact me!
Easy Wins
As an interviewer, it's always refreshing to review a take-home project that's well documented,
follows typical Swift conventions, contains a README, and leverages version control.
Most candidates don't add this final touch to their submissions, but it can really make a
difference for very little additional effort.
Documentation
When writing comments, explaining why the code is written a certain way is arguably more
important than explaining what it does. Programmers can generally understand what a given
piece of code does, but they might find it harder to reason about the context in which it was
written and the potential side effects of its execution.
Here are some examples of good comments as they focus on communicating why the code
was written a certain way instead of what it does:
// We're disabling the "Next" button as this is an invalid state and the
// user has no available options.
In contrast, these would be considered poor comments as they don't provide any additional
information or insight the code doesn't already convey:
Version Control
Familiarity with version control (e.g. branching, resolving conflicts, etc.) is an essential skill for
your job. So, demonstrating your ability to use it correctly [with good conventions] will only
help reinforce the narrative that you'll be able to hit the ground running.
Writing A README
At the very least, the README should provide a summary of the project, list any third-party
dependencies you’re using, and provide instructions about how to set up and run the
application (if applicable). For example, this is where you'd tell the interviewer that they will
have to run pod install before running the project.
You can also use the README to highlight known bugs, missing features, or any other pertinent
information the interviewer should know.
Often, I’ll see candidates using a mix of different coding styles and language conventions in
their projects. I can’t count the number of times I’ve seen Swift code written with Objective-C
stylings or JavaScript conventions brought over to Swift.
This lack of standardization will make your code difficult to read and may make your
interviewer doubt your familiarity with the language and its conventions.
For the interview, I recommend you follow generally accepted Swift best practices and
conventions regardless of your personal preferences. It’s a small low-effort change, but it
becomes one less thing the interviewer can dock you for.
If you’re looking for a good place to get started, I’d check out this well-accepted Swift style
guide: https://github.com/raywenderlich/swift-style-guide
Apologies for any unusual formatting in the following code samples. It was done in an attempt
to make this book more readable.
Over years of interviewing, as a candidate and as an interviewer, this is the most common
question I’ve encountered. If there’s anything you take away from this book, I hope it’s this
question.
The question takes a few different forms, but generally involves consuming some JSON
response (either mocked local data or retrieved as a result of an HTTP request) and presenting
the fetched data in a UITableView or UICollectionView.
I’ve seen the duration of this question range anywhere from a one hour on-site interview to a
few days when it’s part of a more involved take-home assessment.
When it’s assigned as part of a take-home assessment, it will often include additional UI
requirements like presenting a detail view, loading images, or even creating custom UI
components, but regardless of the specifics, this problem is everywhere.
It’s a great question as it touches on all the foundational concepts a iOS developer should
know:
Network Layer
- Foundation
- Asynchronous Tasks
- Error Handling
- Generics
- Codables
- URL Session
Caching & UI
- Foundation
- UIKit
- AutoLayout
- Creating Custom Cells
- Concurrency
Everything Else
- Architecture Patterns
- Design Patterns
- Delegates & Data Sources
- Coding Conventions
- Reusable Code
- Documentation
- Version Control
On GitHub, you’ll find hundreds of variations of this interview problem. I’ve shortlisted a few
variations in case you're curious, but at their core, they all revolve around making some API
calls and presenting the results in a UITableView.
It's not my intention to comment on the code quality or architecture design of these solutions,
I'm just sharing a few examples.
- https://github.com/ekeren/ios-interview
- https://github.com/raywenderlich/ios-interview/tree/master/Practical
- https://github.com/shayan18/Runtastic-Test-iOS
- https://github.com/mediassumani/TakeHome-iOS-challenge
- https://github.com/changjeffrey829/IOSGeniusPlaza
- https://github.com/brandaorafael/iOS-Faire-Take-Home-Assignment
- https://github.com/fila/Egeniq-assignment
- https://github.com/giblerw/HA-TakeHome
- https://github.com/ygapps/Movies/tree/master/Movies/Networking
- https://github.com/valizairov/AppStoreLightweight
- https://github.com/armaluca/clearScore
- https://github.com/ka-ching-as/take-home-assignment-junior-ios
In my experience, there have been certain variations of this question that allowed the use of
third-party libraries, but it was strongly discouraged. A library, like Alamofire, would be overkill
for an assignment like this.
Managing Endpoints
In order to build our networking layer, we’ll need to come up with an elegant way of
representing our application’s various endpoints.
Let's start by identifying a few things that all API calls will have in common:
We can model the HTTP method and the HTTP scheme with the following enums:
Next, in order to represent a generic endpoint, we can create an API protocol which any
endpoint we wish to support must conform to:
/// The API protocol allows us to separate the task of constructing a URL,
/// its parameters, and HTTP method from the act of executing the URL request
/// and parsing the response.
protocol API {
/// .http or .https
var scheme: HTTPScheme { get }
// Example: "maps.googleapis.com"
var baseURL: String { get }
// "/maps/api/place/nearbysearch/"
var path: String { get }
// "GET"
var method: HTTPMethod { get }
}
For example, if we wanted to add support for the Google Places API, we could do so like this:
}
}
With this approach, not only can you represent any generic API, you can easily add support for
any new API your project needs to integrate with by simply creating a new enum. For example,
in a larger application, you could have separate enums to handle your authentication, booking,
and checkout endpoints respectively.
This approach helps ensure the API’s path, the scheme, and the required parameters are all
readable, well-documented, and consolidated in one place.
As the networking demands of our application grows, the last thing we want to do is litter our
codebase with multiple calls to URLSession. Instead, we should try and create some kind of
consolidated network service that can manage both making the request and parsing the
response. As part of that implementation, we’ll want our solution to be as reusable as
possible, so generics would be a great language feature to leverage here.
There’s always a time and a place to add new dependencies to a project, but every additional
dependency increases the codebase's maintenance costs and risks its stability.
In my experience, there have been several times when a new version of Xcode or iOS breaks
one of our dependencies and we are left waiting for the developer to provide a fix before we
can continue releasing our application. Not to mention, this assumes that the third-party
dependency is still actively maintained!
Many times, we rely on large libraries only to utilize a small portion of their capabilities. In
certain situations, it may be easier to re-create the limited functionality you need rather than
introducing yet another dependency.
While bringing in a new dependency might solve your current problem, it will increase your
executable size, maintenance costs, potentially block future releases, be difficult to
de-integrate, and will likely be a black box of functionality. Finally, if the dependency were to
no-longer be maintained, then your only options would be to replace it with an alternative (if it
exists), become the maintainers yourself, or re-create the necessary behavior from scratch -
clearly, none of those options are ideal.
All that being said, if you choose to use a third-party dependency in your take-home project,
you should be prepared to defend that decision.
With this approach, our NetworkManager is blind to the specifics of the API being used and the
contents of the response.
That is exactly the behavior we want - our NetworkManager simply acts as a middleman. It’s
sole focus is on orchestrating the HTTP request, handling errors (if any), and passing along the
response to the call site.
import Foundation
/// Executes the HTTP request and will attempt to decode the JSON
/// response into a Codable object.
/// - Parameters:
/// - endpoint: the endpoint to make the HTTP request to
/// - completion: the JSON response converted to the provided Codable
/// object when successful or a failure otherwise
class func request<T: Decodable>(endpoint: API,
completion: @escaping (Result<T, Error>)
-> Void) {
let components = buildURL(endpoint: endpoint)
guard let url = components.url else {
Log.error("URL creation error")
return
}
urlRequest.httpMethod = endpoint.method.rawValue
dataTask.resume()
}
}
extension UIImageView {
/// Loads an image from a URL and saves it into an image cache, returns
/// the image if already available in the cache.
/// - Parameter urlString: String representation of the URL to load the
/// image from
/// - Parameter placeholder: An optional placeholder to show while the
/// image is being fetched
/// - Returns: A reference to the data task in order to pause, cancel,
/// resume, etc.
@discardableResult
func loadImageFromURL(urlString: String,
placeholder: UIImage? = nil) ->
URLSessionDataTask? {
self.image = nil
task.resume()
return task
}
}
Final Implementation
Finally, we’ll combine all of these calls together.
In our UITableViewController:
switch result {
case .success(let response):
self?.dataSource = response.results
self?.tableView.reloadData()
case .failure(let error):
Log.error(error)
}
}
And finally, in our custom UITableViewCell, we can leverage the extension we made on
UIImageView earlier:
thumbnailImageView.loadImageFromURL(urlString: photoURL)
We've now created an extensible and reusable network layer, a clean way to represent APIs,
and an extension for UIImageView that lets us fetch and maintain a cache of images without
any third-party dependencies.
Afterword
Congrats on making it to the end!
I hope by now you're feeling more confident about your upcoming iOS interview - I know you're
going to ace it. Writing this book has been one of the most difficult projects I've undertaken,
but it has without a doubt made me a better engineer. In my opinion, teaching others is one of
the best ways to improve as a developer. It forces you to delve deeper into topics than you
would otherwise, which is excellent for filling in any knowledge gaps you may have.
Whether you land your dream job or learnt something new along the way, please consider
leaving a review! I need a sign that I didn’t waste 6 months writing this
Also, if you come across something interesting or educational that would be useful to other
iOS developers, please send it my way. I love to share quality educational content on my social
media. Finally, if there’s anything I’ve missed or if you would like to propose a topic or question
for inclusion in this book, let me know that as well. You can email me at
[email protected] or message me on Twitter.
I will continue to update this book with new content, without charge, in the coming months.
I’ve also created a free to join Slack workspace for anyone to discuss topics related to iOS
interviewing, mock interview requests, sharing interview questions, job opportunities, and
much more.