My notes from Suncoast iOS Meetup’s “The iOS Technical Interview: Get your dream job as an iOS developer” : Global Nerdy

Last night’s Suncoast iOS Meetup — which happens to be the first Meetup I attended after moving to Tampa — covered a topic that currently is very relevant to my interests: crushing the iOS technical interview.

Juan Catalan, the Suncoast iOS Meetup organizer, gave a great presentation based on his own experiences. Six years ago, he began as a self-employed indie iOS developer. He landed a few short contracts, followed by a six-month contract, which in turn led to full-time work as an iOS developer. He continues in that line of work today, having interviewed at a few companies and interviewed a few iOS developer position candidates.

I took notes and photos, and the distilled result follows.

Requirements for iOS developers at different levels

Junior iOS developers should:

Have either:
- At least one app in the App Store (and yes, sample projects count), or
- A GitHub repo featuring iOS projects or sample code
No experience as an iOS developer necessary
Be comfortable with the basics of iOS development
Know Swift and maybe be willing to learn Objective-C

Intermediate iOS developers should:

Have at least one app in the App Store that isn’t a sample project
Have 2+ years experience
Know how to build an app from scratch and publish it to the App Store
Know both Swift and Objective-C, as there’s a good chance that they’ll be working with legacy libraries or even on legacy projects

Senior iOS developers should:

Have several apps in the App Store — Juan quantified this as “5 or more”
5+ years experience as an iOS developer, or 10+ years in software development
Deep knowledge of Objective-C and Swift, and how to interface between the two
Knowledge of complex subjects, such as:
- Memory management
- Concurrency
- Unit testing
- Automated builds
- Version control

Before you apply for an iOS developer job

Have one (but preferably both) of the following:
- An updated LinkedIn profile with links to your apps
- A portfolio website
Have an updated resume in both Word and PDF format (some places, especially recruiters, insist that you submit your resume in Word format for a number of reasons)
Have apps or code that you have written yourself available in some publicly-available repository, such as GitHub, BitBucket, or Gitlab
Now you can apply and prepare yourself for the interviews!

Applying for an iOS developer job

The process generally has these five phases:

Initial screening interview with a recruiter or human resources person:
- This is the first “filter” in the process
- The recruiter or HR person looks at your “documentation”, usually your LinkedIn profile and resume, and matches that information with the position’s requirements
- Remember, when dealing with recruiters, they make money when they successfully match a prospective employee with one of their clients
Technical screening interview, which could be in person or a call/chat:
- A more in-depth look at your documentation by technical people
- An interview with technical questions tailored to the required experience and company needs
- Could include a post-interview real coding exercise
On-site technical interview:
- Technical questions:
  - General software development questions
  - iOS-specific development questions
- Whiteboard or paper coding exercises
- Read coding/exercise or app
On-site team interview:
- Resume questions
- Technical questions
- Behavioral questions
Closing conversation with a recruiter or HR person:
- The company informs you of their decision
- Offer negotiation and offer letter
  - Make sure that whatever you negotiated is in writing is in the offer letter
  - If it’s not in writing, it doesn’t exist, especially dollar amounts! The general rule is: “the more specific, the better”

The iOS technical interview: What you should review

From high-level to low-level, here are the categories of questions that you’ll be asked in an iOS technical interview:

Algorithms and data structures
Design patterns
Tool (Xcode, instruments, Git, and so on)
Frameworks (iOS SDK, 3rd-party libraries)
Programming languages (Objective-C and Swift)

You should review the following topics and sub-topics (and wow, are there a lot of them!)

