
Hire talent, not five years with Java - bleakcabal
http://gillesleblanc.wordpress.com/2013/03/25/hire-talent-not-five-years-with-java/
======
jowiar
Once upon a time (1969-ish), my father was hired as a programmer. He was an
electrical engineer by training, but had zero programming experience at the
time. Given a shortage of programmers, IBM placed an ad in the newspaper,
hired smart people, and taught them how to program. Assembly. On mainframes.

40+ years later, companies are in a similar situation, but instead, given a
shortage of engineers, they are simply whining about it. Presumably, with
tools that are 40+ years better that making it "easier" to program, such a
system of the past would be reasonably replicable today, no? I've seen a few
things pop up here and there - hungryacademy and such, but, by and large, this
is the exception far more than the rule. Once upon a time, companies would
hire and develop talent, investing years to develop the talent with years of
rewards on the end for both sides of the deal. Now? Companies expect hires to
come fully trained, ready to deliver from day one, at their own expense (and
much debt to the banks). Employees have no loyalty (and for good reason).

~~~
InclinedPlane
Part of it is the difference in programming culture. With startup culture,
which has many good aspects, also came the idea that the death march should be
the norm. Meaning, 20-somethings should be working 80 hour weeks on a regular
basis and projects should be shipped at the soonest possible moment it's even
remotely feasible to do so.

This sort of working environment has no slack, no capability to operate
effectively in apprenticeship mode, and little leeway to allow long ramp up
times. And as a result it has become more difficult to positively advance the
state of the industry or the average skill toolset of coders.

It's the classic problem, when you spend all your time in emergency mode
fighting fires you don't have the cycles to be able to make improvements to
systems or to other coders as well.

~~~
dexen
While I agree with your overall message, the

 _> (...) death march should be the norm. Meaning, 20-somethings should be
working 80 hour weeks on a regular basis and projects should be shipped at the
soonest possible moment it's even remotely feasible to do so._

has got me puzzled: in my (limited) experience and from what I've read, a
death march is exactly the opposite of shipping early. The usual story goes: a
deadline looms, or a milestone slips, a middle manager decides to whip up his
team instead of reporting it. Overworked team members can't meet another
deadline, the client and/or upper management is kept in the dark about the
problem, no extension of deadlines for sake of good metrics, rinse and repeat.

``It is done when it is done'' and shipping early is a panacea, not a cause of
the problem.

~~~
InclinedPlane
Death march is often the norm, and when more effort is needed the only option
is a super death march or just giving up.

And yes, it's not a good way to work. Nor is it even a fast way to work. It's
a an equilibrium point that is reached when certain initial conditions in
regard to the value that is placed on the appearance of work and dedication
are higher than craftsmanship et al is valued.

For people who are immersed in that world view it seems perfectly logical that
adding more hours worked will make everything better. But the paradox is that
it doesn't, it often makes things worse, for a whole laundry list of reasons.
People become physically and emotionally exhausted by the pace, there's no
room for higher level improvements which are often the only way to achieve
orders of magnitude gains in efficiency, productivity, and quality.

There are a handful of companies that do things right and at those companies
employees tend to stick around for not just a few years but decades and the
products they make tend to have an outsized impact on the industry (valve,
blizzard, 37signals, pixar, etc.) But it's still so hard to fight against the
conventional wisdom.

------
hkmurakami
Reminds me of one section of the Stripe article on hiring: "Hire People
instead of roles". I couldn't agree more with both authors (Stripe and OP).

 _"One thing that's worked well for Stripe is bringing on people who didn’t
have an immediately obvious role in the organization. If you can think of one
thing this person can do, then there’s probably ten more you're not thinking
of that he/she can do two months from now. Focusing on hiring to fill a role
could make you more likely to sacrifice quality just to get someone with the
right skill set."_

[http://firstround.com/article/How-Stripe-built-one-of-
Silico...](http://firstround.com/article/How-Stripe-built-one-of-Silicon-
Valleys-best-engineering-teams)

~~~
cliftonmckinney
I think the most interesting bit of the Stripe article was that they did most
of their hiring via referrals. That's really one of the very few ways you're
going to be able to hire "people" rather than specifically to certain job
descriptions. Their recruiting method matches their strategy. All too often
companies will say "we hire people, not roles" but then post all their jobs on
job boards where the specific role is well defined. :-/

