Quiz for iPhone Developer job Interview

Appstudio is always looking for talented programmers to join our team. Interviewing prospective employees is a difficult task for any job, but it takes special skill to separate the programming guru from the script-kiddies. Often we are looking at young people without college degrees. They are smart, talented and motivated, but without a degree it can be a bit more work to see if they really know anything.

One problem we've had interviewing is that sometimes a programmer is not "classically" trained, and doesn't know the proper jargon. This can be a bigger problem if their native language is not English. I try to focus on questions that don't rely on knowing the names, or jargon, but just the knowledge of the concept itself.

When job candidates claim to have iOS experience, I am often skeptical that all they really did is installed xcode a few months ago, ran it a few times, and may have followed a simple tutorial. This will appear on their resume as "6 months iOS experience".

Here's a free tip to anyone who is going to a job interview: if you don't have experience in a field don't claim that you do. We have turned down a few people because they claim expertise that they didn't have. Had they been honest we would have been much more inclined to hire.

I have developed a list of questions to ask job candidates that often separate out those who have real iOS experience from those who don't. I have a list of around 30 questions that start off easy and get harder as we go along. This way we can get a pretty good idea as to a person's knowledge of iphone programming.

Here is a small section of the test, which I only give to people who claim to have more than six months iOS experience. I don't expect them to get them all, but when they don't get any, or worse - they answer some nonsense instead of saying "I don't know", I start to think that their "six months experiences" means they installed xcode six months ago and never opened it.

In the two code snippets below neither is correct or incorrect, but will act differently in some cases. Name any case where the code will act differently.

Question 1

[[UIDevice currentDevice] orientation];

[[UIApplication sharedApplication] statusBarOrientation];

This is a pretty tough question to answer without documentation, but I still think that some iOS developers could answer it without looking. Just by looking at the words some programmers can understand that there is a difference between how the device is pointing and where the status bar is.

The key difference is that they return different types. [[UIDevice currentDevice] orientation] returns a UIDeviceOrientation (which includes FaceUp and FaceDown) and [[UIApplication sharedApplication] statusBarOrientation] returns a UIInterfaceOrientation. The most common case where they will be difference is when the device is oriented in a way that the UI does not support; for example if an app that supports portait is in landscape. In such a case, the device orientation will be landscape, but the status bar orientation will be portait.

Bonus points if you know that UIInterfaceOrientationLandscapeLeft = UIDeviceOrientationLandscapeRight because as you move the device to the left the UI moves to the right to compensate.

Question 2

myset is an NSSet

if ([myset containsObject:object]) {
        NSLog(@"%@", object);
}

if ([myset containsObject:object]) {
        NSLog(@"%@", [myset member:object]);
}

This question occurred to me when I was reading the NSSet documentation and wondered when you would ever need to use [myset member:object]. If you already have the object why would you need to get the object out of the set?! The answer is that object and [myset member:object] may not be identical (==), but only equal (isEqual:). You may, for example have a mutable object in the set, but search by inmutable object. Or you have a class "Student" with a unique id 12345 in the set, you could use [myset memeber:[Student studentWithId:12345]] to retrive the student object with all student information. (Of course you have to have overwritten the isEqual: method to compare Student's IDs).

Question 3

myView is a kind of UIView

myView.backgroundColor = [UIColor whiteColor];
myView.alpha=0.5;

myView.backgroundColor = [[UIColor whiteColor] colorWithAlphaComponent:0.5];

The most common reason for getting this wrong is that the programmer never dealt with any UI that had any alpha component; which is not so horrible. That is what I assume when the programmer says "I don't know". Sometimes the job interviewee answers something that shows he does not really understand what a UIView is, or what a property is.

If myView is simply placed on the screen the two boxes will look identical. But there is a big difference in how they will treat their subview. The first myView where alpha=0.5 will also apply the alpha to its subviews. The second myView with a transparent color background will not.

Question 4

if([object isKindOfClass:[NSString class]]){ ...

if ([object isMemberOfClass:[NSString class]]) { ...

This is probably the question that is most likely to separates out people who learned iOS from tutorials, or taught themselves from those who studied Objective C in some formal way. The difference is that kindOf also includes subclass, while memberOf is only for the class itself. In the code above an NSMutableString will return YES for the first code snippet, but NO for the second.

This is a question where dishonest job candidates do worse. If a person says "I have a little experience in iOS" and gets this wrong, I don't hold it against him. But if a person says "I have been programming iOS for over a year and I have never used isKindOfClass" I see that as a warning sign that he doesn't understand how object messaging works in iOS, and doesn't check object types before sending messages.

I encourage our programmers to use isMemeberOfClass whenever you are casting such as:

-(IBAction)toggleButton:(id)sender{
    if ([sender isKindOfClass:[UIButton class]]) {
        ((UIButton*) sender).selected=((UIButton*) sender).selected;
    }
}

Some people would claim that if you know that this will only be called by a UIControl you don't need it. These people are wrong, and I don't hire them.

Question 5

Assume that this is run in an object that has a 'setup' method.

[self setup];	

[self performSelector:@selector(setup) withObject:nil afterDelay:0];

This is one of the hardest question I ask and I don't think anyone has ever got it right. The best answer I ever got was "I have no idea, it seems like they should be running the same code".

The answer requires some subtle knowledge about how runloops work in iOS. [self setup] will run the setup code immediately in the same runloop, performSelector:withObject:afterDelay will always schedule it in a future runloop - even if you set a delay of 0.0. In other words the line below performSelector:withObject:afterDelay will run before the code in the method 'setup'