Saw a similar link a few weeks back on a list of questions for front-end website designers. I thought it was a really great lists for people looking to hire a programmer/designer here in the new year, so wanted to make something similar for iOS, as we may be hiring and it would be useful to have this on hand.
This is an early work in progress, but suggestions/PRs would be much appreciated!
Was hoping to work on this next week, as we do a bunch of Android work as well and it would be useful for us! I'll link in this repo when I get that up.
If you're in a situation where the best way you have to assess a candidate is to ask them questions, I'd recommend focusing on types of questions that open up room for discussion about how the candidate thinks and works rather than simply asking trivia questions about Apple's frameworks.
In context of iOS/Obj-C/Cocoa, ask about MVC. Ask about delegates versus blocks versus notifications as mechanisms of communicating between objects. Ask about CocoaPods, but framed as a larger question of when and how to bring in and manage third-party dependencies versus building them yourself. Give them the opportunity to share how they think, not just what they know.
That question really needs to be flipped (this is true of any "what's your favorite feature of [x]?" style question). It's far better to ask "what would you change about Xcode / developing for iOS[1]", because anyone can recite features of a product - it's another thing to be asked to critically think about what you would actually change to make your life as a developer easier.
[1] NB: "Crash less" doesn't count as an answer for Xcode, correct as it may be...
How does any of this prove they are a good candidate? All this proves is they can remember things. When coding all if not 99% of these questions are a 4 second Google away.
And most of them are also opinions which tend to lead to bias. "Oh this user doesn't like Xcode, while I only use Xcode, so nope to him".
This was my first thought, too. "What is widget X" isn't a good question. Questions more along the lines of "When would you use widget X over widget Y" will lead to better insight about a candidate, and will show actual experience.
In the same way, for normal CS questions, "Write a hash-table implementation" is OK but I think it's better go with a question where a good solution involves using a hash-table.
Absolutely a lot of these questions were general knowledge to any techsavvy guy. I strongly recommend this book called [Cracking the coding interview] by Gayle Laakmann. It's very details and in-depth, helped me prepare for all my interviews.
Understandable that these are mostly just trivia questions, my thought was that they should be a springboard (pun intended) for senior developers/managers prepping for a hiring interview, who may be a bit unsure as to what to ask.
Any candidate who answered these in one sentence/work answers with little detail would definitely not be a strong candidate, IMO. But mostly a round up of "Here's some topics to maybe dive into and get to know an engineer better with."
Majority of these questions seem to be Trivia, which can be looked up. I don't see any need to learn them. They are probably nice to know but are not helpful in objectively evaluating a developers iOS skills.
The important thing while talking to candidates is evaluating their understanding of technical concepts - like multithreading, GCD vs NSOperations, application lifecycle, properties, references, blocks, memory management, caches, sandboxing, responder chain.
Whats the point of someone knowing HealthKit or Voiceover or screen resolutions if they don't understand how atomic or nonatomic properties differ?
Understandable, I'm mostly a designer and so the first run I had a few questions like this sounded a little rough. Have a friend contributing and helping with these a bit, but still very early on this.
If you have any suggested questions, I would love to add them. If you don't wanna go through the PR, etc, my email is in my profile. Feel free to send over and I will add.
I think part of the idea of interview questions like these is that it will get a developer into those finer points, if they are in a technical discussion.
I would add questions where answers can't be found easily by searching or on stack overflow. If the answer is found in the first search result, then I don't see the point in checking if the interviewee has memorized it.
Add questions that should lead to discussions and show general knowledge.
I would add a section for small, interesting coding challenges.
This list reads like a multiple-choice test at a community college for a "Survey of iOS Technologies" course. Casual iPhone aficionados who read 9to5Mac would dazzle an interviewer if they were merely asked these trivia-type questions.
I'm afraid this isn't going to produce much beyond anxiety in your candidates. This leads to the sort of interaction where I'd end the interview early, thank the interviewer for their time, and high-tail it out of there never to return.
It's a trivia quiz. And frankly, who cares if you know what iBeacons are? What's the likelihood a project requires knowledge of both iBeacons and HealthKit?
HealthKit AND HomeKit?
HomeKit AND Apple Pay?
Why ask about something as deeply specialized as Metal, a brand new 3D graphics API, when so few projects are likely even to need it—except in game dev shops?
And in what conceivable universe does someone need to know the screen resolutions of any given piece of hardware? I've been building iOS apps for six years now, and I barely remember at any given moment.
Anyone looking for great interview questions for iOS devs should instead consult Black Pixel's excellent post here:
CameronBanga, appreciate you sharing this! As a long-time iOS designer and developer, I appreciate you helping and effort in finding a great one.
I unfortunately think that all of your questions are at best, filtering questions to ensure they have base familiarity with pretty benign facts and at worse, questions that give no insight at all into iOS abilities. Your design questions are, in particular, extremely trivial and almost silly.
Feel free to reach-out to me if you'd like to collab on a better list.
Everyone else reading this, no even semi-serious iOS developer or designer would endorse these questions as a robust way to filter candidates or even teach yourself.
Posted a link here, https://news.ycombinator.com/item?id=8828209, explaining. This was a quick starting point for a friend and I, hoped a post here would encourage a person or two to help out, and seeing a huge unexpected response.
I am more than happy to accept any suggestions, I understand most are super trivial, I assume these as a starting point for any conversation, or as basically a few things that could help give someone an idea as to where to start.
PRs are appreciated, or feel free to just email me questions and I will add (email in profile). Create an issue and add there as well, and I will go ahead and work in. Whatever is easiest!
Thanks for all of the attention everyone. I know it's basic, but it's a start. Hopefully we can work to evolve it into a much more detailed document that a few of you can benefit from.
First of all, thank you for taking the time putting this together.
Next, this should be used as a good example of "types of questions not to ask in a technical interview".
These will give little insight into what a candidate actually knows other than random trivia. I've seen a lot of junior interviewers focus on these types of questions, to perilous results.
I actually think high level questions like these are just conversation starters which can get into highly technical conversations quickly.
Sort of like the technologies themselves; GameCenter and CoreEverything are abstractions of lower level functionality.
Being able to discuss their purpose, how to use them, and how to glue them together is what a good developer is. The rest is just syntax.
Moreover, I never see these questions as just being a one-by-one trivia list for applicants. More of just a thing to look over, see the technologies that your app may use, and then use these questions as kinda a way to launch discussion with an applicant to see how well the know their stuff.
32 comments
[ 4.0 ms ] story [ 53.7 ms ] threadSaw a similar link a few weeks back on a list of questions for front-end website designers. I thought it was a really great lists for people looking to hire a programmer/designer here in the new year, so wanted to make something similar for iOS, as we may be hiring and it would be useful to have this on hand.
This is an early work in progress, but suggestions/PRs would be much appreciated!
In context of iOS/Obj-C/Cocoa, ask about MVC. Ask about delegates versus blocks versus notifications as mechanisms of communicating between objects. Ask about CocoaPods, but framed as a larger question of when and how to bring in and manage third-party dependencies versus building them yourself. Give them the opportunity to share how they think, not just what they know.
Bonus points if they laugh bitterly.
[1] NB: "Crash less" doesn't count as an answer for Xcode, correct as it may be...
And most of them are also opinions which tend to lead to bias. "Oh this user doesn't like Xcode, while I only use Xcode, so nope to him".
In the same way, for normal CS questions, "Write a hash-table implementation" is OK but I think it's better go with a question where a good solution involves using a hash-table.
Any candidate who answered these in one sentence/work answers with little detail would definitely not be a strong candidate, IMO. But mostly a round up of "Here's some topics to maybe dive into and get to know an engineer better with."
The important thing while talking to candidates is evaluating their understanding of technical concepts - like multithreading, GCD vs NSOperations, application lifecycle, properties, references, blocks, memory management, caches, sandboxing, responder chain.
Whats the point of someone knowing HealthKit or Voiceover or screen resolutions if they don't understand how atomic or nonatomic properties differ?
If you have any suggested questions, I would love to add them. If you don't wanna go through the PR, etc, my email is in my profile. Feel free to send over and I will add.
Add questions that should lead to discussions and show general knowledge.
I would add a section for small, interesting coding challenges.
It's a trivia quiz. And frankly, who cares if you know what iBeacons are? What's the likelihood a project requires knowledge of both iBeacons and HealthKit?
HealthKit AND HomeKit?
HomeKit AND Apple Pay?
Why ask about something as deeply specialized as Metal, a brand new 3D graphics API, when so few projects are likely even to need it—except in game dev shops?
And in what conceivable universe does someone need to know the screen resolutions of any given piece of hardware? I've been building iOS apps for six years now, and I barely remember at any given moment.
Anyone looking for great interview questions for iOS devs should instead consult Black Pixel's excellent post here:
http://blackpixel.com/blog/2013/04/interview-questions-for-i...
It talks through concepts as much as technologies, hitting the most common cases for what a developer will actually use.
I unfortunately think that all of your questions are at best, filtering questions to ensure they have base familiarity with pretty benign facts and at worse, questions that give no insight at all into iOS abilities. Your design questions are, in particular, extremely trivial and almost silly.
Feel free to reach-out to me if you'd like to collab on a better list.
Everyone else reading this, no even semi-serious iOS developer or designer would endorse these questions as a robust way to filter candidates or even teach yourself.
I am more than happy to accept any suggestions, I understand most are super trivial, I assume these as a starting point for any conversation, or as basically a few things that could help give someone an idea as to where to start.
PRs are appreciated, or feel free to just email me questions and I will add (email in profile). Create an issue and add there as well, and I will go ahead and work in. Whatever is easiest!
Thanks for all of the attention everyone. I know it's basic, but it's a start. Hopefully we can work to evolve it into a much more detailed document that a few of you can benefit from.
Next, this should be used as a good example of "types of questions not to ask in a technical interview".
These will give little insight into what a candidate actually knows other than random trivia. I've seen a lot of junior interviewers focus on these types of questions, to perilous results.
Sort of like the technologies themselves; GameCenter and CoreEverything are abstractions of lower level functionality. Being able to discuss their purpose, how to use them, and how to glue them together is what a good developer is. The rest is just syntax.