------
justin_vanw
Who is the target audience for this sort of advice?

The people who will understand this figured it out long before they were in a
position to hire other people. It's just obvious and is repeated so much
(don't hire for specific experience) that it is a cliche.

The people who don't get this will never get it, even if you paste stickers
that say it on the windshield of their car and whisper it in their ear as they
fall asleep each night.

So it's all great to repeat this for the 3 newbs who joined our community in
the last 5 minutes and haven't heard this 80 times already this week, but it
shouldn't be on HN's homepage.

~~~
jbelanich
There are also people who get it but don't care. Not all companies need, want,
or can keep the most talented developers. For them, it is fine to have someone
who just has "5 years programming with java". This advice is too general and
doesn't apply to everyone.

------
tokenadult
Here is another active discussion of company hiring procedures here on HN.
Most of us have been hired for at least one job in our lives, and all of us
who have built up an organization have had occasion to hire someone else
before, so we all think about this. I searched the comment thread to see if
anyone has linked to the Hacker News FAQ on this subject. The last full
posting of that FAQ was a while ago,

<https://news.ycombinator.com/item?id=5227923>

and the tl;dr of the FAQ is "If you are hiring for any kind of job in the
United States, prefer a work-sample test as your hiring procedure. If you are
hiring in most other parts of the world, use a work-sample test in combination
with a general mental ability test."

"Reasons for being selective when choosing personnel selection procedures"
(2010) by Cornelius J. König, Ute-Christine Klehe, Matthias Berchtold, and
Martin Kleinmann backs up this advice:

"Choosing personnel selection procedures could be so simple: Grab your copy of
Schmidt and Hunter (1998) and read their Table 1 (again). This should remind
you to use a general mental ability (GMA) test in combination with an
integrity test, a structured interview, a work sample test, and/or a
conscientiousness measure."

[http://geb.uni-
giessen.de/geb/volltexte/2012/8532/pdf/prepri...](http://geb.uni-
giessen.de/geb/volltexte/2012/8532/pdf/preprint_j.1468_2389.2010.00485.x.pdf)

------
planetjones
Some of the best developers I have worked with weren't Computer Science or
Software Engineering graduates, but had Engineering or Electronics degrees.
However, some companies wouldn't hire them because their degrees didn't fit
their definition of correct.

All the points made about years of service not equaling ability are absolutely
proven, yet ignored by many - I'd rather work with someone who can break
problems down, ask the right questions and think logically - as opposed to
someone who can force a program to work because they know the syntax. Some of
this is how candidates are interviewed too - technical screenings alone rarely
find someone who is good at software development.

Writing a syntactically correct program quickly, is the not the same as
writing a good piece of software.

------
b0rsuk
In general, this article belongs among the best articles nobody will read.

It looks like I might finally get a job as a Django/Python developer after 3
years of unemployment. Encouraged by my local course for unemployed, I visited
the company personally and handed them a dead tree CV and cover letter. I was
mildly amused to find they seem to be just 3 guys in small dusty room. I ended
up on a job interview of sorts I wasn't prepared for. It ended with a talk
about games, Fallout and Counterstrike were mentioned. The best part for me, I
got a homework assignment to test my skill.

~~~
tomjen3
It is embarrassing that in this day and age a dead tree copy of a CV, handed
in in person is what gets peoples attention, but it does.

Also maybe print it in an unusual size -- that way they can't file them away
for "maybe later" as they won't fit and they are forced to have the CV on
their mind. An unusual color might also prevent it from getting lost in the
stack of resumes.

~~~
March_Hare
I'm not a fan of unusual sizes and colours. That said, printing on a decent
linen paper (on the correct side!) has helped me.

------
RandallBrown
I used to complain to the HR department at my last company about this kind of
stuff all the time.

Even after working at the company for almost three years, I wasn't technically
qualified for any of the job postings on the site. I had friends who didn't
apply just because they didn't have all the skills in the "required" section
of the job posting.

Luckily, the developers in charge of interviewing and hiring people seemed to
understand that hiring someone smart was better than hiring someone with
"experience" in random technologies.

------
ruswick
The issue is that "tallent" is nebulous, and difficult for companies to both
define and measure. How does a company determine one's capacity to adopt new
technologies? How do they adequately determine who is "smart" and who is not?
The reason companies resort to hiring based off of experience is that
experience is a reasonable if imperfect proxy for skill, and because someone
who has worked with a technology for some given amount of time can be
reasonably expected to have attained competency in it. Experience is
quantifiable and the link to ability is solid, making it an efficient metric
for use in hiring.

Obviously, the best case scenario would be for companies to deduce who will
have an affinity for certain technologies before they actually use them, but
that's too complex and involves the type of decision-making to which HR
departments are averse.

------
jared314
This is similar to Joel Spolsky's Smart and Gets Things Done [0], but less
comprehensive.

[0] <http://www.joelonsoftware.com/items/2007/06/05.html>

------
arocks
Let's also clarify why experience is misleading in general. The candidate
might have no experience but could have been an early programming enthusiast
with tons of projects under his belt. Current recruiting systems reject such
talent or offer them very poor packages.

------
bobwaycott
Perhaps the better approach to solving this problem is to stop repeating it on
tech blogs, and start moving to publishing and discussing it in HR blogs and
similarly appropriate, targeted mediums. As stated elsewhere[1], this is
undoubtedly the existing mentality of the audience to whom this article is
written. Those who actually need this advice are the existing and future HR
managers and departments who are in charge of hiring.

I spent some time about a year-and-a-half ago building up and managing a small
internal development department at a mid-size corporation. I was involved in
finding talent to fill development roles in the company twice. The first time,
I sat in on an existing search and interviews for a role in a different
department. The process could not have been more broken--the position had been
open for roughly one year, and the interviews yielded no hirable candidate (as
judged by the individuals making the hiring decision). The second time, I led
a search for positions freshly opened for my department. The process could not
have been more smooth--three strong candidates were hired within three weeks.
The only significant difference between the two hiring pushes was the approach
--the first was focused entirely on a candidate who had _n_ years of
experience on platform _X_ ; the second focused on candidates who showed the
greatest talent and aptitude in previous professional and personal projects,
and gave the greatest indications they were a great fit for the personality of
the team.

After we completed our hirings, the VP of HR pulled me aside to mention she'd
never seen anyone conduct interviews like we did (she sat in on a couple after
hearing about how we'd done the first candidate interview), and was impressed
by the way the candidates responded in the interviews. She could "feel" which
candidates were going to be hired, even though she had no knowledge of
software development. We discussed the differing approaches between hiring for
talent and hiring for _n_ years of _X_ experience. She intuitively understood
the difference, but had not ever seen it in practice as intentionally as we
pulled off.

Programmers understand this. Small businesses who are predominantly
programmer-driven or -dependent understand this, too. Even big businesses who
are primarily technology-focused show signs of getting this as well (a recent
round of interviewing with an Oracle company surprised me with how much they
were focused on the _right_ things).

The proverbial dragon to slay here is the HR departments, managers, students,
and training programs lacking this advice as fundamental practice. Perhaps we
need to see more process-oriented and manager-level technologists joining up
with HR professionals to advance the point. Maybe HR departments and
educational efforts could start creating Developer Advocates to assist in
crafting better approaches and more finely tailored practices to support
development/engineering talent. These might be the vanguard of producing
better job descriptions and interview processes to hire talent that is more
competent, productive, dependable, and retainable.

The most important lesson I learned when I worked with a formal HR department
to hire new people is that _they care_. They really do. They don't want to
hire terrible candidates who are going to be miserable, hate their jobs, and
drag down a team. They want to empower people to improve professionally while
taking care of a company's needs. We need to start working with and spreading
this advice among the HR professionals who will increase their value to both
companies and personnel by including it in their standard procedures.

[1]: <https://news.ycombinator.com/item?id=5441337>

[edit: forgot link & punctuation error]

~~~
ritchiea
I don't think you're wrong. But could you define talent? That's something that
bugs me endlessly. Talent gets thrown around recklessly everywhere. Is talent
smart and gets stuff done? Is it more than that? I feel pretty confident I can
identify "talent" but the blog post you are responding to isn't written for me
or you, it's written for people who are already doing things the wrong way and
content with it.

We say hire for talent as though talent is self explanatory. I don't think it
is. Maybe we generally feel like we know talent when we see it but that's not
satisfactory advice if what we aim for is to give advice to people who
struggle to hire good people. If you are the kind of person who hires for X
years of experience you probably aren't the kind of person who feels confident
identifying talent outside of a solid definition.

~~~
kyllo
"Hire for talent, train for skill" means to screen for more general
intelligence and problem-solving aptitude rather than specific buzzwords. You
want smart people who will pick up anything you throw at them quickly, not
just people who have hit all the keywords in their resume.

It may sound squishy, but it's really not. You can tell smart people pretty
quickly from talking through logical problems with them. Dumb people will ask
irrelevant questions and want you to hold their hand and walk them through it.
Smart people will ask smart questions and deduce a path to the solution.

------
readme
Talent is a function of experience. It's not that you shouldn't hire for
experience - you should. The problem is that the model most people have for
quantifying experience is flawed.

As it says in the article, 5 years of experience for one person might be the
same as 1 year for another.

To solve the problem, we need to borrow an idea from RPGs: experience points.

~~~
b0rsuk
Funny, I think it's the other way around. Experience is a function of talent.
Talented people gain xp points faster and therefore level up faster. Or
rather, they have lower xp requirements for new levels.

~~~
readme
It could be that way... I doubt it though. I don't believe anyone is that
innately talented. Try picking up a few musical instruments that you don't
know how to play. Genius is learned, not inborn. You need to be lucky enough
to win a certain IQ and have all your fingers and toes, but after that it's
perspiration.

Find me a child prodigy genius who didn't come from a well to-do family who
paid for tons of tutoring. Find me one from a slum. (hint: you probably won't
find one)

~~~
lccarrasco
<http://en.wikipedia.org/wiki/Srinivasa_Ramanujan>

> Without a degree, he left college and continued to pursue independent
> research in mathematics. At this point in his life, he lived in extreme
> poverty and was often on the brink of starvation.

~~~
readme
>Born at Erode, Madras Presidency (now Tamil Nadu) in a Tamil Brahmin family
of Thenkalai Iyengar sect[2][3][4] Ramanujan's introduction to formal
mathematics began at age 10.

"Brahmin" are the elite hindu upper class.

I would credit you with contradicting me but you haven't.

However, that's a pretty interesting link. Thanks for sharing.

~~~
lani
>> was an Indian mathematician and autodidact who, with almost no formal
training in pure mathematics, made extraordinary contributions to mathematical
analysis, number theory, infinite series, and continued fractions. Living in
India with no access to the larger mathematical community, which was centred
in Europe at the time, Ramanujan developed his own mathematical research in
isolation. As a result, he sometimes rediscovered known theorems in addition
to producing new work. Ramanujan was said to be a natural genius by the
English mathematician G. H. Hardy, in the same league as mathematicians such
as Euler and Gauss.[1] He died at the age of 32.

\-- no formal training \-- developed his own mathematical research in
isolation.

We're talking talent here, upper class or no. Talent is talent ,even when it
is not discovered. In this case ,it was

------
hfsktr
Sadly I think it only just occurred to me that I might be one of those 1 yr /
5 times people. Only because my job was mainly CRUD work. I did get to do some
other stuff but it was not often. That place closed down and I've been looking
for work since. Feeling like I must not have learned enough (or the right
stuff) since I have had many interviews and not gotten any offers.

How much of an average developers time isn't CRUD? How do you get the
experience to do other things[1] unless you needed them for that one off
project?

1\. Unless you are talking along the lines of specializing in something idk
what these things might be.

~~~
russell
You have my sympathies. One thing that might help it to pay attention to your
attitude and demeanor. One problem is thinking that you are humbly begging for
a job and that they are in control of the process. A bit more of a chip on
your shoulder may help. Sure some my be put off by an "attitude", but if you
arent having any success, why not? It may make you look like a can-do person.

~~~
hfsktr
So if I'm reading this right: Act like I'm a pro and can solve all their
problems.

My biggest issue is with confidence. It probably shows in interviews. I know
that given the chance I can do just about any work (some might take more time
but I am willing to put the effort in).

One of the other threads recently was about questions during interviews. I
learned that there are a lot more things I should be asking about that I
wasn't.

------
jasey
This 100%.

I have 6+ years experience now and am going for senior dev roles.

4 of those years are PHP and I feel company's and recruiters pidgin hole me as
a "senior php dev".

I feel like I have to continue down the php stack + web dev path or take a pay
cut even though I have non professional experience in mobile for example.

I understand where they are coming from but a little less narrow mindedness
would be nice.

-gets ready for the 'no one other than a php shop wants to hire a dev with most their experience in php' jokes-

~~~
nollidge
Yes. I increasingly get the feeling that I'm stuck in .NET-land because that's
the only thing that recruiters feeding off of LinkedIn seem to care about when
they "network" at me.

------
fecak
The key issue is probably time investment for companies. Using years of
experience is the easiest way to judge 'ability', and it can be judged by
someone non-technical that can ask simple questions about experience - so
every applicant is not wasting the time of a tech team member. Pay a fresh
grad 30K to review resumes and waste their time instead of your 120K tech
lead.

A trend these days is using interests as a predictor of talent. Most of my
clients (recruiter of engineers) could see two identical levels of
professional experience, but if one of those candidates is writing Haskell at
night that is the one getting the interview. The intellectual curiosity and
interest in complex subjects seems to be an indicator of ability and/or
talent. This could be something easy to teach HR and recruiters, and I always
ask candidates about tech hobbies or "What do you run at home?" to get some
insight.

Most below average engineers are probably not assumed to be researching
complex concepts in their spare time.

To think that companies or individuals will not continue to use experience
numbers in evaluating talent is overly-optimistic, but I think judging based
on interests is becoming a useful means.

------
happywolf
I would agree with OP, until when I has become a hiring manager myself. I do
understand years of experience may not equal to competency in certain skill
sets. But if you are going to run a hiring post, what kind of metrics could
you use, on top of years of experience?

Putting something too generic (e.g. intermediate programmer, mid-level, etc.),
you tend to attract a lot of non-relevant, hello-world sort of people.

Putting a laundry list of language features? You are afraid you could
unwittingly weed out people you want, let alone the first person to complain
would be the recruiter in HR.

Most hiring managers, myself included, just use years of experience as a
guidance so that the candidate can get a feel of the expectations. I did hire
candidates with lesser experience but with good technical competencies.
Therefore there is no harm to try if you are confident you are a good fit. In
fact, I will be really impressed if someone can sell and market oneself
intelligently. Surprise me!

~~~
drewcoo
When I read resumes, and I don't mind personally sifting through hundreds a
week, I look for a narrative. If there's a cover letter, that helps create the
narrative. I want to see personal, professional growth on a resume. I wonder
about time gaps and seeming to do the same job repeatedly but they're not
deal-killers at the resume screen stage. I look for increased depth of
knowledge and increased scope of influence. Both of those things make someone
more senior, rather than having just repeated the same year x-many times.

If someone can sell me his/her story in the cover letter and resume, I follow
up on that in a phone screen. I'm still looking for more proof of someone
being "passionate" (overused term but often part of HR doctrine) and showing
that they grow and grow and grow.

This has never made any sense to any recruiters I've worked with and has
sometimes been a hard sell to others when I wasn't the hiring manager but I
honestly don't know how else to screen for "has a lot of potential but maybe
doesn't know our stack yet".

I'd love to hear how other people do this. I'd especially like to hear from
someone who doesn't focus solely on what's in someone's Github repos.

~~~
hga
That's interesting, and I suppose my resume shows that, although there are ups
and downs, i.e. a very demanding job followed by one not so demanding.

What I do is to express a narrative in each job, showing how I did stuff that
made a difference. I'm most proud of this ending to a sentence in my resume: "
_[my work] provided half of company revenues and enabled another quarter (out
of $5 million for FY92)_ " (it did go along with some demanding work,
technically, and human factor for GUI/workflow).

------
prophetjohn
Here's the strategy we feel is working pretty well for us.

First of all, our tech stack looks like this:

Java/Spring(MVC)/MyBatis/Hibernate/etc

Ruby/Sinatra/ActiveRecord/etc

JavaScript/Angular/etc

A bit of SQL (MS)

We look for candidates of all skill levels who have experience with any
"systems" programming language (Java/C/C++/C#) and any scripting language
(Ruby/Python/JS).

Once we've found a candidate that has any level of experience with both a
scripting and systems language, we send them a small coding project. The
coding project is very easy. Any experienced programmer would be able to solve
it in about an hour. We tell the candidates to solve the problem in any
programming language and that the goal is to show off problem solving, testing
and design skills.

Once we've received the code, we review it for the above stated qualities with
an emphasis on clean, readable and well-tested code. We're not too hard on
these code reviews, we just want to try to eliminate obviously poor fits.
People who write no tests are immediately eliminated. Hugely over-architected
solution? Eliminated. Code is bad enough the person might not actual be able
to program? You get the idea.

Once the person has passed this stage, they come in for an in-person
interview. They are asked to bring their laptop. When they arrive, the dev
manager will show the candidate to the room where they will be interviewed,
talk a bit and then come get two developers for a coding interview.

The coding interview is somewhat on a per-candidate basis, but fundamentally
the two interviewers will review the code beforehand and find places for
improvement. Improvements might be refactorings to make the code cleaner or
new features if the code is particularly well-written. We first have the
candidate give us a code walk-through and explain what's happening, thought
processes, etc. Then one of the interviewers will pair with the candidate for
a while and switch out with the other interviewer after a while.

The whole process thus far is an attempt to, as closely as possible, simulate
what it would be like to work with this person on a real task. No writing
quick sort on the white board. Writing code, at a computer, with an IDE as a
pair. Google stuff, whatever your normal workflow is. We just want to know
what it's like to work with you.

After the pairing part of the interview, we do a more informal group interview
with the rest of the team. We're currently 7 people counting the development
manager, a scrummaster/QA and a PM/QA. So the group isn't too big. This is an
opportunity for more high-level and philosophical questions. "Why do you want
to work here?", "Anything in particular you dislike about Java?". Maybe if
they're more senior, I'll have them explain OOP to our designer to see how
well they can mentor. At the end of this section, we open it up for questions
from the candidate.

So far we've had particularly good success with 1) not wasting our time with
people who can't code, can't test their code or are poor at designing the
structure of their code; 2) finding good cultural fits - if someone doesn't
like pair programming or TDD, we'll be able to figure that out as part of the
interview; 3) not arbitrarily eliminating people because they didn't study
their CS textbook ahead of time or aren't comfortable writing syntactically
correct code on a whiteboard.

