views:

2063

answers:

11

My company is starting a new branch with IPhone development and we need to hire a developer.

I like to test this person in his/her skills in iPhone developement (Objective-C etc) and general programming skills.

iPhone programming skills is not a must to apply for this job but I still like a have a iPhone/Obj-c theme on the questions to test how good the applicant is at learning new technology.

As I'm not proficient in iPhone developement myself I'd appreciate if the SO community could help me gather some good programming questions.

The one who can come up with the best question+answer that test the most aspects of a iPhone developer's work wins the accepted mark! :)

+31  A: 

Every question is going to have a subjective answer, so how can you possible administer this test without knowning about iPhone development yourself?

Why don't you have your applicants bring a demo app into the interview, along with source code, where you two can discuss things together?

Outlaw Programmer
I personally agree with you
Stefano Driussi
I think a demo app along with a quick demonstration of the creation of a simple application as another responder suggested would be best. A demo app allows for demonstration of deeper understanding and further discussion about why they did something, the creation of a demo shows basic understanding.
Kendall Helmstetter Gelner
Ask them to bring some demo code/app for discussion, discuss general app topics - discuss basic concepts - no trap questions (as you don't require iphone genius just want to see what they know) but as you are not proficient with iPhone maybe hire a good senior iPhone developer as consultant, for a day or two, and ask them to help you to go over applications and to help interview applicants. He can discuss iPhone specifics with applicants while you can still judge general knowledge, coding and communication skills. Ask memory management, properties, view management, tab navigation, MVC ...
stefanB
+1  A: 

I would test their C. Give them the quicksort test or any of the standard C tests as a gatekeeper.

Then, ask them how to figure out which UIView is being touched. Their answer should be clear enough and demonstrate confidence.

Lastly I would want someone with either strong demos showing they know the platform, or better yet deployed apps in the AppStore.

Genericrich
+1 I think knowing C is probably good enough. Like many people, I'm just starting to get into Mac/iPhone development, so it's very likely to run into a candidate that's an awesome C programmer but they just haven't had any experiences with Apple environments yet.
Outlaw Programmer
+4  A: 

If you don't want to ask iPhone specific (objective-c and cocoa touch) programming questions, you could ask for an rough interface mock up. This would at least let you know if your candidate understands the platform and the controls available on it. To educate yourself on possible answers I would pop open interface builder, look at the various controls and possibly string together a rough interface. As far as general dev skills, I would just look for a good working knowledge of C. Learning obj-c and apple's interfaces should be pretty accessible to a seasoned C programmer.

Nick
+1  A: 
  1. As them What features of Cocoa framework are not available on the i-phone, and vice versa.
  2. Ask them what they know about MVC (some iphone apps will be developed using this model).
  3. Ask them what different touch types there are for the i-phone.

Possible answers.

  1. i-phone has the location library, and touch, but it doesn't have feature x.
  2. MVC in Xcode will create a project with 2 .m files and their companion .h files. One with Controller appended before the extension and the other with View append before the extension. Also the philosophy behind MVC is ....
  3. Swipe. tap. pinch. ...
J.J.
And how do you adjust their score if they spell it "i-phone" instead of "iPhone"?
Chris Hanson
:-D Double check their NSString objects :-P
J.J.
When I first started coding Perl, I would spell it Peale. I was teaching myself from the Learning Perl book while I was misspelling it. Kinda sad history is repeating it self. I learning from a book with "Learning iPhone ..." on the front of it as well :-(
J.J.
Question 1- I've only ever programmed Cocoa for the iPhone. I wouldn't have a clue what is available on other platforms. Moreover, 3 can be answered without any experience of programming the phone, just using it.
Airsource Ltd
J.J., your understanding of MVC seems to be a little bit lacking… Also, all iPhone apps will be developed using this model, not just some.
Jonathan Sterling
@Jonathan: How does it feel to pick on my post 9 months later? Do you really have a full understanding of my comprehension of a subject based on 2 sentences I wrote? Ok, what if you you did peg me? It has been 9 months! Who's to say I haven't become an expert in that time frame? Does your comment really add to this discussion? All I saw was you make me look bad/dumb to people who halfway agree with you, and made me feel like I was picked on.
J.J.
+6  A: 

If you're just trying to test their raw knowledge of iPhone coding...

Start them with the standard C reverse a string test. If they can't do that to 90% accuracy, they're not a C programmer (typos and out-by-one errors only count as errors if the applicant can't correct them with hinting). It's the standard test and any good C programmer has done it 3 times before in interviews and won't hesitate.

Maybe ask them to sketch out code for a tableView:cellForRowAtIndexPath: method constructing a UITableViewCell with a text label and disclosure indicator. This is hands down the most commonly implemented construction on the iPhone. They don't need to memorize the names of the methods or constants but all the steps should be there.

Accurate solution is:

- (UITableViewCell *)tableView:(UITableView *)tableView
    cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *cellIdentifier = @"MyDisclosureCell";

    UITableViewCell *cell =
        [tableView dequeueReusableCellWithIdentifier:cellIdentifier];
    if (cell == nil)
    {
        cell =
            [[[UITableViewCell alloc]
                initWithFrame:CGRectZero
                reuseIdentifier:cellIdentifier]
            autorelease];
        cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
    }

    // Configure the cell
    cell.text = label;

    return cell;
}

Important steps are: get an identifier (unique for this row-type), dequeue, conditional if doesn't exist, construct, set accessoryType (this is optionally outside conditional), set label, return.

Matt Gallagher
Funny, I've done a few of these, but I never actually had to think of doing the dequeue thing because it's already there when you create a new UITableViewController class!
squelart
+4  A: 

Assuming you have already tested applicants on their basic C and algorithms skills on a whiteboard, provide them with a Mac and ask them to develop a simple app, e.g. a todo list... If technically possible, allow access to Apple dev site and stackoverflow (and more if they ask).

Leave them alone for 1-2 hours, this should give them the best chance to prove actual coding skills with less of the nerve-wrecking code-on-the-board-while-we-watch-you-sweat environment.

After that, if you're not 100% sure about someone but feel there's potential, ask them to come and code stuff for half a day (paid). I've done that a couple of times and it was useful.

On a final note, I would generally agree that a great C coder would probably be better than an okay iPhone coder. However, if you explicitly advertised for an iPhone dev position, they should have at least shown enough interest to read about it and they should already understand major principles (ObjC features, rough Cocoa Touch hierarchy...) Owning an iPhone is a plus too.

squelart
I like this Idea.
J.J.
Unless I was just out of college or interviewing with an upper-tier tech company, there's no way I'm writing code for a 2 hour interview unless I'm getting paid.
bpapa
I would prefer to write code for 2 hours alone than be forced to try to look smart and think at the same time. It takes a good deal of practice to think quickly with someone who is evaluating you present, since you tend to censor your thoughts/statements to avoid saying anything stupid.
nosatalian
+3  A: 

I describe the (incomplete) requirements to a simple app - usually a little more complex than the currency converter - and ask candidates to sketch out the design (not so much the UI, but the classes and interactions) on a whiteboard. As they're going, I clarify one requirement, change my mind over another and add yet another. I'm firmly of the opinion that learning any API or language is easy, compared with reasoning about a problem, proposing a solution and justifying the decisions which led to that solution.

Graham Lee
+1  A: 

Without any knowledge of iPhone development it is going to be difficult to evaluate this skillset. I would avoid trivia questions on Cocoa Touch. Ask them about their iPhone experience and try to get a sense of their abilities and then test what what you can actually evaluate:

Give them problems to solve in C (e.g. remove a node from a linked list, find the most frequently occuring character in a string). This should give you a good sense of their problem solving abilities and progrmaming ability.

I would also go through a standard app like Maps, and ask how they think some of the features were done. Have them draw designs on a whiteboard. Then ask them what other ways there are to do it. Have them come up with the advantages and disadvantages of each.

+3  A: 

Questions are all good, but how about asking them for examples of code they've shipped? It's so easy to get an application in the App Store, why not ask for apps they've actually released (or at least helped on)?

Martin Gordon
+2  A: 

To be honest, I found the best way to test someone for their skills is to look at previous experience. Definitely ask them if they've have any released apps on the app store. I don't think you can have questions that will completely test a developer's ability to build an app.

+3  A: 

There are many good Java developers who are moving from Java to the iPhone.

I'm not sure asking people to write traditional C code is a good way of testing if they are a good iPhone developer. I have never done C professionally, only Java (mainly server side stuff). I found the transition to iPhone was not much to do with remembering what I learned about C at Uni but more about:

  1. Learning about UI design and mocking up a interface
  2. Learning the cocoa libraries
  3. Memory management
  4. Learn the dev tools

I was able to bring aspects of good OO design and other development practises from my Java experience.

From my outside perspective (having only written 4 major applications) Objective-C does a great job of hiding some of the dirty details of the C language. That's not to say one should not have an appreciation of them. But it's not the be all and end all. I actually found Objective-C to be rather beautiful compared to what I remember of C. (I know that it's a superset, before you all jump on me)

Of course if I were developing iPhone games then I would expect a good solid knowledge of low level C stuff.

So if I went to an interview to be an iPhone developer and I was asked to write quick sort in C i'd probably run for the door. Not because I can't do it, but because I don't really think it's relevant to being good iPhone developer.

lyonanderson