By Benjamin Sandofsky in App Dev — Nov 16, 2014

How I Interview

A student recently asked for iOS interview tips. I've interviewed hundreds of candidates, and whiteboard coding only makes up a small part of my interview. Some of our best hires came with virtually no iOS background. Based on what I look for, I've settled on this format.

Your Current Project

I warm up with, "Anything cool you've been working on lately?"

These questions provide context. If you're coming from games, I won't ask about REST APIs. If you've been working on Android, I'll keep my questions platform agnostic.

Your Hardest Problem

What's the hardest technical challenged you've encountered? How did you go about solving it? I guess this is a behavioral question. Recruiters love them because, supposedly, past patterns are the best predictor of future performance.

I'm more interested in what they consider hard. A typical candidate talks about troubleshooting bugs in iOS frameworks, but I had one candidate recall working in embedded software for cable company DVRs, and how he debugged an mpeg decoder that failed at the same time every week.

Whiteboard Coding

Whiteboard coding is overrated. I never have to code without an IDE and search engine. Writing code on a board is like interviewing a designer by asking them to draw a perfect circle, freehand.

However, whiteboard coding does reveal the candidate can follow instructions, can think analytically, and isn't making up their resume.

My favorite go-to problem is: "Implement a function that takes two strings. The first string is text to search, and the second is the text you're searching for. The function returns the index of the first match."

  searchString("Hello World", "World") // -> 6

I don't care about efficiency. In real life, I start with the simplest thing that works, and optimize if it's a bottleneck.

Domain Specific Knowledge

I treat technical questions as an entry point to a conversation. If I ask about event patterns, you could just tell me, "Target/Action, delegates, and Notification Center." If you want to stand out, keep talking. I love to hear opinions like, "I avoid Notifications unless it's a one-to-many relationship, because debugging gets harder." Even if we disagree, you can talk about your real world experience. If you disagree without appearing cocky, it's a sign you can work well with others.

I avoid CS questions because I'd probably fail them. I've never had to implement Quick-Sort. I only pull out CS if I'm interviewing a candidate fresh out of school.

These are some questions I ask a typical iOS iOS developer:

What are the common event handling patterns in Cocoa?
Describe reference counting. What's an autorelease pool?
What are some advantages and disadvantages of Interface Builder?
What is a CALayer?

If I'm put on an Android interview panel, I stick to generic questions:

If you had to download 50 avatars, why wouldn't you fire one thread per request?
What are some challenges of working with a garbage collector? How would you work around them?
Could you describe some challenges of working with a cell phone's radio?

I asked Twitter for their favorite Cocoa question, and got these:

What provisioning profiles & certificates do you need to run a sandboxed app on a iDevice? -- Tzeejay
What are the caveats of copying a mutable collection? -- warrenm
How ARC works, differences between strong, assign, weak. I'm surprised about how many people with years of exp doesn't know that. -- jlaube77
High level coverage of basics (mvc, delegation, protocols, iOS patterns, experience w/iOS frameworks) is surprisingly effective. yipe
What are the caveats of copying a mutable collection? -- warrenm
Implement an NSDictionary equiv class where the object references are weak. -- jazzychad
Create an app with a button that changes a text field. Would knock out 90%+ of people. -- tapbot_paul 1 2
Implement -autorelease -- dinhvh
Implement a property setter (without arc) -- mpv

Why Here?

What interests you about working here? Don't say, "I live in the city." I want to hear enthusiasm about something at the company. If you can't think of anything, this is the only time in the interview where it's OK to lie.

Any Questions for Me?

You're already under NDA, so any questions about me, the team, the company, or anything? I regularly get small talk question like, "What's your favorite part about working at the company?" Deeper questions tell me you've put serious thought into the position.

Other Thoughts

Riddles?

Google stopped asking brain teasers like, "Why are manhole covers round?" Ten years of data show the data is useless for hiring. Unless you want to test how a candidate acquiesces to an inane superior, stop perpetuating this cargo cult.

Side Projects

Side projects stand out. Maybe there's something you could open source, or an app you wrote to scratch your own itch. One candidate showed me a todo list app tailored to his personal workflow. These projects excite me because it suggests you love what you do.

Personality

The best engineers I've known were also the most humble. The Dunning-Kruger effect is real, and the more skilled you become, the more you underestimate yourself.

No matter how skilled, I will never hire a candidate I suspect of toxic traits like hubris, duplicity, argumentativeness, or sexism. It's never worth it.

Presentation

The most stressful day on a job is the interview, so I try to read beyond the candidate's nervousness. However, most people have a cognitive bias toward confidence. A successful comedian once told me you can get a laugh from just about anything, so long as you sell it.

It's hard to muster confidence, but there's good news: no matter how nervous you may feel, I want you to succeed. I want to fill this position. I assume the other person is smarter than me until proven otherwise.

One way to cheat is to become aware of your body language. You don't need a poker face, but just being aware makes you look better than most people. Just as important, I believe that if you pretend to be more confident, you'll start feeling more confident.

Accepting Failure

Over the years, I was rejected at a number of companies I really wanted to work at. It feels crushing. Ask what you could have done better, and put that into action, but don't take get hung up on it. Looking back, getting rejected was the best thing that happened to me.