Objective-C
- Classes, instance variables, properties, methods, method signatures
- Memory management: ARC, MRC, retain cycles, strong, weak, assign, initializers (designated and convenience), dealloc
- Protocols, categories, and blocks
- Control flow: loops (for, for-in, while, do-while), fast enumerations, switch, if-else, continue, break, return
- Foundation classes, including NSString, NSArray, NSDictionary, NSSet (and multiple counterparts), NSNumber, NSDate, NSNull vs. nil, NSURLSession, NSJSONSerialization, NSError
- Interfacing Swift with C/C++
Swift
- Structs, classes, value types vs. reference types, methods, method signatures, properties, enums (with associated values), tuples, extensions, protocols, closures, generics, map-filter-reduce
- Memory management: ARC, retain cycles, strong, weak, unowned, initializers (designated and convenience), deinit
- Optional types (regular, implicit, unwrapping, optional chaining, default values), variables and constant, if/let, guard
- Dictionary, Array, Set, String, Int, Double, Date, URLSession, URL
- Control flow: loops (for/in, while, repeat-while), switch, error handling (do/catch, throw, throws), continue, break, return
- Bridging headers, interfacing with Swift-Objective C, API Design guidelines
iOS SDK: UIKit
- Storyboards, nib files, segues, autolayout in UI vs Autolayout in code
- UIViewController, UINavigationController, and stack of view controller
- UITableView, UITableViewController, UITableViewCell (custom cells), asynchronous data loading (background thread)
- UIView subclass, gesture recognizers, core graphics, core animation, UICollectionView, UIStackView
- UIButton, UILabel, UIImageView, UITextField, UIScrollView, UISwitch, segmented control
iOS SDK general topics
- Support multiple versions of iOS
- Foundation, Swift standard library
- UIKit, Core Location, Core Animation, Core Graphics, MapKit
- Core Data, UserDefaults, Property Lists, File Manager, SQLite
- URL, URLSession, JSONSerialization
- Grand Central Dispatch, Operation, OperationQueue
- XCTest
3rd-party libraries
- Know how to discover and install 3rd-party libraries using Cocoapods or GitHub
- Networking: AFNetworking, AlamoFire
- JSON: Mantle, SwiftyJSON
- Alternatives to Core Data: SQLite, Realm
Development tools
- Xcode: project, targets, info.plist, source control, editor (refactoring, code folding, re-indent), archive, devices, organizer, debugger (breakpoints, inspect variables, single-step)
- Instruments: allocations, zombies, leaks, network, time profiler, activity monitor
- Apple Developer Account, iTunes Connect, beta app distribution and crash reports (TestFlight, Fabric, HockeyApp)
- Git, GitHub/Bitbucket/GitLab: commit, merge, rebase, reset, stage, pull, push, fetch, fork, clone, pull requests, GitFlow branching model
- Cocoapods, Carthage, Swift Package Manager
Design patterns
- Object-oriented design: inheritance, polymorphism, composition
- MVC, delegation, KVO, factory, KVC, singleton, target-action (IBOutlet.IBAction), notifications
- Protocol-oriented design (Swift)
- MVVM, inversion of control, dependency injection
- General patterns: Decorator, Facade, Adapter, etc.
Algorithms and data structures
- Big-O notation
- Array, string, liked list, stack, queue, binary tree, graph, hash tables
- Recursion, breadth-first search, depth-first search, binary search, merge sort, quicksort, data structure operations (insert, delete, find, traversing graphs, etc.)
- Multitasking: thread, process, lock, critical section

The coding exercise

You may be asked to do a coding exercise and build an simple sample app. The example Juan provided was one that displayed NASA’s “Image of the Day”, which would present a list showing the most recent images of the day in reverse chronological order (that is, the most recent one first). Each list item would feature a thumbnail of the image of the day, its title, and a brief excerpt of the image description. Tapping on an item would take you to the screen for that item, which would display a larger image, the title, and the full description:

You would need to know what controls to use:

And you’d have to handle a number of cases, as pictured below:

When the list is first populated
Downloading image thumbnails for the list
Simply displaying the list
What happens when the user pulls down the list to refresh it

Sample interview questions

What was the latest version of iOS you worked with? What did you like about it, and why?
Have you worked with Swift? What do you like about it? What don’t you like?
How is memory management handled in iOS?
What do you know about singletons? Where would you use one? Where would you not?
Explain the difference between using delegates and using KVO.
How do you usually persist data on iOS?
How do you typically do networking?
How do you serialize data on iOS, from getting JSON from the web, to memory, to persistent storage?
What design patterns do you know and use on iOS
What’s autolayout?
How do you handle asynchronous tasks?
How do you manage dependencies?
How do you debug and profile your iOS apps?
Do you do code review?
Do you test your code? What do you do to make your code testable?

Advice

