The introduction of Swift pushed Objective-C into this weird state of still being the most popular language for iOS development, but one that is becoming less and less relevant with each passing day. Since Obj-C is not yet obsolete, we figured it’s a good time to talk about our technical interview process and what we expect from the candidates.
While the interview usually starts with soft questions that are intended to evaluate the candidate’s chattiness and confidence, we quickly transition into a more technically-oriented conversation.
Although every self-respecting programmer should have a working knowledge of the principles of computer science, we don’t care if you’re able to roll out a red-black tree on cue. It’s OK not to know the complexity of Dijkstra’s algorithm by heart. However, we expect you to know or at least have an intuitive feeling of how Foundation collections behave. One of the easiest questions we ask is: “Which Foundation collection would you use for frequent
containsObject: tests and why?” We let candidates explain their reasoning and we try to point them in the right direction, should they get off track.
It’s fine if you don’t know which data structure
NSDictionary uses internally (although it’s documented). You should know which methods are crucial when implementing a custom subclass of
NSObject that’s intended to be used as a dictionary key. Many developers are not familiar with these concepts.
These questions are supposed to test the candidate’s CS knowledge and do so in the context of its practical applications in the world of iOS development. We actively try to show that knowing this stuff matters in real life, without resorting to academic dogma.
At this point, we’d be hard-pressed to find a person that has never used blocks. We put a strong emphasis on writing block-powered production code. It’s vital that you understand how a block captures variables from an enclosing scope and when to use a
Functional programming paradigms are becoming more and more popular and it helps if you can see those patterns in code you write. Knowing how map, filter and reduce work and coming up with simple applications of those is a plus. We’re not Haskell aficionados, but we glorify using a category that maps
NSArray into another array over cluttering the codebase with repetitive code that appends objects to
NSMutableArray in a
for loop. This is especially important now that Swift arrays support these idioms out of the box.
Even though the introduction of ARC made day-to-day Objective-C programming much easier, it certainly hasn’t obviated the need of knowing how memory management works. You should be able to explain what a retain cycle is, when it happens, and how it influences the running application.
View Hierarchy & Animations
iOS apps are heavily skewed towards the presentation of data, so knowing the ins and outs of
CALayer is very handy. You should know how UIKit utilizes CoreAnimation, how the responder chain works and why the tree-like hierarchy is useful when delivering touch events. I always ask for the difference between
bounds. Many candidates can’t explain it, even though it’s discussed right here on this blog.
From the very beginning, animations were a crucial part of the iPhone experience and you should be able to roll out nontrivial animations on your own. Playing with
alpha is not enough, it would be great if you could concatenate transforms with ease.
Knowing the higher level stack provided by Foundation and UIKit is important, but Objective-C is still a C-based language and knowing its tricky parts is a must. There are three areas that we find important: pointers, stack & heap, and bitwise operators.
While rolling out an
NSArray filled with
NSNumbers is often fast enough, some performance-critical situations may require a drop down to bare-bones C. When would you use a
malloc vs variable length stack array? Is it OK to return a pointer to a
struct that is created locally inside the body of a function?
As for bitwise operations, you don’t need to recite Hacker’s Delight. However, you should be able to turn bit flags on and off (think
NS_OPTIONS) without breaking a sweat.
A self-proclaimed senior iOS developer should have at least a superficial understanding of Objective-C runtime, especially the way that the messaging system works. There are many areas to be investigated in the course of discussing the more advanced parts of Objective-C, and the more you know the better. It would be awesome if you could explain whether a value of
0x0d381c23 could be an address of an Objective-C object or what you expect lldb to print when asked for
p $r0 right at the beginning of the method. You won’t need these skills every 5 minutes, but when things crash you should be capable of at least trying to investigate the problem.
We understand that writing code on a piece of paper is not something a developer does on a daily basis. However, we quickly realized that this particular task is crucial in the evaluation of potential hires. I never believed Jeff Atwood’s claims that many programmers can’t program. I was wrong. Here’s the first coding task we give:
Imagine you’re a Foundation developer and today you’re working with
NSArray. Write an implementation of the following method:
- (void)enumerateObjectsUsingBlock:(void (^)(id obj, NSUInteger idx, BOOL *stop))block
Before you start writing, we will explain the meaning of each of the block’s parameters. I love this exercise because it’s so simple yet it touches on a few important areas of day-to-day development: a simple loop, a block call, taking an address of a variable, and
if condition. It takes 7 lines to implement the code.
Here’s the shocker: it turns out barely 50% of candidates can correctly write this method down without any hints. We couldn’t believe it either. Some don’t know how to call a block, others don’t know how to make use of the
stop argument, while still others don’t even know what it means to iterate over an array.
Should the candidate pass the
NSArray test with flying colors, we usually proceed with another challenge, slightly more algorithmic, but one that still falls within the realm of iOS. Obviously, we don’t care if the syntax is perfect. The ubiquitous autocompletion makes it easy to forget a trailing curly bracket and that’s just fine.
Open sourcing a piece of code takes guts, so having a non-empty GitHub profile is a huge plus. We will take a look at your contributions to have a grasp of your skills and to see whether you care for code quality.
You should know what’s going on in the world of iOS development. You should be subscribed to iOS Dev Weekly and it’s great if you read issues of objc.io cover to cover. If you’re fascinated by the writings of Mike Ash, we welcome that with open arms.
Don’t be a douchebag. We understand that a good developer might have a slightly elevated ego, but if you come to the interview on a high horse, you call our process stupid and then you fail to answer even the most elementary technical questions, you might as well skip the interview altogether.
Be aware that you don’t have to answer all of the questions. The problems we’ll throw at you will represent different levels of complexity, as we will be trying to ascertain the overall quality of your skills. We try to gauge what you know, as well as how you think. A smart developer may always read up on the specific frameworks.
We don’t really have a step-by-step script for the interview. While we have some guidelines as to which topics we will be going through, we highly value discussions on the subjects we touch upon in the interview, and we often meander to further explore topics the candidate seems to be familiar (or unfamiliar) with. We constantly tweak the process by adding and removing questions so nothing is set in stone, however, we’re pleased with the results so far.