iOS Interview Questions

Note from Ray: This series is on a very subjective topic, where there are thousands of different opinions. This article reflects Kyle’s views, and not necessarily mine or those from this site. We’d love to hear your own thoughts after you check it out too! :]

Welcome back to our three-part series on applying and interviewing for an iOS developer job.

• In the first part of the series, you focused on the applying part of the equation – i.e. preparing your resume and cover letter.
• In the second part of the series, Ray showed you a few examples of some iOS resumes and cover letters he likes that might be useful for reference or models.
• In this third and final part of the series, you will focus on the interviewing part of the equation – i.e. what types of iOS interview questions to expect and prepare for, and how to do your best in an interview.

Again, remember that these are the kinds of questions we ask when we hire folks at Empirical Development, but remember that different companies interview in different ways so your experience may vary.

I hope some of this knowledge helps you land your dream job!

Preparing for the Technical Interview

Before we get into the questions, first let’s discuss some general tips to make sure that your technical interview goes as smoothly as possible.

Focus on the Basics

You can’t prepare for every possible question, so you want to pay special attention to the basics. Make sure you are familiar with the features of Objective-C 2.0. You can expect questions about about messaging, protocols, dynamic types, forwarding, categories, posing, method swizzling and so on. The interviewer will want to see how much you know about current or recent problems. A couple of hours looking at the most-asked recent iOS questions on StackOverflow may prove helpful.

Read over Apple’s Objective-C guides to make sure there are no topics on which you feel weak. Most organizations have stopped asking Google-esque questions like how many golf balls fit in a school bus (250,000) or how many windows are in San Francisco (> 1 billion), but you may want to prepare yourself for the possibility. When you are faced with these types of questions, the answer isn’t as important as your thought process. Talk out how you are working towards an answer – that is what the interviewer cares about.

Be Ready for Whiteboard Coding

If your interview is in person, you might also be expected to perform some whiteboard coding. Make sure you practice this a little before you go in, because with the pressure of performing in front of someone and the lack of autocomplete it may prove harder than you are expecting.

Be prepared to do whiteboard coding for any language you claim to know on your resume. A friend of mine was asked to whiteboard Erlang during an interview since he had listed it on his resume. He got the job, and I maintain that he is one of three people on Earth who knows Erlang.

Interview Etiquitte

If you have an in-person interview, make sure to ask about the company’s dress code. Showing up in a suit when the person interviewing you is wearing shorts and a t-shirt is embarrassing for you and possibly off-putting for the interviewer, and the same goes for wearing a polo shirt when everyone else is wearing a suit. The hiring manager will be more than happy to advise you.

Make sure to silence your phone. You would be surprised how often I’ve heard a phone go off during an interview. Under almost no circumstances should you answer or look at your phone during an interview. If there is some sort of potential emergency situation, like your wife may be going into labor soon or your husband is undergoing surgery, let the hiring manager know beforehand so that when you do check your phone, it’s understandable.

Make sure you are well rested, both mentally and physically, when taking an interview, and try to schedule the interview when you don’t have anything else going on. Cramming it into a lunch break from your current job will not produce the best results. I have even had a few interviews cut short because the applicant’s current boss needed something! Avoid compounding the stress you will already feel.

For an in-person interview, arrive 15 minutes early, but no earlier. For a phone interview, if it is on a conference line make sure to dial in about two minutes early. When calling someone directly, make sure to be right on time.

Be Ready with Questions

At the conclusion of the interview, you will often be asked if you have any questions about the company or job. Make sure to prepare for this question and have a couple of topics written down. It shows that you are actually interested in the job and aren’t just going through the motions. I am amazed at how many applicants ask nothing during this phase. It’s a great chance to learn if the job could be a good fit for you.

The Questions

Now for the time you’ve been waiting for – the questions!

Our technical interviews last one hour and I have a sheet of 75 questions from which I will draw randomly at first. Then, depending upon what I learn about the candidate, I will tailor my choice of questions somewhat. For example, if I suspect the candidate has a weak spot, I will hone in on that area.

I do have favorites and go-to questions that will have to be retired after the publication of this article. Expect my first question to now be: Have you read this article? :]