~~~
s_baby
>Hugely over-architected solution? Eliminated

For a code interview I can see myself over-engineering a solution even though
my day-to-day coding style is all about flexibility and readability. In my
mind being able to over-engineer shows an ability to code.

~~~
Jare
> In my mind being able to over-engineer shows an ability to code

Huh, very mixed feelings here. My gut reaction is to reply that "it also shows
poor judgement", but there is some truth to what you are saying. The middle
ground would be where you can actually explain what you are trying to achieve
with the over-engineered bits.

~~~
s_baby
What is over-engineering for a toy example is good coding for some problems.

------
warrenmar
There's also the case of asking for N years of experience where the technology
has been around for N-1 years.

------
ses
This resonates a lot with some experiences I have had, and the reluctance to
take a very small risk on whether someone with talent will be able to pick up
a new technology is something I do feel a lot of companies are losing out from
as a result. However at the same time I'm quite sure recruiting is a very hard
thing to do, as there does seem to be a big shortage of both skills and talent
in our industry. I suppose you have to always consider the context of what you
are recruiting for. But personally if I was given the choice I would go for
someone that clearly has talent and ability to learn, as long as there is some
evidence available to show for it.

------
yuhong
I think "years of experience" dates back to the era of widget factories where
it actually made sense.

~~~
trhtrsh
Why did it make sense then?

