A large media company rejected a friend of mine who only had less than one year iOS experience (but had already collaborated on a couple successful apps). Their rejection reason was they were looking for engineers with 2+ yrs of iOS experience. Some of my friends meet their baseline requirements and they are not hirable (busy with client projects). What this company's HR department fails to understand is it easier to hire someone who has a solid non-mobile background and has been doing it for fun, on-the-side than to hire a mythical 2-yr iOS experience developer. I've gotten all of my contracts because of two big things: my personal connections and my portfolio of iOS apps. What pointy-haired bosses seem to fail to understand is the portfolio is the benchmark for performance and experience. Btw - I have exactly one year of iOS experience and have worked on four apps.
Requiring 2 years of iOS experience is hilarious considering the platform has barely been around for 2 years.
However, the iOS SDK is large enough that I'd be skeptical of candidates without a reasonable amount of experience. There are a lot of areas to learn and a lot of gotchas that will only be understood after building (and maintaining) a real world app. For example, with Core Data, the rabbit hole gets really deep really quickly.
I wholly agree that the best measure of an iOS developer is the apps they've actually shipped.
Yes, CoreData is a focus of experience in itself. CoreData apparently was based off of what was in WebObjects?
It looks like the iPhone SDK was officially released on March 6, 2008. I think I could be a brutal interviewer with my one year. For example, tell me how you would design a CoreData-based app with a table showing how far you were from a list of addresses (that you had lat/long for). There are a lot of gotchas (background thread, if you wanted distance-based section headers...) that could only be learned by hands-on coding. There is only so much you can learn from a book or lecture - at some point you are going to need to dive in - so you yourself could give a talk on what was left out...
I think even "simple" stuff like how to implement a loading view could quickly ferret out the doers from the pretenders. And the next level would be asking how they would create custom UITableViewCells. And so on... But the important thing, is there are some pretenders who want to become doers - those are the ppl I think you want - and the ones that big companies can't identify. The programmers who love problem solving, who love figuring things out.
Comments
> Don't hire "mobile engineers"
A large media company rejected a friend of mine who only had less than one year iOS experience (but had already collaborated on a couple successful apps). Their rejection reason was they were looking for engineers with 2+ yrs of iOS experience. Some of my friends meet their baseline requirements and they are not hirable (busy with client projects). What this company's HR department fails to understand is it easier to hire someone who has a solid non-mobile background and has been doing it for fun, on-the-side than to hire a mythical 2-yr iOS experience developer. I've gotten all of my contracts because of two big things: my personal connections and my portfolio of iOS apps. What pointy-haired bosses seem to fail to understand is the portfolio is the benchmark for performance and experience. Btw - I have exactly one year of iOS experience and have worked on four apps.
Requiring 2 years of iOS experience is hilarious considering the platform has barely been around for 2 years.
However, the iOS SDK is large enough that I'd be skeptical of candidates without a reasonable amount of experience. There are a lot of areas to learn and a lot of gotchas that will only be understood after building (and maintaining) a real world app. For example, with Core Data, the rabbit hole gets really deep really quickly.
I wholly agree that the best measure of an iOS developer is the apps they've actually shipped.
Yes, CoreData is a focus of experience in itself. CoreData apparently was based off of what was in WebObjects?
It looks like the iPhone SDK was officially released on March 6, 2008. I think I could be a brutal interviewer with my one year. For example, tell me how you would design a CoreData-based app with a table showing how far you were from a list of addresses (that you had lat/long for). There are a lot of gotchas (background thread, if you wanted distance-based section headers...) that could only be learned by hands-on coding. There is only so much you can learn from a book or lecture - at some point you are going to need to dive in - so you yourself could give a talk on what was left out...
I think even "simple" stuff like how to implement a loading view could quickly ferret out the doers from the pretenders. And the next level would be asking how they would create custom UITableViewCells. And so on... But the important thing, is there are some pretenders who want to become doers - those are the ppl I think you want - and the ones that big companies can't identify. The programmers who love problem solving, who love figuring things out.