Myths Of Building A Great Mobile Team
techcrunch.com
techcrunch.com
While I agree with the fact that an organization should be generalist heavy. There are some areas that I think there is no substitute for specialist, security and HCI are two areas that we rely on specialist to helm the direction, there is so much domain knowledge in both that it is money well spent to carry specialist in these areas. It looks like the author implied this by using the word culture, but I felt that it is probably worth expanding on so that the avoidance would not be taken to the extreem by a reader.
But would you want to hire a mobile HCI specialist? Or someone who is great at consumer HCI and will apply that understand to mobile within mobile design constraints?
My personal bias would be to hire the consumer HCI specialist and have them work on / learn mobile.
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.
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.
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.
What he means, is don't hire mobile engineers that have worked at big telco provider (samsung,motorola, or carriers). It is well known that these companies just don't have good talent. I'd rather work with a good generalist, than a crappy mobile developer. But, a good mobile developer will run circles around a generalist.
"b. Don’t hire “mobile” Product Managers (PMs)" Again, same thing. He equals 'mobile pm' to somebody that has worked in crappy telco related companies.
That's not true. There have been plenty of mobile companies that are not telco related. Even before iPhone came to change the landscape, there were plenty of companies that were both mobile and consumer focused.
..
"For example, on the early Google mobile team we had a PhD student from Yale with no industry experience, an expert on enterprise Java from BEA, and a research scientist at Google. These people helped form a formidable core for mobile engineering at Google."
Ah, this explains why the Android api seems like something that came from the desktop. It has everything thrown into it, even the kitchen sink. Comparing to the iPhone sdk, it is clumsy. Also, this probably explains a lot of the usability problems Android has in general.
The sad fact is that developing for the android is twice as expensive, and produces less good looking application than the iPhone.
Perhaps this guy should have hired mobile engineers?
I have developed both on iphoen and android:
1. Dalvik VM manages a lot of stuff that have do by hand on iphone resulting in iphone always costing 1.5 times as much as android.
2. I can point out the crappy iphone apis if you like such as that notification api that freezes iphone devices more than once even for the average user on a daily basis.
If your main reason for not hiring someone is "They worked for Nokia," then I'm not quite sure what to say, besides that it doesn't seem to be a very good reason not to hire someone.
Of course, I've never worked for any of the aforementioned companies. That being said, I know some very smart people who have (and continue to do so). People who I'd be happy to work with, if the chance ever came up at the right time.