Don’t waste your bullets. You have a limit amount of time and energy — use it where it will be most effective!
Be honest. You will get found out if you’re not!
Be precise. This is programming, after all.
Be respectful. How you conduct yourself is just as important as your coding skill.
Be friendly, not arrogant. You will be working with other people, some of whom will sign your paychecks.
Never give up.

The interviewer’s perspective

Juan then invited Igor Androsov to talk about iOS interviews from the interviewer’s point of view:

I’ve interviewed lots of people, and asked lots of the questions that Juan posted
I like to ask questions about actual hands-on work that people did
I often ask questions that lead to other questions
“I’m not here to tramp you down — I want to hire someone!” I’m buried in work, and need someone to take some of it off my hands.
Leading questions should be a sign. Chains of questions are an indication that you weren’t clear with answers, and they’re also a cue for deeper discussion
Be ready to say “I don’t know”. That’s okay; you can’t know everything. “I can prepare all day long, but I’ll never know all the answers”
With interview questions, tries to stay out of the details; tries to stay more general
Honesty is important; it’s a good indicator when someone stumbles — I want to see what they do next. Will you work through the problem? Will you ask questions?
More concerned about an attitude — Will they work with the team? Is there a cultural fit?

Chris Woodard, organizer of the Tampa Bay Cocoaheads Meetup, wasn’t able to make his guest speaker appearance, but posted these notes from this talk:

What I look for:
- Solid development experience: By this I don’t mean “I developed, by myself, thirty one games and pushed them to the app store”. I mean you’ve been through a number of development cycles and encountered (and solved) problems enough times not to get thrown when something weird happens.
- Ability to work solo if need be: Pair programming is the new hotness in some areas but sometimes you have to go it alone. You need to be self-sufficient enough to be given a problem and left alone to solve it.
- Ability to work as part of a team: Along with the previous bullet point, you need to know when you’ve beaten your head on the desk enough to go ask for help or look on Stack Overflow or Cocoa Controls
- Being able to DIY or adapt: It’s one thing to have some manager tell you you can build your app quickly by slapping together a bunch of components (React Native enthusiasts think this way); it’s another to do that, have one of them not play nicely with the others and you have to go dig into five or six components you didn’t write to fix the problem. You need to be able to take a look at someone else’s code (*cough*AFNetworking*cough*) and recreate just as much of it as you need. You avoid the consequences of the old saying “Marry in haste, repent at leisure.”
- Hungry: Mobile is fast-moving. You have to be hungry to stay enough ahead of things to be able to bat aside the flavor of the month “write once run anywhere” hybrid app solution until you understand it and can give a reasoned opinion.
- Comfortable Talking about Your Projects and Your Role In Them: Resumes, especially ones that come from recruiters, tend to have weasel-words in them that are red flags – “Involved with” or “Helped” or “Worked with” are an attempt to inflate minimal experience into something that might pass an interview if the interviewer isn’t technical or experienced. I ask people about what they worked on, what they did, what they encountered and how they solved problems. Sometimes I ask why they made a certain decision – not that I think they’re wrong, but how they thought it through.
- Technical Proficiency: Where I work we give a four-hour timed task. You build an app from scratch to do something useful. You’re not recreating Paper or Facebook, but you’re not writing “Hello World” or “Flappy Swift” either. That, along with a standard technical interview designed to see where your experience is heavy and where it’s not, gives me a good picture of your skills and abilities.
What I don’t look for:
- Dead-Enders: It’s one thing to be dedicated to solving a problem and shipping software. It’s another to think you have to grind yourself into dust to do it. Nobody really needs to make a habit of 80 hour weeks for months at a time.
- Trivia Buffs: We need to write code, not argue over what CFString did eight years ago. I care that you know how to build an app.
- One-Uppers, People with Something to Prove: People like this are never fun to work with and aren’t very often worth the trouble they bring.
- BS Artists: There are red flags I mentioned earlier. Others are things like trying to take over the interview and direct it their way, evasive language, the “Gish Gallop” of acronyms and esoteric concepts designed to overwhelm the interviewer(s) and seem a lot smarter than they are. There are lots of other ones but this is a short post.
- Perfection: Nobody is perfect. Everyone makes mistakes.

Reference material

The slides for Juan’s presentation are available on SlideShare.