Cacher is the code snippet organizer for pro developers

Hi Jonathan,

My name is XXXX. I currently work at XXXX, but have been building apps on the side for the past few years, and have my first tech & iOS engineering interview in a few weeks. I’ve looked up to you and your work for quite a while, and was wondering if you had any tips or advice.

I’m completely self-taught and lack a formal CS background. I think I can hold my own with Objective-C/Cocoa related questions, but am worried that it might be a more general-purpose engineering interview. Do you have any anecdotes from past experiences? Most importantly, I have been studying, but am still uncertain on the type of iOS-specific questions they are going to ask. I realize this is different on a company-by-company basis, but would you be able to provide any insight? I appreciate any help you can offer.

Thanks

Hi XXXX

As you say, every company is different. But I find in the Bay Area there's definitely a lot of (IMO too much) focus on pure algorithms. Fortunately there's a lot of good information out there - look for info on Google interviews - they're particularly heavy on algorithm questions. I too lack a formal CS education (or rather I'm a CS dropout)

• many of these algorithms based interviews seem to be focused on hiring Stanford Grads and I don't think are great at finding good iOS guys. But learning the basics of O notation, reading up on common algorithms (Sedgewick's Algorithms in C is a great book) and practicing a few Google style questions will help a lot.

I think a balanced interview schedule would be based partly on algorithms (often along the lines of "how would you implement a solution to blah") and then focusing on the day to day problems iOS developers need to solve. I personally like to find out where an interviewee's wounds are. i.e. what kind of things trip them up and what they'd like to change in the iOS SDK. I find people who don't have strong opinions about iOS development haven't really been around the block and may not be as experienced as their resume might claim. Plus, iOS apps all share various common problems that most developers would likely hit - stuff like delegate methods triggering after the delegate has been dealloc-ed, or various UITableView cell reuse problems.

Common topics that most interviewers will focus on (or at least should) involve memory management, callbacks, networking and threading.

For memory management I ask about the differences between property attributes assign, weak, strong and retain (yes I know the last two are a trick question). This is a pretty basic question - but occasionally people will trip up on the exact behaviour of weak. Even though ARC has made memory management less tedious it's still important to understand what's going on. I've (mostly) stopped asking people about @autoreleasepools because I've found people just don't use it much if at all any more - this is especially common in junior developers. My new favourite trick question is to ask the candidate to explain the difference between [NSString copy] and [NSString retain] (hint: there's no difference). (*)

For callbacks I ask interviewees about the pros and cons of delegates, blocks, notifications etc. This often leads onto the woolier topic of class design and use of protocols and so on and occasionally onto MVC (I don't focus on MVC because well - I don't believe developer practice matches the theory of MVC). Sometimes it will often lead onto the __weak vs __strong problem in sync block callbacks - I've found this is a great problem to differentiate new from experienced developers.

For networking I'll often branch back into callback territory (and sometimes threading territory too) - I like to ask about techniques to fetch avatar images inside a UITableViewCell. This is a great chance to talk about cell reuses problem too (which although aren't rocket science a great way to gauge how much iOS code a dev has written). Networking is dramatically easier these days than it was before - so it's less of an interesting topic. But it does touch on so many other topics (threading, caching, etc etc).

For threading - I again use the avatar image in UITableViewCells problem. This topic will highlight basic stuff like if the developers knows about not calling UI code on background threads etc. A common more advanced question I like to ask is how to make a hash table thread safe and then how to optimise it so it works with multiple readers and/or writers.

I do like to ask about the developer's background too - esp. if they have interesting projects on their resume. I know a lot of companies (Google?) will basic avoid asking any career background questions and focus on a set of "exam" questions. I don't think that's a good way of hiring outstanding individuals. But I think I may be atypical here and most people focus on set questions.

I'll often ask about optimisation too - starting by describing some code that is slow and asking the candidate to walk through optimising it. Distressingly few people have a strong optimisation toolbox. I think it's important that developers can explain (roughly) the things they'd do when trying to optimise code. It's generally not enough to just say "I'd use Instruments".

I personally don't like getting people to live code. I think it puts insane pressure on people and I'm not interested in code - I'm more interested in how people think. It's much easier for a candidate to talk about how they'd solve a problem than it is for them to focus on the code and I think it allows them to "noodle" with ideas even if they're unsure.

But basically - know your basics. Algorithms (brush up if you're weak here) and memory management being the two most important basics.

I'd also recommend open sourcing something and putting it on github if you haven't already. My open source code has been a huge boon to my career. Find something you're passionate about or might be useful to other people or is just fun and code it and write it up - I saw a little Pong game implemented in Pull to Refresh in iOS Dev Weekly today

• if I saw that on some candidate's resume at the very least it would be a talking point and something for me to help frame an interview question or two on.

I do think I'm a somewhat atypical interviewer perhaps - so all this is definitely from my personal perspective obviously: but I hope this helps.

(* Oops original copy had a mistake) ( Fixed most embarassing typos)