iOS Interview Questions

Kyle Richter Kyle Richter

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! :]

iOS Interview Questions!

Check out these iOS Interview Questions!

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:

  • 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.

The Practical Coding Interview

This is the most important interview that we do, as it is meant to reflect how well the applicant will perform at the job. We give the applicant an app we call The Dragon’s Test, which is broken in known ways. We then give the applicant a list of bugs and grade the applicant not only on the solutions they use but on the time it takes them to complete the task.

Since our company provides iOS development services to large corporations, we aim to deliver solid results to our customers with a quick turnaround. So the coding interview is a crucial evaluation for us because it lets us determine what the person can be paid to remain profitable. Finding developers who can implement solid solutions very quickly is the holy grail of software interviews.

There is a delicate balance to be struck between attention to detail and completion time, but I’d rather have someone who gets us 95% of the way there in 1/3rd of the time than someone who gets us 100% of the way there in more time. If there is one secret to how we consistently choose the top tier of our employees, it is this practical coding exercise.

Unfortunately (or fortunately, depending on how you look at it), the best way to prepare for a practical coding interview is just experience. The more apps you make, the more likely it will be that you can develop code quickly and solidly. So keep practicing and learning! :]

Where To Go From Here?

Let’s sum up:

  • Practice the basics of the computing language and make sure you are well-rested for your interviews. During the interview, talk about the company to which you are applying and its products. Keep your interview answers brief and on-topic.
  • When doing any kind of coding, keep turnaround time in mind. The speed at which you complete the task will make or break a project. The faster you can put out good code, the more valuable you are, and the more valuable you are, the more the company can afford to pay you.

Ray and I hope you enjoyed this series! Let me know if you’d like to see more articles along these lines – we could discuss how to build your skills as an iOS developer, how to find iOS jobs, or how much you should expect to be paid as an iOS developer. Let us know what you’d like to see if any! :]

Also, do you know the answers to any of the iOS interview questions I mentioned above? If so, join the forum discussion to compare your results!

Kyle Richter
Kyle Richter

Kyle Richter is the Chief Executive Officer at MartianCraft an award winning Mobile Development Studio. Kyle began developing software in the early 90s and has always been dedicated to the Apple ecosystem. He has authored several books on iOS development including Beginning iOS Game Center Development, Beginning Social Game Development, and iOS Components and Frameworks Advanced Programming.

Between running day to day operations at MartianCraft Kyle travels the world speaking on development and entrepreneurship. He currently calls the Florida Keys home where he spends his time with his border collie. He can be found on Twitter and is available for birthday parties and other engagements.

User Comments

28 Comments

