Most iOS contract houses tend to have one or two experienced developers, along with a large number of junior people. It is also common to classify anyone with more than 3 years of experience work with Cocoa to as 'senior'. At Black Pixel, most of the developers on our staff have 7 to 10 years of Cocoa experience, and many of them are ex-Apple product engineers. The few 'junior' developers we have would be considered very senior anywhere else.
It's critical that the people we hire are good enough to keep up with the rest of the team: we run at a fast pace, and a new hire that can't keep up will make things harder for their people we're working with. Plus, it's not really fair to throw someone into the deep end of the pool without giving them some idea of how hard they are going to have to work in order to catch up with everyone else.
An applicant's final interview is with me. Over time I noticed that I was recommending that we pass on a lot of the candidates that I was meeting with, not because of any particular harshness on my part, but because it became clear that they were going to be struggling to hold their own with the rest of the team.
I eventually distilled my questions down to a basic list and started asking people to run these by applicants before recommending that they interview with me. This is by no means a comprehensive list, but it's enough to get a feel for where people are in their technical progress.
I'm generally looking for "yes" (where applicable) to all of these, along with the ability to speak knowledgeably about their experiences:
1. How do you handle asynchronous networking?
2. Have you ever worked with multi-threaded Core Data?
* How was it?
* What approach did you use?
3. Have you ever worked with Core Animation?
* Can you tell me about that?
* What kind of animations? (grace notes for an app versus canned table view insertion or bulk affine transforms)
4. Have you ever worked with Core Graphics? (answer for Mac devs should be a resounding "HELL YES I DID")
* What kinds of things did you do?
5. Have you ever filed any verified issues against Apple frameworks on radar?
* Can you describe them to me?
* Better still, can you point them out on open radar?
6. Compare and contrast NSNotification vs KVO.
* When would you use one or the other? What are the implications of using them?
7. Have you ever worked with NSOperationQueue?
* What did you use it for?
8. Please tell me about your Core Text experience.
9. How would you use NSURLConnection on a background thread?
10. What kinds of issues should someone be aware of when working with blocks?
11. Have you ever built any custom frameworks or libraries?
* What's your preferred method of working on an application in parallel with a library?
These are standard, practical technologies we work with every day, not an abstract set of obscurities we're asking about out of some kind of elitism. I don't necessarily expect a solid command of all of these, but if someone can't clearly and articulately get through a conversation about the majority of them, they probably aren't ready to be a good fit for our team.
Asking questions like these helps ensure that the developers we bring on board at least have enough of a technical background to get started working with us, and they also give the people applying an idea of areas we'd like to see them improve on if they want to try and come on board further down the road.
Obviously the person asking the questions has to have a good enough command of the material to assess the responses, but I've found this to be a fairly concise way to get a temperature read on an applicant's skill set. If you're looking for a senior developer for your company, these questions might help you determine if the person you're talking to is a good technical fit, too.
Likewise, if your lead developer can't talk about these technologies intelligently, that person isn't going to be able to advise which to use in a given situation. If that person isn't actively seeking out people who can help with gaps in their expertise, you're likely in for trouble.