
Why We Hire Great Developers, Not Great Mobile Developers - astigsen
https://medium.com/runkeeper-everyone-every-run/why-we-hire-great-developers-not-great-mobile-developers-98acf14112d5#.5zn08imsu
======
lordnacho
Makes total sense. Once you've figured out how coding works, you can do any
stack, any framework, any language.

It bothers me how job ads tend to focus on various buzzwords. I'm quite sure
you're better off hiring someone with good fundamentals who can learn your
stack, rather than someone who is a novice but has some experience in the
stack.

I started off doing financial trading code in c++ / c#. It wasn't a huge leap
doing Android and iOS. Principles are the same:

\- Some kind of OO. They are all pretty similar for most purposes. C++ is
maybe a bit more intricate. Similarly, some kind of functional/lambda.

\- Some way to access a database. Plenty of ORMs or ways to do SQL if you need
that.

\- Some GUI organisational principles. WinForms, WPF, Qt, Android, iOS,
whatever. They tend to have things like "only draw on the main thread" and a
pile of APIs for organising the screens, buttons, and so forth. But if you've
done one, you're not going to need a course to do another.

\- StackOverflow will tell you everything that's pure translation. Things like
{} dicts for python.

\- Get a brief tutorial for each new language/framework. They're all over the
web, and the main point it just to highlight the features.

~~~
chrisseaton
If you're hiring someone to do something like implement a new machine learning
algorithm or a new compiler optimisation they're not to just pick that stuff
up off of stack overflow are they? Sometimes you need specialist knowledge.

~~~
workitout
If it's a new concept then the entropy is huge for anyone regardless of
background.

~~~
AznHisoka
That's not correct. Who do you think would be able to implement a spam machine
learning algorithm in a month? A NLP PhD or a regular Android developer?

~~~
tbrownaw
Given a whole month? Anyone who can use google and isn't afraid to experiment
with the available libraries they find.

~~~
chrisseaton
Would you trust your security to a TLS implementation done by someone who'd
spent a month googling on it?

~~~
lordnacho
What if they spent the month finding out how some open source implementation
worked, including what experts thought of it, and wired it up for your needs?

~~~
chrisseaton
You know, at the bottom of your stack someone, somewhere, needs to know a
subject well enough to implement things from scratch. If what you are doing
hasn't been done before you can't just google or find an open source library.
Even if it has been done before often these things are often barely written
down.

Do you think when Google decided to create the V8 JavaScript JIT they hired a
couple of Django programmers and asked them to google 'how to write a JIT'? Or
do you think they specified a certain level of experience in writing JITs on
the job advert?

~~~
lordnacho
> You know, at the bottom of your stack someone, somewhere, needs to know a
> subject well enough to implement things from scratch. If what you are doing
> hasn't been done before you can't just google or find an open source
> library.

That really depends on what "from scratch" means. Any particular piece of code
can be examined in enough detail that nobody in the whole world would
understand all of them. Luckily people who understand specific pieces will
produce a part for others to use. Often the only thing that hasn't been done
before is one particular mashup of existing parts. Then the skill of coding is
like the skill of cooking: using judgement to assemble well known parts into a
new whole.

> Do you think when Google decided to create the V8 JavaScript JIT they hired
> a couple of Django programmers and asked them to google 'how to write a
> JIT'? Or do you think they specified a certain level of experience in
> writing JITs on the job advert?

That wasn't the point. I'm not saying that any programmer can do any
programming job. But that the selection criterion (language, framework) is in
general wrong. If you have a guy who did a JIT for Java, do you disqualify
that guy from a JIT for Go job? I don't think so.

------
Mapiarz
What I have noticed in the first paragraph: "It seems that some schools have
caught on and are teaching students the ins and outs of being a mobile
developer but for the most part graduates seem to only have a course or two of
mobile dev under their belt."

Am I the only one who finds that weird? During my 5 years of college education
in "informatics" I never had a 'programming for..." course. We were taught how
to tackle problems, algorithmics, patterns and practices, formal languages,
ai, distributed mechanisms and so on. We had to get that hard concrete
experience on our own. IMHO having courses like "programming for Android" or
"Web/JS programming" is a great way to mass produce monkey programmers.

~~~
alistairSH
Totally agree with the "mass-produced monkey programmer" comment. I've seen it
in practice, when interviewing new graduates.

The grads from good (not necessarily great) schools tend to have solid
fundamentals, and even without lots of "buzzword" coursework, they come out
better. The grads from mediocre schools often have more buzzwords on their
resume, but often lack solid fundamentals.

Of course, that isn't written in stone. We have several great new hires from
schools that are typical regional universities.