When answering questions, try to keep your answer brief and explain your thought process when it is beneficial. The interviewer isn’t asking you these questions because they don’t know the answers – they want to see if you know what you are talking about.

Note that I’m just going to list the questions here, not the answers. That’s for you to figure out, if you don’t know already – learning is half the fun! Feel free to share the answers in the forums once you’ve figured them out.

Without further ado, here are some sample questions for the technical interview:

What is the difference between frames and bounds? — I don’t ask a lot of GUI-type questions and I probably should ask more, but this one gives me an idea of how much layout work a developer has done.

• Explain method swizzling. When you would use it? — I like this question because it’s deep language. Most people will never need to use swizzling. The developer’s answer to this question also shows me how much restraint s/he has when implementing complex code. An answer of “I swizzle everything” is much scarier than someone saying they have never worked with it.
• Take three objects: a grandparent, parent and child. The grandparent retains the parent, the parent retains the child and the child retains the parent. The grandparent releases the parent. Explain what happens. — Even with ARC, I like to ask a lot of memory-related questions, as it shows that someone has been around for a while and has core knowledge about how things work.
• What happens when you invoke a method on a nil pointer? — Basic Objective-C handling is important and it’s shocking how many times I have heard wrong answers to questions like this.
• Give two separate and independent reasons why retainCount should never be used in shipping code. — This question has two benefits: to make sure someone isn’t using retainCount and to see if they understand why they shouldn’t use it.
• Explain your process for tracing and fixing a memory leak. — This dives into the applicant’s knowledge of memory, instruments and the debugging process. Sometimes I hear things like “start commenting out code until it is fixed,” which is slightly terrifying.
• Explain how an autorelease pool works at the runtime level. — These types of questions go beyond the basics a programmer will learn from a couple of books and investigates his or her knowledge of how things actually work.
• When dealing with property declarations, what is the difference between atomic and non-atomic? — Once again, it is shocking how many people don’t know the answer to this question. Many just declare properties a certain way because it’s what they’ve seen others do. Questions like these expose those issues.
• In C, how would you reverse a string as quickly as possible? — I don’t like to dive too deeply into computer science, but this question lets me know how someone thinks about performance as well as about his or her background in C. I have also been known to dig into big O notation.
• Which is faster: to iterate through an NSArray or an NSSet? — Another deep dive. Sometimes just because a class solves a problem doesn’t mean it’s the one you should be using.
• Explain how code signing works. — A lot of applicants have no idea how code signing works and then complain because they are having code signing issues.
• What is posing in Objective-C? — Posing is a little-used feature of Objective-C. Like the swizzling question, this gives me an indication of how deep someone has dived into the language.
• List six instruments that are part of the standard. — This question gives me a general idea of how much time someone has spent in instruments. Hint: It should be at least 10% of your coding time, if not more.
• What are the differences between copy and retain? — Memory questions reveal a lot about a developer’s knowledge, especially since many people are leaning on ARC these days.

What is the difference between frames and bounds? — I don’t ask a lot of GUI-type questions and I probably should ask more, but this one gives me an idea of how much layout work a developer has done.

• What happens when the following code executes? Ball *ball = [[[[Ball alloc] init] autorelease] autorelease]; — Another memory question. The answer I am looking for here is not just that it will crash, which it will – I want to know why and when.
• List the five iOS app states. — Almost no one gets this question right. Normally I have to give an example, such as background state, for them to know what I am talking about.
• Do you think this interview was a good representation of your skills as a developer? — Some people test well and some don’t. I like to give people the option to explain their results a little. Confidence is important and the answer to this question can reveal a lot about a person’s confidence.

Many of these questions can be followed up with a “Why does that happen?” or “Explain your thinking in getting there.” The point of a technical interview is to determine just how much of a language or platform a candidate knows – and as you’ve seen, not just the breadth of knowledge, but the depth also.

The technical interview doesn’t do much to reveal what a person is like as a developer – it simply determines if someone is worthy of moving forward in the process. The best academic developers who may knock the technical interview out of the park may completely fall to pieces in the practical coding interview, but someone who bombs the technical interview won’t be a good candidate for the position. If they can’t discuss topics such as these with their coworkers, then they won’t be able to contribute to the growth of the team.