~~~
michaelochurch
_Why did it make sense then?_

Age and maturity. Most people didn't even finish high school and started work
at about 15. "5 years of experience" meant you were getting a 20-year-old--
likely, for a working-class male before 1960, to have settled down and gotten
married, and to either have a child or be planning to have one.

~~~
jeremysmyth
In the days of guilded craftsmen, apprentices weren't allowed marry.

------
taude
Phone interview with company developing Flex or Silverlight widgets?

~~~
bleakcabal
Yeah Silverlight :)

------
mortdeus
If you are not hiring developers based solely on their portfolio of previous
projects they authored. You are doing it wrong. Every prerequisite requirement
for developers is inherently flawed.

1\. A degree. While degrees are nice and prove somebody is considerably
"intelligent" and not a "complete waste of time", many talented programmers,
especially the ones you want to hire; are fully capable of teaching themselves
without a lecturer.

There are some developers who have already studied the dragon book and have a
sophisticated understanding of how operating systems work because they hack on
Linux.

A developer may make a very reasonable and logical decision not to go to
college because they dont want to accumulate debt, for an education they
already possess, and ultimately waste time not working on their software
projects.

A degree doesnt mean they are a good programmer, and a lack of one doesnt mean
they are a bad one either.

Im not saying college is a bad investment, rather recruiters should not turn
away an applicant just because he passed on that, as they see it, inherently
flawed "life experience".

