Over the past few weeks I've had a few friends and colleagues ask me about the iOS developer interview process -- both on the interviewer and the interviewee sides. Having sat on both sides of the table, this post is a collection of thoughts on how to find the right developer for the job. I should note that these opinions are entirely my own and are completely subjective.

First, I think there a few things to consider before diving straight into interview Q&As -- there's a lot more to it than just rattling off a list of Objective-C programming questions found from a Google search. Yes, that can help you find smart engineers, but it might not get you the whole picture. Here are a few main points to consider when looking at a candidate:

Published work
Knowledge of Objective-C and Cocoa Touch
The right ratio of hackerness vs convention-use
Online reputation*
Overall tech savviness

Published work

You'll want ask for examples of published work. While at Cocoa Camp last summer I noticed several things that Apple looks for in a perspective engineer. Here are two from my notes:

Someone who is driven to learn - and ship.
Someone who has an obsession with creating - and delivering.

There are lots of extremely talented computer scientists and web developers in the world, but it takes a unique blend of hard-skills and finishing ability to make a good iOS developer. While pet projects are nice, that alone shouldn't impress you. Half-baked ideas are just that, half-baked, and not something you want to publish as your company's next app. Looking at the candidate's apps on the app store will tell you more about their experience level than their resume ever could. If their work was written as a team effort, ask them which pieces they developed or what percentage contribution they made to the overall app.

Knowledge of Objective-C and Cocoa Touch

You'll want to be sure the person has a solid understanding of programming principles, design patterns, Objective-C, and the Cocoa Touch frameworks. The depth of knowledge and understanding required will vary depending on the experience level you're looking for and how much you want to pay, but here are my suggestions for a good junior-level iOS developer.

MVC pattern - Ask the candidate to include an example or explanation of how they've used it in an app.
Protocols and delegates - Ask the candidate "why are delegates protocols?" (and not normal classes). What I would look for is that the candidate can explain that protocols are more flexible than a normal class, because they can be implemented by any class, allowing for greater reuse. If they can explain this to you, in addition to the general idea behind the delegation pattern, that's a good sign.
Strong vs weak pointers - What's the difference? When would you use one vs the other?
Check out Ray Wenderlich's post on iOS interview questions.
Any questions specific to your project, code base, or existing development team that can help determine if this person is the right fit.

Hackerness vs Convention-use

I'm not sure what else to call this one. Objective-C is a very convention heavy programming language. If the candidate is a recent transplant from another development stack or a hobbyist iOS developer turned professional, they may not have fully embraced the Objective-C way (no ill-will towards these groups, I came in with almost exclusive Java/Android experience when I started with Objective-C). There are always opinions when it comes to code formatting, design patterns, and naming conventions, but with iOS in many cases there is a recommended best practice that should be followed.

