views:

332

answers:

3

Can anyone suggest a few basic phone screen interview questions for prospective Mac OS X desktop application developers?

Just something to help determine if the candidate has really done real development on the Mac as opposed to someone who knows some buzzwords and is trying to fake his way into an in person interview.

TIA.

A: 

I like to ask: "If you could change language X (Objective-C 2.0), what one feature you would add (or remove)?"

This usually shows a candidate's grasp for the language. For an in person interview, I always ask them to write a very small program on paper.

brianegge
A: 

Describe the basic memory management facilities in Objective-C. Expect them to understand retain, release, autorelease, GC, properties with auto retain, etc.

Describe ObjC support for static and dynamic binding. Compare contrast usage of each.

Make them program something in ObjC -- something simple, but they have to read it to you over the phone -- I guess make sure it needs something that isn't just C if you care.

Lou Franco
If someone asked me to read a program to them over the phone I'd laugh and hang up in their ear!
Chris McCall
Sorry, but I'm sick of having non-programmers try to get jobs. I make them recite something like FizzBuzz before they come in.
Lou Franco
+1  A: 

For a senior developer, ask for some information about a Radar they've filed. Any senior developer should eventually have encountered a Cocoa bug, and a good one will have filed a Radar.

I agree w/ Lou about memory management questions. Any serious Mac developer should know the rules of memory management cold, including the three magic words. Anyone who says "I only use garbage collection" hasn't been developing very long because it only came in with Leopard, and it's not available on iPhone.

A senior developer should know the Core Foundation memory management rules, and should be able to explain what "toll-free bridging" is. (A true CocoaHead should then wax poetic about what how incredible and elegant a concept toll-free bridging is, but maybe that's just me.)

A senior developer should be able to name several Frameworks outside of Cocoa. Specifically, they should be familiar with at least one Framework that does not link by default and they need to add to their project (any serious developer will have encountered this problem).

Any Mac developer should be able to easily explain what would cause EXC_BAD_ACCESS.

Any Mac developer should know what happens if you send a message to nil.

A senior developer should be able to explain an NSInvocation, at least to the level of how you would use one.

A senior developer should be able to explain the use of method swizzling, at least in broad terms.

Any Mac developer should be able to explain the MVC paradigm, and describe how to break down a simple problem into Models, Views and Controllers.

Rob Napier
Ask to explain autorelease pools, and ask them about setter and getter methods. Ask them to code a getter and setter method for an object field. Key/Value Coding would be a fun thing to include. And isn't Method Swizzling evil? You don't have source code to the framework. so how do you know what you're breaking? In Win32 world, we call it "hooking", and it's done a little differently, and it's been the source of incredible pain for me. I'd find almost any alternative and use it before I'd touch a low level hack. (Apparently each version of objective-C runtime requires different hacks)
Warren P
Agree on accessors and particularly how to code one. KVC is good as well. Method swizzling is the basis of KVO, so a senior developer should understand it, and it demonstrates an understanding of the implementation details of ObjC, which I expect of sr. developers. Another way to ask the question is "When you call a setter on a KVO observed object, willChangeValueForKey: is called automatically, even though it's not in the setter code. How is this achieved?" An intermediate developer should at least be bothered by this surprising behavior, and a sr. developer should know roughly how it's done.
Rob Napier
Oh, and method swizzling is incredibly useful in debugging and performance analysis when you want to know when a framework method is being called (by allowing you to easily inject logging code). But no, it shouldn't be used broadly (and very seldom is in the code I've looked at). It's very confusing.
Rob Napier