2\. Years of experience. Assuming the project is well documented... If it
takes a developer longer than 2 weeks to figure out how to use a project's
api, even if they have no prior understanding of the technology.

They are not a good programmer.

If you are looking for a developer to actually understand the internals of a
project well enough to be able to commit, even linux shouldnt take 5 years of
studying before a talented developer is able to visualize whats going on.

Real developers spend almost all of their time reading code and studying
something they havent learned yet.

if they cant adapt quickly to your projects, while perhaps even teaching
themselves the new technology along the way unbeknownst to you. (new
programming language, library dependency api's, network protocol, etc)

They are not a good programmer.

3\. Previous Work Experience [as {insert stupid job title here}]: First, there
is nothing sillier than job titles for programming positions. The only valid
titles that should ever exist for a programmer's job are Hacker, Bit Composer,
Code Poet, Git Wizard (seriously, this is the only valid specialized hacker
position)

Second, Just because Bob has 30 years of work experience as "Lead Programmer"
at "FooBarly inc.", that doesnt mean he is a better engineer than 21 year old,
no work experience, Alice.

While Dino Bob may be able to write optimized, neat, software. And although he
might able to debug rather complicated bugs, and ultimately lead a team to
write a program that does what its supposed to.

Alice may have been an exceptional, innovative, and disruptive programmer who
could have not only written the software but innovated the concept into
something beyond the scope of the original concept design.

There are some hackers out there who can see data structures and algorithms
like a painter can see the scene painted on the canvas before they make the
first stroke. Innovation requires an exceptional level of creativity and the
ability to abstract an opaque idea into a deep, detailed conceptual model.

People cant be taught to think this way. Much like a professional musician,
whom despite practicing each day for hours to perfect their art; will always
lack the skill of a virtuoso mind like Mozart. Many people are great
engineers, but could still lack in talent against someon who was just born
with an exceptionally creative and brilliant analytic mind.

These are the kind of programmers that you cant afford to let your competition
snatch up. Yet you just foolishly tossed Alice's resume in the trash because
Grandpa Bob has credentials and she doesnt.

Interview Quiz: When given questions like, "given two arrays, find all the
elements in one array that are also in the second array". in attempt to talent
scout.

A good programmer will claim the real right answer is either the obviously
simple choice or the theoretically most efficient, and well tested sort
algorithm that can be found using google.

If comparing two arrays is seriously a performance bottleneck that requires
optimization, you might as well skip the bs and go with the best. We arent
solving problems if they no longer exist, and a programmer not solving
problems is a programmer wasting time.

4\. Portfolio A portfolio is the only valid option to consider when you want
to be absolutely sure you hire the best developers.

If the person hiring cant identify what good code is, then your startup is
screwed anyways. You dont need a degree to build a portfolio, and if somebody
does choose to college they get to build their portfolio as part of the class
projects.

If a developer doesnt have a portfolio or if the software in their portfolio
doesnt actually do anything useful then you know they arent a real hacker.

Hiring a programmer should only ever be based on the quality of software they
have authored.

Like Linus said, "Talk is cheap, show me the code".

~~~
facorreia
Often the majority of a programmer's portfolio is code that is intellectual
property of former employers and they can't show it around. In fact, most
times they're not supposed to have that code in their personal laptops.

~~~
hga
Indeed. Some of my portfolio is from dead companies where I got permission
from the rights holder, some is where I got permission to use a few
foundational files that showed e.g. how I do things to improve error reporting
and debugging but none of the company's secret sauce. But neither would have
been possible without my having been in the field for a long time.

------
GoranM
Here's a relatively novel idea (I guess): Outline exactly what you need the
developer to do, and have them send in proof that they can actually do it.

Previous projects, personal github experiments ... Most capable programmers
will have something interesting to show.

Right?

~~~
namenotrequired
Good idea but I think part of the point of the article is that the job will
change. So to "Outline exactly what you need the developer to do, and have
them send in proof that they can actually do it" is, again, to attract people
with 'experience' that happens to fit that particular job description, rather
than talent.