You might be thinking "so what if they do it their own way, so long as it works" (especially if you're just looking for a temporary contractor). Wrong! No matter how small you think your project will be, there are going to be changes to be made down the road. And who's going to read that code? It might be the original developer, or it might not. Use of conventions allows for easier readability and better maintainability, and will lower your switching costs if the original developer doesn't work out or decides to suddenly leave for another gig.

If you yourself have a good knowledge of iOS development, brush up on your Cocoa Coding Guidelines and ask for a code sample. Look at things like use of class prefixes, method names, constants, and categories. Ask the candidate about software design. Do they design their code for personal use, quick-and-dirty, never to be touched again, or do they design their code with reusability and efficiency in mind. One of the best signs of a modern programmer is that they design their code -- internal and external -- as if it were an externalizable service - taking a page of Amazon's book. A code sample can also be useful to see their design style and identify particular areas of focus (e.g. networking, UI, data persistence, animations, etc).

Online Reputation*

I put an asterisk next to this one because I think this might be the most debatable point. For me personally though, I give bonus points for active use of GitHub, StackOverflow, App.net, and Twitter (unless its to manage a Biebs fan handle). Open-source software is huge both in web and mobile. If the candidate is familiar with pulling code off GitHub (properly attributed of course), it could definitely come in handy in the future. Better still if the candidate has contributed to open-source projects or created one of their own.

Completely on the other side of the coin, I know several excellent developers who don't care much for social media or personal branding. It's no knock on them, it's just not in their interests. That's fine too, just be aware of it and make sure the candidate is a good cultural fit for your team. e.g. if you're launching a social network for chihuahuas and the candidate isn't active on Facebook, Twitter, or Instagram, it's probably not the best fit even if they are extremely smart.

Overall Tech Savviness

Lastly, and you've probably done this by now, Google search the person's name and see what turns up. In emails or an interview ask them what they like about programming, iOS, and technology. You know this, but design is HUGE in mobile app development. It should be a big deal to the interviewee. UI/UX will make or break your business, so make sure you value this appropriately. I love that in a mobile developer job posting for Alpine Replay, their "next steps" are simply:

"Send us an email. Please include some of your sample work, a collection of your favorite designs (not yours) and whatever else you feel may be applicable."

A savvy design enthusiast who's up on the latest trends and upcoming iOS 7.1 or iOS 8 features could help take your app's user experience to the next level.

Disclaimer

All the suggestions in this post are personal opinion. Any and all of it should be adjusted to fit your needs and your team's culture.

Disclaimer: This isn't a total knock on singletons. Alternate title: "Why singletons can be bad".

Software Design

Yesterday I had a conversation about software design with an experienced colleague and found myself reaching when discussing design patterns. Specifically, we got onto the topic of the singleton pattern.

Knowing from recent experience at Cocoa Camp that singletons are not the end all be all solution for object oriented programming (yes, I might have thought that at one point), I was careful not to sound overly enthusiastic that I used the singleton pattern. I first learned about the singleton pattern in an Android development college course that I took in Winter 2011. It sounded pretty cool then, and it was even a semi-significant part of the midterm. I later began learning Objective-C, and after using the pattern in a few iOS apps over the past year - including collaborative projects with other developers who hadn't ever mentioned any negatives in the singleton pattern - I had gradually assumed that they were a pretty solid way to go. Last month at Cocoa Camp the pattern came up and although we didn't get into any detailed discussions on it, I got the impression that singletons weren't as favorable as I had thought...

Back to our conversation, I mentioned that I knew singletons had positives and negatives and explained a little more about why I'd used them in the past. He pried pried a little deeper, asking two questions that I want to expand on. "What are some of the downsides to the singleton pattern?" "What alternative design patterns would you suggest?" I mentioned a few things, including keeping the object in memory for the entire life of the application, rather than when specifically needed, and that an alternative method could be to pass the data between view controllers rather than via the shared singleton instance. Then we moved on. Conversation over.

Why singletons are bad

Later (okay, ten minutes after the conversation ended), I found Steve Yegge's blog post, Singleton Considered Stupid:

Begin Quote

Here's what most people got out of Design Patterns: "blah blah blah blah SINGLETON blah blah blah blah". I kid you not. I've seen this so many times that it's become a full-fledged pattern in its own right; patterns need a name, so let's call it the Simpleton Pattern.

The Simpleton Pattern unfolds like this:

Me: So! Have you ever heard of a book called Design Patterns?

Them: Oh, yeah, um, we had to, uh, study that back in my software engineering class. I use them all the time.

Me: Can you name any of the patterns they covered?

Them: I loved the Singleton pattern!

Me: OK. Were there any others?

Them: Uh, I think there was one called the Visitater.

Me: Oooh, that's right! The one that visits potatoes. I use it all the time. Next!!!

I actually use this as a weeder question now. If they claim expertise at Design Patterns, and they can ONLY name the Singleton pattern, then they will ONLY work at some other company.

End Quote

I really hope I didn't fall into this category in the mind of my colleague, but wow was I unprepared for those two questions. Especially the second question. There are few design patterns with a name as catchy as the singleton pattern. There certainly are other ways and methodologies to accomplish a programming objective, but what's the catchy name for instance classes, interfaces, and passing data between controllers?

I've done some more reading and in hopes of getting it right the next time, here are some of my thoughts.

What do you think are some of the downsides to the singleton pattern?

There are actually a ton. The reasoning is pretty straightforward and I don't know why I didn't think of these earlier.

A shared singleton class requires that memory be in use throughout the entire application, even when the object isn't needed.
Singletons hide dependencies!
As a result of these hidden dependencies you can lose track of the coupling. Instead of meticulously passing each object you need (and only the objects you need) into a function, you instead call [AppUser sharedAppUser] to access your shared instance. While it feels cleaner since it can mean less lines of code to get the access you need, you can end up with very tightly coupled code.
You can't (really) subclass a singleton
Singletons are hard to test! (1) With hidden coupling it's difficult to create mock objects and (2) singletons generally exist for the lifetime of the app which presents a problem for unit testing, as each unit test should run independently of other unit tests.
Just think of it as the "global-ton" pattern. The name isn't that far off. Does it still sound as sexy?

There are some upsides too, but I'll save that for another time.

What alternative design patterns would you suggest?

Object oriented programming. This isn't just a snarky answer. Use instance classes that are instantiated within the scope that they are needed and pass those objects between methods or controllers as necessary.
Create the instance of your object only within the scope that is needed (be careful not to abuse the AppDelegate).
Use dependency injection to pass a single instance of the object to the components that need it (like your unit tests).

Takeaway

Be smarter. Understand what is actually happening when you use the singleton pattern. As tempting as slapping in SynthesizeSingleton.h into an iOS project is (see http://www.cocoawithlove.com/2008/11/singletons-appdelegates-and-top-level.html), it is NOT the solution to all your problems. You may not need it at all. Tightly coupled code can be a major problem with singletons, and chances are you probably aren't unit testing (or not properly anything) whichever objects you've transformed into singletons ...which you should fix. Most of all, if you enjoy software design but can only list of the singleton pattern when trying to have an intelligent conversation about design patterns, you have homework to do.