~~~
mattmanser
The graduates from schools with higher entrance requirements have better
graduates than the schools with lower ones?

And you think it's their course material...

~~~
alistairSH
Yes. Based on what I've seen, there is absolutely a curriculum problem at some
schools. None of these were terrible schools, just not R1 universities.

------
smt88
When I saw this, I thought it was going in a different direction. I personally
despise mobile development because so little of it is elegant writing of code.
A lot of it has to do with learning the bizarre ins and outs of thoroughly
fragmented targets, as well as documentation that's sometimes very lacking. I
had assumed any developer who really loves coding (rather than debugging or
trial-and-error) would avoid mobile development, leaving the talent pool very
lacking.

~~~
dozzie
Also, most of mobile development seems to be writing another UI for sensors or
SQLite database, or sometimes another game like the plenty out there. Why
would anybody think of that as exciting?

~~~
V-2
Like your typical web app isn't yet another CRUD or CMS ;)

~~~
alkonaut
> Like your typical web app isn't yet another CRUD or CMS ;)

Indeed. To avoid the CRUD groundhog day, I'd stay away from both web and
mobile.

~~~
V-2
What do you do then?

~~~
alkonaut
There are tons and tons of areas in software that aren't web (or mobile, which
is usually just web with another toolkit).

Games, Desktop apps, Industrial, embedded, ...

Personally I do desktop applications and love it.

~~~
V-2
Yeah I did desktop apps for a while (in .NET), but they can be just as
repetitive and non-inventive. In my case they were mostly shelf-stacking /
syncing apps for internet shops.

I simply don't believe that a domain (understood broadly, ie.
desktop/mobile/web) in and of itself dictates whether projects are original
and interesting.

Not until you work on something really specialized, like AI etc.

