Mobile developer interview questions, that a non-mobile developer can ask [closed]
I need to interview some people for a mobile developer position (iphone) soon. The problem is that my strength is in Java web development.
What questions should i ask without sounding like an idiot? Also, what are valid answers to these questions?
WOW this answer is five years old. For 2015, I would just ask:
The answer for the OP here is something like "autolayout, autolayout, autolayout". In real estate, you have the catchphrase "location, location, location"; in iOS development it's "autolayout, autolayout, autolayout". As a real-life practical matter, say you're checking someone out for a freelance job. In practice, about the only thing you ask them to show is that they are expert with autolayout, and associated issues such as using constraints in code, etc.
Are you totally expert with PubNub, Firebase, Parse and similar systems ... baas "is iOS engineering" today. To learn iOS today, is, to learn to hook up to a baas; to freelance in iOS is to do baas jobs.
Ideally, do you have some familiarity with Android development as well, do you at least have Android Studio on your Mac and you can build a trivial app to your Samsung; so you can interact with colleagues.
Here's the old answer!...
If it was me, I would ask them...
are they completely familiar with these TEN KEY POINTS:
- XCode (and ideally it's debugging tools)
- Interface Builder
- submitting apps to the app store, everything that involves (certs, blah blah)
- in objective-C, using properties inside out
- in objective-C, using delegates inside out
- networking with ASIHttpRequest {this answer really was five years old!}, AsyncSockets, GameKit, Bonjour
- total understanding of subclassing
- basics like CoreAnimation and CoreData
- "all the usual interfaces" on iOS like UITableView, etc etc
- everything, from top to bottom, about memory management
I think that's a good starter list. (If I've forgotten anything obvious, it will soon be suggested.)
Note that item 10, memory management, is the critical item. You just can't build finished working production mobile device apps unless you are a memory expert on your platform. Furthermore someone who's really good at iPhone memory management is usually good at everything else on the iPhone. If I could only ask one thing that's it!
There are also a dozen little things you have to have down pat to develop for iPhone - for example "preferences," "accelerometer," "icons and splash screens," "playing sounds," and so on and on. You have to be able to do all those in five minutes, not five days of investigation. It's pretty tough really. Someone could probably list all these "minor must-haves".
A perhaps separate somewhat specialist issue is OpenGL. Depending on what you're payin' them and what you need, you may demand someone who is, furthermore, an OpenGL expert.
Is your company's field games development? If so, it is perfectly likely that, furthermore, as a "total" iPhone games developer, you may need someone who is, also, already completely expert with
- Unity3D (for 3D etc)
- the popular physics (2D) packages (eg chipmunk, etc)
- one way or another, the server side of client-server systems
So that's that. A question is - what SPECIFICALLY are you going to be doing (in general terms)? ie, scientific computing, game development, marketing apps to get rich, in-house catalogs, hand-held clients, or?? If you tell us we can tell you what they need.
And finally overwhelmingly -- you would have to be able to see 3+ actual apps that they have done. With the iPhone, you really need to be able to "bring it home", writing good code snippets is not enough, you know. It's tough.
Here's the "stuff we forgot in the ten critical points" list beginning already!
Matt points out, they should be comfortable with "MVC" which stands for model-view-controller thinking. (This is kind of a fascist cult within the iOS world - we all adhere! We can't tell you about it until you are one of us. If their face lights up when you mention MVC, you're all set. If they get dark and uncomfortable looking, move on...)
David and Brad point out that - perhaps unlike other programming fields - iPhone and Mac programmers usually need a sense of the interface. You need a feel for that clean iPhone interface, you have to know how to layout any particular problem on the iPhone using the iOS elements that add up to the iPhone user experience.
Limit yourself to evaluate the traits that you can legitimately, well, evaluate. Ask another, knowledgeable individual to judge what you cannot.
Also, you can ask the candidate to explain you about iPhone development, explain that you are not familiar with it, and judge the response: candidate is arrogant about it? Candidate gets excited about it? Candidate can clearly explain train of thought? Candidate "makes sense"? All this are traits that you can legitimately judge and they do matter for any position.
Again, don't try to evaluate what you yourself don't know.
Stick them in front of a machine running Xcode. Then, have them write a basic application and run it.
Things to possibly put in said app:
- loading an image from a website while keeping the UI responsive
- editing a table view; being able to remove a row with animation and reordering it
Or, go with something basic like:
- a simple text editor
- a calculator
Once the app is running, try things like rotating the device. See how the person reacts. Do they realize how to fix any errors? How quickly? Where do they look for solutions if they don't know off the top-of-their-head? Do they use the documentation, or simply copy/paste code from somewhere?
Don't try to have the person create a full-blown app. In other words, make sure you stick with something basic. Otherwise, it'll be completely counter-productive. It's a little bit of pressure, but nothing a developer with experience can't handle.
I'd have thought that asking to see some sample code (ideally well in advance of the interview) would still be a worthwhile exercise, especially if you ask the interviewee for a self-contained example.
Whilst you won't be familiar with the nuances of Objective-C, you can still assess the degree to which the interviewee comments their code and the non-Cocoa/UIKit parts of the code won't be that different from Java or indeed any other OO language.
Beyond that, as @Arrieta implies it's probably best to avoid language specifics and focus on their general approach to problem solving, etc.
Don't ask them questions about areas where you don't understand the answers well enough to dig in. That's asking for trouble (a rote memory reciter and/or a glib snow job).
Find common ground, even if you have to go back to basics of programming or application design/test/debug/QA methodology, etc. Dig into their answers in an area you understand well. Only then will you know whether they are feeding you gibberish or not.
An iOS developer should already have an app in the store. Take a look at it before the interview, and question them on any portions where you might understand the goal or underlying tech (networking, graphics, etc.)
Then you could ask the candidate to explain the key differences between your common ground and their specialty which you don't know (mobile, etc.). Why does Objective C, UIKit, Xcode (etc.) do things differently than XYZ common ground coding? See if they can explain it clearly in a way so that you understand it (you can Google the answers later to see if they led you in the right direction).
They should have already worked on an app or two (even if just for themselves), have them explain the structure of it. You should be able to intelligently comment on arrangement of classes, and hopefully they would know some UML to be able to describe class layout or call paths.
加载中,请稍侯......
精彩评论