[ 1 , 2 ]
  • Can you help me about objective-C
    rakeshthummar
  • Hi Kyle, I think quite a few of these questions are valid, but they focus largely on interesting things about the "car" vs. how efficiently to build the "car" - and by efficient, I mean making best use of already created patterns and framework classes that . These questions are all over the internet and can be easily answered if someone has a prepped themselves and merely memorized them.

    GUI is the only way that we communicate with the customer - so it really needs to be front and center in questioning.
    Julian_Car
  • Can u provide complete iphone note and topic vise interview questions with clear explanation.
    Koteswararao
  • Download ios_interview_questions.zip from http://bizzydevapps.weebly.com/
    Ram#
  • Hi Kyle,

    I really enjoyed this series. You (and others writers) could go on with these subjects.

    I would like to read articles with your suggested subjects like: how to build your skills as an iOS developer, how to find iOS jobs, or how much you should expect to be paid as an iOS developer.

    Thanks :)
    Luis Jacintho
  • One of my favorite questions for candidates comes a bit from left-field: "What annoys you about Xcode?" There is not really a correct answer in this case. What's more important is how quickly the answer is give. It gives a quick idea of what the experience level is.
    WaltSellers
  • I'm with hamuggi on this one. I thought there was going to be a discussion on the answers. It'd be a great source of knowledge.

    I'm also in the same page with the guys who state that answering text-book concepts is hardly the best way to measure the value of a developer. The thing is that I think the extremely good devs do know most of this and on those interviews they want to separate not-good-enough from good and good from great.

    It's always be good to at least have an idea on those topics and try to get a position according to your level of knowledge and expertise.
    juan294
  • There is a discussion on the answers... it's the one you create. Seriously, if you want to get talking about one of the answers let's do it, but a list of correct answers isn't going to help that much - you'd probably forget it if you just read it once anyway, I know I would. All of the team will join in and explain as best we can. tomredman wanted to know about the NSSet vs. NSArray question so some code was written and the timing difference was dramatic, that's the kind of thing you should be doing for answers you don't know.

    I like these questions and I do think they help to differentiate between a good and an average developer. To put it another way, if everything else was equal I'd take the person who could answer all the questions over one who couldn't. Of course the actual interview matters as much as the content of the answers as does a coding exercise, cultural fit (does the candidate laugh like a hyena at random moments? Has the candidate bathed this week?) and anything else, like recommendations from people you respect.
    aeberbach
  • Enjoy More iOS interview Questions at
    http://huntmyideas.weebly.com/blog/cate ... nd-answers
    jitenrahul
  • Vicky1234
  • Awesome collection!
    Got another stuff here.very useful.
    http://huntmyideas.weebly.com/blog/cate ... nd-answers
    Vicky1234
  • The problem with this style of interview is that it's subject to confirmation bias of the interviewer. In other words, the interviewer will undoubtedly find many good candidates by only hiring those which pass these challenges, and then believe this process is effective, all the while not realizing that there is a huge, vast number of equally qualified and excellent developers who will not pass such tests that are being inappropriately weeded out.

    How is this possible? The reason is that the tests in no way reflect what the actual job is about. When we code, or create apps, we do not rattle off inane lists of sophomoric technical definitions which can easily be ascertained on demand. That's trivial, and doesn't separate good coders from bad ones. The true test of a good coder is in their results; in the product they generate.

    The truth is that different people work differently. We may each be able to arrive at excellent code or results in our own unique ways, and assuming that another senior programmer MUST do it the way that YOU did it is not only arrogant, it's shortsighted. Assuming that if a senior coder doesn't know off the top of their head how some confusing Objective-C brainteaser works that it means they won't write excellent code is a fallacy.

    I'd suggest the best way to judge a coder is simply to give them a full project, set a deadline, and ask for it to be delivered in whatever way the programmer sees fit. That way you can judge a full, real product that was produced by non-artificial means in a non-artificial setting. Only then will you not be passing over all the excellent talent that you previously may have overlooked because they (rightfully) rejected your asinine interview games.
    jlytle
  • I am passing values from table view to collection view controller using SwReveal view controller. when I click a cell in collection view I stored the collection view cell's index path. But when I select a table and pass a value to the index path collection view. The cell not displaying the value. It is null... here is my code


    -(void)viewWillAppear:(BOOL)animated{
    text=seltext;
    NSLog(@"text %@",text);

    **// HERE I AM GETTING VALUES FROM TABLE VIEW CONTROLLER**

    self.displayindex=Viewindex;
    NSLog(@"self dispaly %@",Viewindex);

    **// HERE I AM GETTING INDEX PATH OF SELECTED COLLECTION CELL**

    Cell *cells = (Cell *)[collectionData cellForItemAtIndexPath: self.displayindex];
    cells.subjectLabel.text=@"djhfkjdshfjkhd";
    cells.cellView.backgroundColor=[UIColor greenColor];
    NSLog(@"cell is %@",cells);
    NSLog(@"text %@",text);

    **// CELL IS NULL HERE AND NOTHING IS DISPLAYING EVEN IF I PASS THE CELL FRO ITEM INDEXPATH**

    }

    CAN YOU PLEASE HELP ME IN THIS CODE
    anusha_b
[ 1 , 2 ]

Other Items of Interest

Ray's Monthly Newsletter

Sign up to receive a monthly newsletter with my favorite dev links, and receive a free epic-length tutorial as a bonus!

Advertise with Us!

Vote for Our Next Tutorial!

Every week, we alternate between Gaming and Non-Gaming tutorial votes. This week: Gaming!

    Loading ... Loading ...

Last week's winner: Apple TestFlight Tutorial.

Suggest a Tutorial - Past Results

Hang Out With Us!

Every month, we have a free live Tech Talk - come hang out with us!


Coming up in January: WatchKit.

Sign Up - January

Our Books

Our Team

Tutorial Team

... 60 total!

Update Team

  • Zouhair Mahieddine
  • Riccardo D'Antoni

... 12 total!

Editorial Team

  • John Clem

... 17 total!

Code Team

  • Orta Therox

... 3 total!

Subject Matter Experts

  • Richard Casey

... 4 total!