~~~
alkonaut
Yeah, so long as a desktop app _could_ have been a browser app, it tends to
have the same problems as a browser app (i.e it's just CRUD).

They are usually only interesting if they are desktop apps because they have
to, like image editors, games, CAD.

My test for interesting work is the fraction of lines of code that relates to
processing data and not just input/presentation/persistence/validation.

------
pjmlp
Nice article.

As someone that occasional does some hobby Android and WP coding, when time
allows, it is quite interesting to see this type of attitude.

Here in Germany many IT companies seem to disregard skills if they aren't
listed as part of the previous job. Regards of what one would be able to show
at the interview, if HR didn't filter out the CV.

So no chance of switching tech stacks unless one is able to land in a
greenfield project that is taking off, inside the same company, before doing
the jump.

~~~
V-2
That's not just Germany, it's typical. It reminds me of
[http://programmers.stackexchange.com/a/1847](http://programmers.stackexchange.com/a/1847)
:)

~~~
lohengramm
That's perfect. Definitely not a Germany thing.

~~~
alkonaut
Wow, so there are situations where a bad programmer with the right CV keywords
would be chosen over a good programmer with the wrong keywords on the CV? I
thought we were past that now.

~~~
userulluipeste
Worse than that is when a developer has side projects that may show real
expertise that was not required nor used in the previous jobs. Considering
only the skills endorsed by previous jobs when doing a hire is a sure way of
handicapping your company!

~~~
pjmlp
That is what prompted my comment.

Once an HR drone has explicitly told me that my side projects had zero value
for the application, even though they matched what was being searched for.

------
coldcode
As long as someone understands the platform you can do this. I've seen way too
much iOS code written by smart people new to iOS with no clue how to structure
and ship a successful mobile app. This is likely true for most platforms. A
smart developer can learn in time but usually you don't get that time so it's
better if at least someone has done whatever it is before. I am sure I could
master Android in time but if I started building an app on day 1 it would
likely be terrible.

~~~
alistairSH
The article addresses this. They have experienced developers on-hand to assist
and ensure standards are maintained. Getting the time to learn is a management
problem, not a developer problem.

I've taught C# and the .Net framework to several teams over the last two
years. The good developers pick it up without much problem. But, we usually
start with several sprints of co-located group programming (for complete teams
learning the stack).

~~~
pconno3
Agreed, it's important to that the entire teams understands when someone is
learning a new skill set or language. We try to allocate more time in our
sprint for not only the developer who is learning but also for another
developer on the team to help ramp them up.

It takes a bit of working with the PM to determine what is a good task that
isn't super time sensitive but it's typically a solvable problem.

------
EvanPlaice
How can I find a place like this to work.

It seems like everybody sharing their interview experiences says they all use
the same Google-wannabe standard. Ie whiteboarding, implementing an advanced
data structure from memory, and rapidly solving CompSci homework questions.

I'm no CompSci grad but I have pretty a pretty experience in many
languages/stacks. I have confidence that I could design and implement a
reasonably complex distributed architecture if requirements called for one.
Yet I'd look like a complete asshole if asked to whiteboard a R/B tree from
memory.

~~~
gedrap
Fair enough. In my experience, "no one was ever fired for buying ibm" kind of
thing is very strong in the interviewing.

Why are you asking these meaningless questions, that don't give a chance to
demonstrate any relevant knowledge?

Everyone does that, duh.

~~~
EvanPlaice
It's kind of sad that a person's worth can be reduced to such a useless
metric.

HR has no ability to objectively judge technical talent, so they follow the
latest 'flavor of the month' interviewing strategy.

The suits are heavily influenced by sources like Business Insider that
repeatedly parrot advice about avoiding 'false positives at all cost.'

Meanwhile the tech specialists who should step in and call BS, won't because
they're to arrogant to admit their own hindsight bias. Ala judging new
candidates based on their current level of ability and specialized knowledge
rather than the level they were at when they were initially hired.

It seems like the industry is dead set on forcing the perception that software
development is hard science -- as in -- everything can and should be described
in terms of fundamental data structures and algorithms. When the reality is,
software development is 95% art and about 5% hard science.

The vast majority of clever algorithms and data structures can be implemented
in less than 100 lines of code each. What accounts for the other millions of
lines of code in a system such as the Linux kernel?

The world will never know...

------
seivan
Mobile Devs might be better versed in the UI layer as they would be more
familiar. Could end up not having to need a "photoshop-designer".

We've used good developers on iOS projects, and while they would do ok with
actual logic, they didn't do well when it came to Core Data or UIKit. It's not
an education problem, but an interest issues. Most of them used Androids, the
ones with iOS devices really didn't care much about UI.

But I kinda agree with this in other aspects.

~~~
pconno3
That's a valid point. Although, we hire developers who are interested in
becoming mobile developers. If you want to succeed as an iOS developer, Core
Data and UIKit are essential to learn. If the person isn't interested in doing
the front end then mobile dev probably isn't for them. That should come up in
the interview process.

------
jmbrook
Small nit pick, but I would be worried about a mobile development place that
thinks it has only been around 8 years, not heard of J2ME, Symbian and Windows
CE etc?

I do agree with the idea of hiring decent engineers and just training them, my
only concern would be that without having had the mobile experience they might
not know that they don't like it - it can be quite painful getting code to
work nicely on a large collection of different hardware.

~~~
potatolicious
That is a pretty small nitpick you've got there ;)

It's a bit like saying "don't they know human flight existed before the Wright
Bros." or "don't they know cars predate the Model T?"

Of course, but the iPhone (and subsequently Android) presented a gigantic
turning point in mobile development, to such a degree that mobile development
can largely be categorized into "pre-iPhone" and "post-iPhone".

Pre-iPhone mobile development was a vanishing small industry compared to today
and used technologies that are largely completely not around today (see: J2ME,
Symbian, Windows CE).

So yeah, maybe they could've said "mobile development in the modern context
centered around multitouch-centric interfaces using soft keyboards has only
been around 8 years", but that's kind of a mouthful, and unless we're trying
to write an accurate history of mobile software, not particularly relevant to
anything.

~~~
jmbrook
I would agree with the pre/post iPhone shift - but the likes of EA/Glu and
other major games companies shifted an awful lot of apps pre iPhone.

The big shift is that touch became the only game in town (along with all the
associated dev wrinkles). Also the demise of all content aggregators meant we
could just upload our apps to a store and keep 70% (prior to this we got ~20%
i.e. operator took 60-70%, aggregator took 30% and we got 50/50 on that).

------
sridharpoduri
I think this is mostly true for all successful companies, not just startups.
You are looking to hire for the company and not for a particular position.
Hire for talent and let them grow with the product/domain/technology.

~~~
pconno3
I strong agree with this. It's important to hire people who are excited about
the company and the environment. This will inspire them to learn/grow.

------
scottishfiction
Totally agree with the approach. Relevant -
[http://www.joelonsoftware.com/articles/GuerrillaInterviewing...](http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html)
Although perhaps 'Smart and Gets Things Done' is an over-simplification.

~~~
simi_
You might like this [http://steve-yegge.blogspot.de/2008/06/done-and-gets-
things-...](http://steve-yegge.blogspot.de/2008/06/done-and-gets-things-
smart.html)

------
JamesBaxter
What I can't seem to teach my project manager is that the App Store review
process takes as long as it takes and other app store restrictions.

------
rumcajz
On the other hand, programmers jumping from one industry to another build no
domain knowledge. The result is that domain experts, such as accountants or
telecom technicians, specify the requirements, which then get translated 1:1
to software design, no diligence applied. The result is shitty software.

