
It's not a talent shortage, it's a hiring problem - RandallBrown
http://fredandrandall.com/blog/2012/03/10/its-not-a-talent-shortage-its-a-hiring-problem/
======
jnbiche
This, exactly. I keep reading about this huge shortage of qualified
developers, but I've now met enough talented developers looking for work --
who are reliable and talented, and not assholes, that I know that the standard
line about a talent shortage can't be true. Perhaps it's an issue in and
around the Valley, but it's not in most of the rest of the country. If you're
having trouble hiring in the US outside of SF, then you probably either:

1) Fail to realize that good programmers know about programming in general,
and that this knowledge easily transfers from one language or technology to
another. If you're looking for an X programmer with Y years experience in Z
technology, then good luck with that!

2) Conduct your actual hiring process wrong, as described in this blog post.
All these companies ask for "rock star" developers, yet when they actually get
one to an interview, they spend all their time running them through one
whiteboard exercise after another, instead of asking about all their amazing
projects.

Unfortunately, I know I'm preaching the the choir here. I wish this kind of
blog post could reach the eyes of HR people and/or hiring managers. Perhaps it
could change some minds.

~~~
wyclif
"There's no shortage of smart, hardworking engineers. There's a shortage of
smart, hardworking engineers willing to work for very little money." ~ David
"Pardo" Keppel

If you're having trouble hiring, it's probably because you're not paying
enough. It turns out that talented people are worth paying a lot for.

~~~
RandallBrown
It's not that people are having trouble with people accepting offers. They're
never getting to that point because they don't think anyone is qualified.

~~~
wyclif
I'm simply pointing out that the oft-heard complaint from the other side of
the table is flawed. I very often hear startups complaining of talent
shortages. This is false.

------
kenjackson
Yes, there is something wrong. I had a good friend put himself on the job
market six months ago. He has the total package -- has worked on and shipped
well-known products, has reviewable open-source projects and contributions,
great academic pedigree, nice guy, even good looking -- I said something like,
"You'll have five offers at the end of this week".

Three months later, no offer. What was most interesting was how few interviews
he received. He went with the cold resume drop approach. It's almost as if no
one reads them at all.

He eventually just took a job with someone he knew from a company he worked
with in the past. And in fairness he has several open door offers (I've told
him that if he ever wants to work with me, just email me a start date).

But the fact that someone who I would actually describe as top 1% of devs I've
worked with can't get a job without relying on his network is kind of scary.
Imagine if you want to ever change from one sub-industry to another. And some
of the companies he applied to are the same ones you'll hear complaining about
the lack of qualified talent, yet they didn't even do a phone screen on
someone who I am confident is a lot better than 90% of their current
workforce.

~~~
yason
_But the fact that someone who I would actually describe as top 1% of devs
I've worked with can't get a job without relying on his network is kind of
scary._

Isn't it expected and the way things have worked? Friends give friends who
give you jobs. Applying blind is like the shotgun approach because the
relationship between you and the candidate company is nonexistent and has no
context. If you're a friend of Jack's from his previous company, you're
already someone and you come from somewhere. Doesn't necessarily make sense,
but that's how people are.

Further, exceptionally good programmers hang around with other exceptionally
good programmers and in companies that have an eye for exceptionally good
culture. Now, where's the link to your generic Big Co to which you send your
application? Colleagues? Generally no. Management? I don't think so. Name of
the exceptionally good company? Hardly unless one of the big global names. You
get to keep the badges you're known for? Not really, because the field is
different. Would you recognize a good CEO based on the small company he was
working _But the fact that someone who I would actually describe as top 1% of
devs I've worked with can't get a job without relying on his network is kind
of scary._

Isn't it expected and the way things have worked? Friends give friends who
give you jobs. Applying blind is like the shotgun approach because the
relationship between you and the candidate company is nonexistent and has no
context. If you're a friend of Jack's from his previous company, you're
already someone and you come from somewhere. Doesn't necessarily make sense,
but that's how people are.

Further, exceptionally good programmers hang around with other exceptionally
good programmers and in companies that have an eye for exceptionally good
culture. Now, where's the link to your generic Big Co to which you send your
application? Colleagues? Generally no. Management? I don't think so. Name of
the exceptionally good company? Hardly unless one of the big global names. You
get to keep the badges you're known for? Not really, because the field is
different. Would you recognize a good CEO based on the small company he was
working for? Even if the small company is the technical leader of designing
pressure valves? And you're hiring him for the position of a CEO in a game
company? He might be the rockstar CEO but you don't know the field.

My friend is a manager in a big consulting company. We talked and I suggested
I probably wouldn't pass the hiring process of his company, eventhough I work
for a lot more high-end technical company and would beat most of his employees
technically. He was a bit stumbled but slowly realized it might be true. (And
that he might not get into our company, despite his senior experience.) It's a
whole different world there than where I am. ? Even if the small company is
the technical leader of designing pressure valves? And you're hiring him for
the position of a CEO in a game company? He might be the rockstar CEO but you
don't know the field.

My friend is a manager in a big consulting company. We talked and I suggested
I probably wouldn't pass the hiring process of his company, eventhough I work
for a lot more high-end technical company and would beat most of his employees
technically. He was a bit stumbled but slowly realized it might be true. (And
that he might not get into our company, despite his senior experience.) It's a
whole different world there than where I am.

~~~
alinajaf
> Applying blind is like the shotgun approach because the relationship between
> you and the candidate company is nonexistent and has no context.

I don't know, in my (albeit limited) experience this has worked every time.
Once a year in a row for the past five in fact. A nicely worded cold email
highlighting relevant experience with links to code samples usually gets an
interview.

I am definitely not your 1% super-developer, I think I probably sit right in
the middle of the bell curve.

Not to lower the value of networking though, do it. I've learned much from
just talking to people and keeping in touch, and so far I've helped set up a
couple of deals that went well.

------
darksaga
As someone who just went through this, I had a similar experience. I was on
contract through January. January comes around and I figure I'll have a gig no
problem. As a front-end developer, I already had recruiters knocking down my
door.

A month later, I finally landed a gig. I had a few offers, but over the course
of a month, I had more frustration with people I was interviewing. Three
places I interviewed with weren't looking for a front-end guy, they were
looking for a Javascript programmer (my goal wasn't to write JS 7 hours a day
- sorry). Also, I had several instances where the company had no idea what
they were looking for. One company said they wanted someone who did a lot of
server sided Javascript (node.js and backbone.js) as well as being a great
designer. Seriously? WTF?

I agree that most of the interviews I excelled at, was where I got up and
showed the company the app I just helped build. As opposed the the "code
quizzes" a lot of places now use. I actually stopped a guy in one interview
who kept asking me basic CSS stuff and said, "Did you even look at the sites
in my portfolio or my personal site I built?"

All in all, it was very frustrating and I felt like I really had to go way out
my way to try and convince people of my skill level. At other times, I was
trying to pry out of them what they were really looking for.

~~~
mechanical_fish
Your story sounds… normal? This is how interviewing works, especially if you
know what you want. It's a two-way street. Most jobs are pretty lousy, and
even the great ones often don't fit you. You need to interview _them_ and
figure out whether or not their job is worth taking, then turn it down and
move on.

(This is _especially_ true for folks who program Javascript in 2012. It's a
field in enormous flux.)

In many fields, it's normal for interviewing to take months. They warned us
grad students to expect to spend a minimum of three to six months looking for
Ph.D.-level jobs, because you tend to be searching among a fairly small pool
of employers who are looking for folks with specialized training very similar
to yours.

------
sheraz
From the comments here, and in other similar posts, the HN community seems to
think only one side of the interview process is broken.

I posit that all sides are broken -- yes -- the recruiters, the hiring
companies, and YOU, the engineer/marketer/whatever you are.

I'm only going to address the one part that matters -- you.

Who cares how qualified you are? You think that entitles you to a job? Gimme a
break!!! Do me a favor and put aside your naive and childish ideas about job
entitlement...

The following is not prescriptive, but it works for me. The HUSTLE.

1\. Skip the resumes and all formal methods of first contact. Scrape linkedin
and other places to get an inside contact where you want to work.

2\. Skip HR. They are only good for filing paperwork once you have a done
deal.

3\. Once you have a contact send a two line email asking for 15 minutes and a
coffee. Be charming and funny. Don't sell yourself. Let your good looks and
excellent hygiene speak for you.

4\. Whatever your salary / hourly rate is, double it. Think perceived value.

5\. Ask lots of questions.

Note -- this is nothing new. This is business as usual, and I love it.
Networking is everything.

In case anyone here is wondering, yes -- I am a developer from time to time.

~~~
RandallBrown
You can't just "skip HR" at lots of companies. You can't get a coffee with
someone that lives across the country. These techniques work GREAT for some
jobs, but not at all for others.

I don't feel entitled to work somewhere because I'm qualified. I feel that if
I'm qualified and would be a good fit, that the company should want to hire
me. The problem is that they often don't get a good picture of how qualified I
am or how good of a fit I could be. That is the problem.

~~~
sheraz
1\. I've never seen a company where HR was impenetrable.

2\. For cross-continental meetings, substitute coffee for phone call. Or
serendipitously turn up at a conference, a panel, or in the executive wash
room. This is all the easier with twitter and 4-square. Hustling is not
stalking according to my attorney :-)

3\. Companies don't hire you. People hire you. It is your job to get PEOPLE
interested in you, and that does not come from a resume, qualifications, or
any other credential. Those are incidentals and formalities "after the fact."

------
pinaceae
the broader is issue is that learning has been replaced by hiring. the
assumption now is that you already need to bring all the required skills to
the job, to be productive from day one.

the concept of apprenticeship has been completely eradicated.

i work in a specialized area and had trouble finding candidates that matched
my job profile. frustrating. but then i took a step back and looked at how _I_
had gained those skills - through practice, through experience, not through
formal education. so i started to look for good people, good learners,
flexible minds. yes, there will be a ramp up time, but they also come with
fresh perspectives. i can also directly influence their knowledge as i am
their reference point.

and age is not a factor here, last guy i hired is 50+ - and i am 32.

~~~
justincormack
Absolutely. Most people either do not understand the role of apprenticeship (I
try to persuade them to read Richard Sennet's The Craftsman) or simply have a
completely short term attitude, which often means they fail to hire for longer
than training would take, and also blinds them from the contributions
different experiences can bring.

------
corywatilo
This is spot on. I think it's a recruiter problem - many look at the resume
and take that as the full story.

I have a funny example of this "hiring problem." Shortly after I consulted for
a established, public web company, they were hiring a FT person for the same
thing (design-related). The dept I consulted for emailed me and asked me to
submit a resume and said they'd make sure I floated to the top. What happened?
I didn't get past the phone recruiter. I could tell she got hung up (no pun
intended) on something on my resume and I got a rejection email from her
shortly thereafter.

So as this post suggested, the company went the consulting route before-hand
and we worked well with each other. Then a recruiter got in the middle and
messed it all up.

~~~
bartonfink
Did you mention this to the people you had previously been working for, who
knew you, likely recommended you, and could have helped bypass the phone
recruiter?

It seems you would be in a prime position to get the job (if you, in fact,
wanted it).

------
katabatic
I just went through a long job search process in San Francisco, and I actually
feel exactly the same way.

I told several companies "no thank you" after going through their interview
processes, where the _only_ thing they did was asking one whiteboard coding
question after another. None of which had anything to do with the real-world
domain of their business. The company that I ended up joining didn't ask any -
their questions were no less technical, but they were experience-based, rather
than quiz-based.

------
zanny
As a soon-to-be grad looking for a job right now, I don't get why nobody ever
asks for just code samples.

Its like, here are 5 dozen requirements for the position no human alive
currently possesses, now let us talk about everything EXCEPT code.

I'd just say "you want to work for X doing Y using Z? Show us some code
samples of what you have done in the past".

And I would hope it would not always be "show us code samples using this tech
for what we are trying to do" because then I already wrote your back end for
you, apparently. I have a good ~30k lines of code I have written in college
for both courses and freelance, and it all seems to sit in a folder of stuff I
have since nobody ever wants code samples.

There is the flip side, that people could copy paste someone elses work to try
to claim as their own code to get a foot in the door. Dunno how to deal with
that. Maybe just ask for some 1 day assignment. If you are a web company, have
them build a simple table in django using some database. Or something just to
show they know what you are talking about.

But the rapid fire graph search and various sorting implementation questions
and how do you use insert X random algorithm in convoluted way Y to achieve
random result Z drive me crazy.

------
th0ma5
My current reading of the job market around me, and I may well be just in a
funky mood so forgive me, is that all the IT job listings seem to itemize all
the ways you won't be allowed to be creative, and also list a bunch of
surprisingly general, and contradictory, experience requirements. They promote
any kind of actual CS knowledge as being a masters degree skill only needing
10 years in direct experience in a 10 year old technology. This combination
sounds like they have a bunch of old crap that they've built up to be so
complex that no one wants to maintain it, and it will take a year for anyone
to understand it anyway. So that's the total message like "here, you take
this," but the HR people can only translate the requirements into someone that
doesn't exist, because they want someone to hit the ground running, on an
amateur complexity study.

~~~
RandallBrown
I used to passive-agressively mention this to our HR department and my old job
all the time. The basic "Software Engineer" posting has "At least 3 years of
desktop or server software development" as a requirement. I always liked to
point out that I (and everyone else they hired out of college) wasn't
qualified for the jobs we were doing.

They're in Michigan, so finding development talent _is_ a little bit harder so
I don't know why they're discouraging college students from applying by having
pointless job requirements that don't actually matter.

~~~
randomdata
> they're discouraging college students from applying by having pointless job
> requirements that don't actually matter.

From the opposite end of the spectrum, I'm always amazed at the jobs that slap
on the computer science degree requirement. My small rural municipal
government was recently looking for a web developer to work on their CMS. A CS
degree was a requirement for the job, despite there being very little pure CS
work to being with (it is your standard db-driven website).

I don't know, It struck me as odd. Why would this small government, in a low
income area - average single income was $25K/year in a report a few years ago
- restrict their search to people who are said to be in high demand and
probably being courted by places like Google with interesting CS problems that
they trained many years to work on? And as a taxpayer, why would I want to pay
Google prices? It is a useful resource, but not $100K/year useful.

After several months they finally did find someone for the role. Though, I
cannot say if they finally relaxed their CS requirement or not.

~~~
suresk
Playing devil's advocate here a little bit - If you were a small organization
with little technical expertise, how would you hire developers?

As someone who doesn't have a CS degree, I agree that it is frustrating to see
hard requirements like this. But looking at it from the perspective of your
"small rural municipal government", hiring developers is probably a pretty
tough and scary endeavor. Lots of people hold themselves out as developers,
and frankly, a lot of them are pretty bad at it.

How do you tell the bad ones from the competent ones? A CS degree at least
gives you the guarantee that they at least had some training.

~~~
randomdata
I think that is a fair point, but it seems akin to requiring a physics degree
for the job of mechanic. Generally, the people doing the hiring decidedly know
no more about mechanical work than they do about software development, so I do
not think this is a unique issue.

Now, I am sure it would be useful for a mechanic to understand all of the
properties of the materials to manually derive the torque setting needed for a
wheel bolt and all, but in reality, you just follow the book. The science
behind the application is not particularly useful within this context.

Hiring is hard, but I think this goes back to the original submission: If all
you look for is a physicist, you're going to miss the master mechanic. You
might even end up with someone who has no interest in tearing down engines at
all. Is that really the better member for your team?

------
johnnyg
From the other side of the desk, what I am most afraid of is letting someone
with weak coding or technical chops through the door. It destroys teams.

Yes, culture fit is important as is someone who really likes to program and
build. You get to that after you've established that the person can code.

I'm not talking about the google "how many jelly beans in a bus" thing either.
I'm talking "what is an inner join", "what will this loop output". Basic.
Stuff. 9 out of 10 can't do it. Until you establish that you can, the odds say
you can not.

As someone hiring, someone about to put my money in your pocket in exchange
for the skills you bring, I've got to be sure the ROI is there.

~~~
forkandwait
Why not give everyone a simple test, but give A LOT of people a simple test
(which SELECT statement is an inner join...)?

What I always here is that 90% can't write a for-loop or a basic regular
expression, but look great on paper, and vice versa.

EDIT: Recruiters are probably too stupid (usually) to be able to either
administer or evaluate such tests and so will always be more interested in the
"crisper" resume which belongs to some MBA doofus.

~~~
randomdata
> give A LOT of people a simple test (which SELECT statement is an inner
> join...)?

That is like asking, how do you implement a reduce function in CouchDB? The
answer is easy, and would only take a couple of minutes with Google to answer,
but I bet even many top programmers could not answer that question off the top
of their head.

If you are looking for someone who writes SQL queries all day long, maybe that
is a good question. But if you are writing software that does complex
visualizations, occasionally pulling some information from an SQL database,
should a recite-from-memory knowledge of SQL really make or break the
candidate? INNER JOIN syntax is something you can easily query Google for.

~~~
smsm42
I would disagree. There are questions which if you fail to answer this means
your understanding of the field is near zero. For SQL, I would say question
about "which kind of joins there are and why" is like this - if you don't
understand this, you don't understand relational databases. Which may be OK if
the job does not require that, but at least you'll know that about the
candidate.

Another thing is that some candidates (or their recruiters?) "inflate" their
resumes claiming expert knowledge for things that they heard about in passing
or maybe did some trivial task with it. Asking such trivia knowledge allows to
find it out very quickly - if one claims to be SQL expert with 5 years of
experience and don't know what inner join is - he's probably lying. And this
is a bad sign - to start relationship with a lie. I know some people like to
do that (especially because of the keyword-match approach) but it's a huge
turnoff to start an interview with a supposed expert in the field you need and
find out the most work he did in the field was a toy project 10 years ago in
college of which he remembers nothing and isn't even interested in doing that.

~~~
randomdata
> For SQL, I would say question about "which kind of joins there are and why"
> is like this - if you don't understand this, you don't understand relational
> databases.

This is like saying if you can't write a controller in Ruby on Rails off the
top of your head, you do not understand programming. SQL is a vendor-specific
technology, and while it is related to relational databases, is not tied to
the underlying theory. You can have a relational database that does not use
SQL at all.

> if one claims to be SQL expert with 5 years of experience and don't know
> what inner join is - he's probably lying.

I agree with this. If you want to hire someone who understands the inner
nuances of, say, MySQL then it may be a good question. This is quite a bit
different to understanding relational databases though – one is theory, one is
application.

~~~
smsm42
No, it's not like that at all. RoR is a very specific application, if you
can't write a controller then you probably don't know RoR, but it doesn't say
you don't know programming in general.

Yes, you can have relational database that doesn't use SQL at all - how many
of those are around and popular though? There are some, but not many. What are
the chances that you worked with a lot RDBMS, yet never encountered SQL even
at the basic level, and it is not immediately evident from your resume, which
still says "SQL"? But OK, if that's the situation, you can say "you know, I
worked with non-SQL relational databases, and let me tell you about this cool
thing I've done that is way better than SQL JOIN can do" - and that might be
fine too. Usually though the case is just that people inflate their resumes
and think they won't be called out on it. It's very unpleasant because when
you interview somebody whose resume looks good, you unconsciously plan that
you'd get a great addition to your team - and then you discover he doesn't
even know joins... Bummer.

BTW, inner join has nothing to do with MySQL inner nuances - it exists in
virtually any SQL implementation out there AFAIK.

------
georgemcbay
A big issue in modern hiring, IMO, is the combination of diverging specialized
platforms and languages combined with overemphasis on keyword-hiring.

When I first got into the industry you had:

\---

* old fogey LISP programmers

* old fogey FORTRAN programmers

* old fogey COBOL programmers

* Assembly programmers

* C/Win programmers

* C/Unix programmers

* C/Mac programmers

* some people on the cutting edge looking at this new "C++ thing"

* everyone else

\---

I mean, sure you had some specializations but nothing like what you see now.
Now you have:

\---

* young retro hipster LISP programmers

* JavaScript/Client-Side programmers

* JavaScript/Client-Side/jQuery gurus

* JavaScript node.js programmers

* Python programmers

* Python/Django programmers

* Ruby developers

* RoR developers

* Java/EE programmers

* Java-Android programmers

* Clojure programmers

* Scala programmers

* Perl programmers

* .NET/C#/Win32 programmers

* .NET/C#/Silverlight programmers

* .NET/C#/WP7 programmers

* Objective-C programmers

* C programmers

* Embedded C programmers

* C++ programmers

* Embedded C++ programmers

* Go programmers

* D programmers

* Game Industry programmers (usually C++, often treated as a wholly separate category)

* PHP programmers

* etc

* etc (this is maybe 10% of the list I could generate without getting into the really obscure stuff)

\---

Of course a spectacular programmer can pick up a new language/platform quickly
and is usually learning non-day-job related programming languages on his or
her own time anyway, but I've still both experienced and heard anecdotally of
many situations where spectacular programmers were passed over without a
second glance because they didn't have "at least X years of KEYWORD-HEAVY-
SPECIFIC-TECH". Viable commercial quality languages and platforms are
diverging way beyond the ability of even the most passionate programmer to be
regularly using all but a small minority of them.

~~~
mwd_
Just the other day I saw a job requiring "3+ years iPad experience".

I understand the appeal of hiring somebody who needs minimal training, but
they may still not be the best pick. When it comes to a long-term position, it
is better to hire the great developer who takes two weeks to get up to speed
with some language or technology than it is to hire the mediocre developer who
happens to have used Node.js or whatever.

~~~
joe_the_user
But that in itself isn't new...

When Java was young, I remember many tales of Java job advertisements
demanding experience extending back before the language existed.

My impression is that the current insanity isn't so much the absurdity of the
bureaucratic demands but the degree to which people take them seriously...

~~~
pyre
I'm pretty sure these instances (which I remember hearing about too) are just
example of how out-of-touch HR is. Someone says:

    
    
      I need a developer with 10 years of professional
      experience, and he needs to know Java.
    

HR hears:

    
    
      Developer with 10 years of Java experience
    

That, and we all know that sometimes the job listings are just there so that
they can say that they tried to find other applicants, but the friend-of-a-
friend is actually the 'best fit' for the job (i.e. those job applicants are
designed to fail).

------
lrobb
I wanted to relo to the bay area last summer and agree.

What was more bizarre, to me, was that most of the companies never bothered to
look at my sample code or projects... and a few in fact said they _didn't care
what I had done_ (and proceeded to ask me edge-case algorithms stuff).

What was most off-putting, was the incredible amount of _time_ involved in
jumping through the hurdles. I only did this with a few companies, but after
you add up: customize resume / cover letter + initial/hr screen + solve this
screening coding problem + initial tech screen + anywhere up to 3 more tech
screens + solve this more substantial take-home problem + onsite interviews...
You're looking at a substantial amount of time.

------
latch
There's a misconception that anyone can hire. Tech companies are outsourcing
their IT to heroku and AWS because programmers can't sys-admin. They hire
lawyers and accountants to take care of legal and financial matter. But
hiring? "I can do that" they think.

Worse, it isn't a process they try to improve. They don't try alternative
approaches nor do they refine their process through small iterations. They
have a belief in what "good hiring" is, and they stick with it. They swear by
their approach, all the while bemoaning how hard hiring is. They don't realize
_they_ are the problem because, anyone can hire...

I quit my job 6 months ago, and I've tested the water a few times since then.
It's a joke.

~~~
georgemcbay
"There's a misconception that anyone can hire. Tech companies are outsourcing
their IT to heroku and AWS because programmers can't sys-admin. They hire
lawyers and accountants to take care of legal and financial matter. But
hiring? "I can do that" they think."

In their semi-defense, they probably _can_ do it at least as well as the vast
majority of supposedly specialized technical recruitment firms, who are also
largely a joke (yes, there are a few exceptions that prove the rule).

~~~
latch
Good point. I didn't mean for the alternative to be using recruiters, but
rather simply recognizing that you probably aren't good at hiring, and thus
should continuously be looking at improving your process.

------
eshvk
The other problem that I found annoying when interviewing (even with Startups)
is the way the whole system is organized.

1\. Talk to recruiter who is a non-tech person who doesn't really know what
they are talking about and to whom you cannot really go in deep. This is the
only casual conversation that you get to have about the company. (Assuming you
don't know anyone there..)

2\. Have phone screens which are that exactly: Ways for the company to give
you a few puzzles and determine whether you based on whether you follow a
certain process of solving them are actually good enough to join them. At the
end of this, you are asked if you have any questions for them. In a big
company, this person might not even ever work with the team that you are
interviewing for. There is a good chance that after a grilling interview, you
are tired and can't really have an actual conversation.

3\. You have interviews at their office which again are designed to grill the
candidate and don't offer any time for the candidate to get to know the people
on a personal level.

I used to wish there was a way I could talk to an engineer in a company over
coffee (and I am not talking about the whole lunch interview thing that a lot
of companies do) and figure out what they actually do, what they want in a
candidate and what sort of skill sets that they are looking for. Over the past
few months, I have come to the realization that I am not sure many companies
actually know the answer to that and all they are trying to do is to get the
"best" without actually properly defining what that even means.

~~~
ef4
> I used to wish there was a way I could talk to an engineer in a company over
> coffee

There is. You offer to buy them coffee.

In practice, this is actually how much of business (and that includes hiring)
gets done.

The whole "Send resume, pass phone screen, do interview, get offer" thing is
more the exception than the rule, especially for really desirable jobs.

~~~
eshvk
It's kind of hard to be a struggling grad student in Austin and offer to buy
engineers in San Francisco coffee. :-) However, having said that, what you say
does make a lot of sense.

~~~
jarek
I hear there's an event in Austin around this time of year and you can find a
lot of people from Bay Area there...

~~~
eshvk
I already bit the bullet and moved to SF.

------
danbmil99
I think Google set technical recruiting back a few decades. Their process is
and always has been ridiculous, but because they are so successful, everyone
is copying it.

I propose that Google is successful in spite of their vaunted hiring process,
not because of it.

~~~
jrockway
I think Google's process is great. The result of the process is a bunch of
people that are very easy to work with and smart. I never even have to think
about rephrasing something or explaining it more simply; everyone operates at
or above my level. The result is a very stress-free work environment where a
lot of work gets done quickly. (Except when Google decides to buy out a ski
resort and send us there for a couple days. Less code being committed then :)

The process does produce many false negatives, but that's much better than
false positives. Hiring one bad employee can make many people miserable. Not
hiring one good employee only makes one person unhappy. And they can interview
again anyway.

~~~
jarek
> I never even have to think about rephrasing something or explaining it more
> simply; everyone operates at or above my level.

This implies some others have to think about rephrasing or explaining more
simply when speaking with you.

~~~
javajosh
The same thought occurred to me. Perhaps Google is like Lake Wobegon, where
everyone is above average. :)

But a kinder interpretation is to note that there is a kind of threshold of
intelligence which, if most everyone is across it, makes technical
communication much easier. This fact mixed with (false?) humility to yield the
mistake.

~~~
danbmil99
I think the problem with this attitude is the assumption that what you are
filtering for, which for the sake of this discussion is called 'intelligence',
is the sole scalar factor that makes an employee great.

Haven't we all worked with that guy (or gal) who _can't_ explain things as
succinctly as the great, super-quick-witted double-800 SAT guy, but who has
something different, a creative spark, a way of thinking outside the box? To
assume that that character is simply a 'false negative' that an organization
can do without, I think is very naive.

It comes down to risk and reward. Google has a proven business model; maybe
they don't need that extra something that is worth the risk of a few non-
performers. Or, as I suspect, that spark comes mostly from people who ended up
at Google through acquisition, or the few who have reputations that allow them
to bypass the traditional screening process, or they were just there at the
beginning before the process was so ironclad. Or they got lucky and the
interviewer liked them and gave them a bit of a pass.

TL; DR: Do you really only need an army of facile, confident test-takers who
are good at making first impressions?

[Addendum: it occurs to me that if you are as large as Google, you can accept
a process that only produces 0.1% (or less) creative geniuses (because lots of
false negatives get rejected). You may even prefer to keep that number small
but non-zero (a surfeit of true creative geniuses has its own problems). But
is a ratio like 1:1000 the right number for a 20-person startup? I think the
dynamics are much different at a small company. Let's remember, Google is not
a startup, they are one of the largest companies in the world.]

------
tocomment
I had this exact same experience. It sucks. I actually didn't start getting
job offers until I spent a week basically memorizing my entire computer
science education.

It doesn't matter what you've accomplished if you don't remember what a red-
black tree is you don't know how to program.

------
spdy
After reading some of the comments and the blog post it sounds to me everyone
wants to hire like Google... but they are not Google.

In the end when you want to hire, look at what they have done and ask them
about that. In my opinion thats the only thing that counts. Solving quizes
does not sound very important to me.

If someone can walk you through his thought process on his favourite project
you can see if he/she is able to pick up the job you are offering.

~~~
RandallBrown
The point of the article is that even Google shouldn't hire like Google.

I really like the idea about asking about their favorite project though. That
would have helped out a lot for me in my interviews I think.

~~~
saryant
I've started just pushing the interview in that direction regardless.
Generally a question will come up that's relevant to a project I'm proud of
and I'll pivot the conversation over there. I've also found that if I really
frame my answer as a "teaser" the interviewer will be interested enough in it
to ask a follow-up.

When I'm able to pull it off I've generally felt that I've left a better
impression on my interviewer.

------
tokenadult
There is a whole field of study, called industrial and organizational
psychology, that researches issues like what hiring processes are most likely
to obtain employees who do good work for organizations. Studies of many
different hiring practices across many different industries and job categories
have shown that the two most valid predictors of work performance and success
in an occupation are

a) work-sample tests, if one can possibly be devised for a particular job,

and

b) general cognitive ability tests (IQ tests or IQ-like tests such as SAT
scores).

Both work-sample tests and general cognitive ability tests have about the same
predictive ability (predicting less than half of the variability in actual
work performance, but predicting more than any other kind of hiring screen) as
each other, and considerably more validity than many more common kinds of
hiring procedures.

Expecting job-seekers to have

1) X years of work experience in Y technology,

2) a smooth manner in a face-to-face interview,

3) a degree in field Z from an elite university,

or any of many other hiring criteria are all less likely to identify job-
seekers who will be successful on the job than a work-sample test. If the work
at your workplace is so complicated and varied that it is difficult to design
a representative work-sample test for job-seekers, test the job-seekers'
general cognitive ability with one of the validated hiring tests used for that
purpose. That can reduce the expense of your hiring process and improve its
results.

~~~
cheatercheater
CITATION NEEDED.

------
athst
I like the point about how randomness seems to be such a big part of the
process. If you're not using connections and are applying through normal
channels, to me it seems like there is so much that can go wrong that isn't
related to your ability to do the job. Maybe the recruiter had a bunch of
email that day and missed the application. Maybe the person who screened your
email didn't like the font or design of your resume.

To me, one of the big problems in the process is the lack of a feedback loop.
Since recruiters and interviewers rarely give honest feedback (probably for
good reason), it is hard for an applicant to know if they're applying to the
right jobs or not. And faced with this lack of information that would
otherwise allow you to be more effective and only apply to a few jobs that
would be a good fit, the strategy becomes just spamming your resume everywhere
until you get a response. On the company's end, this means that you have this
extra mass of applications of wildly varying quality because no one has a clue
what you're really looking for.

How could this feedback loop be improved? I'm not sure.

~~~
lekus
It will never improve until there is a "real" shortage in the market.

~~~
randomdata
As far as I can tell, a real shortage is basically impossible.

I come from a farming background. On the farm, when the work has to be done,
it _has_ to be done. The crop will wither away and be worthless if you spend
any time waiting. That often means hiring people who are not skilled to get
the job done.

On a grain farm, at least, good help are worth their weight in gold. I see
some farms offering $50/hr. just to find talent. But in the absence of those
good people, you still need someone to do the work. That often means settling
on someone who is unskilled for, say, $10/hr. You just end up hoping the
reduced pay will offset the additional costs of employing them.

The technology sector is different. The constraints on time are completely
artificial. If a really good programmer isn't available today, the project can
wait until he is available next month. Unlike other industries, here there is
simply no reason to hire the less skilled programmer, even at a reduced
salary.

~~~
lekus
Try not able to hire any programmers and losing your existing programmers.
Happened 12 years ago. Just get rid of the H-1B program and wait.

------
JailhouseRodeo
I was checking out the interview questions people are posting on glassdoor.com
and felt pretty stupid after going through them. I work at a successful
startup at a pretty high level, and I could not tell you the best sort
algorithm for some particular case. I could tell you how I would model it in a
database, since that's really where large datasets get manipulated in my
world. I wonder if the types of algorithm-heavy questions I see in interviews
are there because these companies need that skillset, or is it to weed out
people who aren't 'rockstar' or 'A Player' engineers. Sometimes it feels like
a pissing contest to see who has the hardest interview. At my company, we give
you a couple of real world coding tests, as long as you do ok, it's all about
your personality and whether or not you seem cool to work with. It seems to
work very well.

------
ootachi
There are simply very few positions for programmers throughout the country.
That includes the Bay Area. As much as everyone wants to believe it isn't
true, it's true. There's very little demand and way too much supply.

Programming is a losing profession, and if you're in it you should get out
while you still can. Get into sales, marketing, and/or management instead.

~~~
match
Then apparently we're the only company that has crazy number of openings and I
personally talk to people every week that aren't what we're looking for.

~~~
laaph
Hi match,

As a developer looking for work, I am curious what you are looking for in your
future employees. Looking at your profile and comment history gives me no
hints.

Perhaps you have enough people to weed through that you don't want to post
here and get a few more, but I know that I am not the only developer on HN
that is looking for work. I'm also certain that other people would also
appreciate knowing where to look for employers who have "crazy number of
openings".

Thanks,

------
liuming
My stupid comment on the interviewing is: Go figure out how many people can do
an excellent job as an interviewee, take the number, divide it by 10 or 20 -
that's the number of interviewer who know how to conduct a good interview.

------
sn0wright
Glad to have come across this. I'm actually going through this process now,
and its almost comforting to know that this is how it should be :/

It seems its a lot harder when I'm trying to relocate. Me thinks it really is
about who you know.

------
hsmyers
The only question that matters is "Can you do the job?" If you don't hear this
question or for those doing the interviewing, if you don't ask this question,
then there is something seriously wrong. All of the rest is pretty much a
waste of time at least until after that key item is settled. With that out of
the way, then it is time to worry about how well someone may or may not fit in
etc (something that can be allowed for or fixed as may be). And whatever else
might come to mind. But first and foremost everyone should realize that doing
the job is the single most important item.

~~~
match
"All of the rest is pretty much a waste of time at least until after that key
item is settled."

Yes, but unfortunately settling this item is not as simple asking "Can you do
the job?". Oddly enough all the candidates say "Yes".

~~~
meric
What about doing some sort of 3-month probation thing? Is that legal? Will
that turn away too many developers?

------
JoeAltmaier
Been working at startups all my life. Got all of them but one from folks I
worked with at previous job(s). Except the college hire of course - that was
pre-trick-question-interview and my hobby projects caught their interest.

The 'but one' was more interesting. Moved to a new state, drove over to the
University incubator, knocked on doors and chatted with people. Nobody turned
me away. Two were interested, but one was moving to Detroit (no thanks!) so I
took the other one. Worked out pretty good for a couple of years. Total time
'interview to job' - 1 day.

------
geekin
Other problem is that interviewing is a lost art. Most companies ask their
developers to interview from a set of predefined algorithm/DS questions -
there is no way to know if the candidate answered from his own thought process
or just knew the answer. So most of the tech interview become a game of
chance. I liked this article which says "let the interviewee impress you" -
let the candidate show what he can do - give him a problem to solve on
computer during a whole day or perhaps a week - see the results ?

------
jerickson
We often find that there are plenty of technically qualified people out there,
but what you can do isn’t the only factor in hiring. The most important thing
about hiring talent is finding talent that works well with your existing
talent. In other words: finding a good CULTURE fit. There are LOTS of smart
people out there, but only a small percentage of those people are sociable
enough to really do an exceptional job as a part of a TEAM, and teams, not
talent, build products.

~~~
j_baker
Actually,I would argue that talented teams build products.

~~~
jerickson
Of course, but that includes being talented at being part of a team ;)

------
igorhvr
What works for me is:

a) Making the candidate interested - I want them to be really interested in
being hired, to ensure he will give his best shot (this is much easier when
hiring with a specific spot in mind, which is not always the case);

b) Using a coding test that the candidate can do remotely at the time most
convenient for him (<http://www.codility.com/> currently - they are _really_
good for this) as a first filter. This establishes basic programming skills,
and allows me to...

c) Call the candidate for an in-person conversation and spend much more time
discussing higher level questions, validating problem solving skills, and
understanding the candidate past history. Unless it is remote position, in
which case this will be a phone screening - notice I say an _phone_ and not
some kind of crappy can-barely-hear with-echo-or-lag-or-some-other-crap VOIP
solution.

Finally, keeping this in mind has helped a lot:
<http://news.ycombinator.com/item?id=3690544>

------
brooksbp
> I’m generalizing here, but I think that if I’m qualified to work for
> Microsoft, I’m probably qualified to work just about anywhere.

> Companies shouldn’t be turning qualified candidates.

> I feel like there are so many reasons to hire me

> I didn’t get to talk about the iPhone app I built.

Stop right there. You are not generalizing. You are talking out of your ass. I
am always shocked when I run across people my age who are so arrogant. No
matter how qualified you think you are, there will always be problems tougher
than you have faced, hw architectures more delicate and complex than you have
dealt with, and people who can blow your mind in ways that you cannot imagine.
When you eventually acknowledge this, you should be grateful for the
opportunity to learn what you can every day and that someone is _paying_ you
to do it. Fast forward 10 or 20 years and then we can start talking about
value.

------
davyjones
Every time I hear a puzzle based interview process, I recall this anecdote of
Asimov's:
[http://shuzak.com/Replies.php?ID=582&Topic_ID=556](http://shuzak.com/Replies.php?ID=582&Topic_ID=556)

------
lekus
The problem has been solved long ago by other industries, see lawyer and
doctors. Eg: entrance qualification + no H-1B competition for jobs.

------
danielrhodes
Given the harm a bad coder can do to a codebase and the morale of a team, it
is better to not hire a good coder than hire a bad one.

~~~
RandallBrown
I totally agree. The whole point of the post was to point out that there are
lots of good coders out there that are being labeled as bad coders because of
poor hiring processes.

~~~
match
I agree with you that these companies are probably turning away qualified
developers. However at my current job it is the prevailing feeling, and I
mostly agree, that it's better to turn away a few qualified candidates in
order to prevent a mis-hire.

~~~
katabatic
I generally agree with that sentiment too -- having seen what a bad hire can
do first-hand. However, I feel like the industry has gone too far in that
direction, and may in fact be selecting for a different kind of mis-hire.

When you spend an _entire_ interview doing college computer science quiz type
questions, and none of it on process, code review, coding style, development
philosophy, approach to testing, etc.... you end up selecting for people who
are good test-takers, but may not be any good at writing maintainable code. Or
debugging. Or troubleshooting production issues. etc... etc...

~~~
match
I actually agree with you. This is why I never make a hiring decision based on
a single trivia question, but I do ask trivia questions that are all over the
map on a topic in order to find something the candidate is good at. Honestly,
if you can answer any of my trivia questions in a deep and meaningful way that
demonstrates insight into the topic then I'm satisfied.

------
earl
I personally _hate_ graph algorithms and all the stupid associated questions.
I have to spend two weeks reviewing all that stuff every time I change jobs to
go ahead and never ever use it again. It simply never comes up in the type of
work I do.

At my current place of employment, one of the engineering managers was
complaining that an interviewee bombed a graph algorithm question. I asked,
"Where -- if anywhere -- in our codebase do we use _any_ graph algorithms?"
Answer: "We don't." At all. Yet knowing graph algorithms is apparently a
requirement for working here, which means that at minimum, I am unqualified to
do my job. Sigh.

I'd much rather candidates spent time understanding memory implications of
different types of java/jvm data structures, or know how to diagnose and fix
memory pressure, or have experimented with design patterns to reduce memory
requirements, etc. But nobody asks me. If you know off the top of your head
that in the hotspot jvm an Integer is 4x as big as an int and that a Double is
24 bytes, and can figure out the rough size (8.5KB!!!) of a 100 entry
TreeMap<Double, Double>, and know what compressed oops does and why it works,
you'll almost certainly get a "please hire" vote from me.

edit: note that knowing a bunch about jvm memory use isn't a requirement, but
knowing it will impress me. It probably also means you've been burned by jvm
memory use before and that's why you know this stuff.

~~~
archangel_one
I've been interviewing recently and my opinion is more or less the reverse. I
preferred the interviews where I was asked algorithms - only got asked on
graphs once, but my last job did involve a lot of those so I was pretty
comfortable with them. They seemed more useful to me than asking "trivia" type
questions which you could learn in fifteen seconds - for example, I got one
elsewhere about access to members of nested classes in C++, which I just
couldn't remember at the time. The thing is, you can solve that immediately if
given a compiler.

Personally I'd rather have a coder who understands the concepts behind these
things, even if they don't necessarily know the answer right then, than one
who is simply able to rattle off definitions by heart. In the example you
gave, I agree that it's valuable to know that an Integer is significantly
bigger than an int, and that a Double is bigger, and that your TreeMap<Double,
Double> might be bigger than you expect, even if they didn't know the exact
sizes of any of those things - but I guess I'd want them to be able to take a
stab at working them out.

~~~
pyre
I think the point is not that someone who doesn't know about Java memory
issues is useless. The point is just that someone who knows those things, but
doesn't know graph theory well may be a better fit for the job, but the
interview process doesn't account for this.

~~~
ma2rten
Well, I think the goal of these graph questions is not so much figuring out if
they "know graph theory". But, rather, figuring out if the candidate had a
solid Computer Science education and if they can think about a problem in
abstract terms (as a proxy for being smart in general). The idea being that if
those two things hold true, they can learn everything else on the spot.

~~~
kelnos
I don't have a solid CS education (I studied EE in college), and I've had no
trouble getting interesting, satisfying jobs at startups. Frankly I've found
little correlation between CS background and whether a candidate is a good
developer or not.

------
georgieporgie
A few years ago, I applied to a senior Windows dev position. As I recall, they
needed someone primarily to port existing software. One of the first interview
questions was about how I would optimize shell sort for some particular edge
case. The interviewer did not appear to have any papers with her that
contained shell sort. I don't know if she thought I would remember it (last
time I implemented it was high school), or what.

In months of sporadic interviewing, I don't recall being asked a single
question relevant to Windows development, engineering strategies, how I
comment my checkins, or any of a million other things which seem much more
vital to me. _Every_ interview centered on puzzles and algorithms. _Every_ job
listing was for Windows/C++ with various platform-specific technology
requirements that I fit.

Personally, I think a lot of employers just like to have perpetual job
openings. It makes the company look good. Also, I think that a very, very
large percentage of the "screening" is really just to provide justification to
the subconscious decision that was made within moments. There's a reason that
Silicon Valley is almost entirely white, male, and under 40, and it has
nothing to do with technical aptitude.

~~~
grannyg00se
"There's a reason that Silicon Valley is almost entirely white, male, and
under 40, and it has nothing to do with technical aptitude."

Ouch....That's a very damning statement. I'm not in a position to comment on
the truth of it - all I can say is that I hope you're wrong.

~~~
gruseom
_Silicon Valley is almost entirely white_

That's far from the case.

~~~
angelbob
In small startups it's white, Indian and Asian. There are occasional women but
less frequently as programmers. Women are more common as designers and
sometimes sysadmins, though.

Bigger companies don't look like this. They look more like big companies all
over.

~~~
akkartik
I work at Google, and while you can level a lot of criticisms at it, this is
not one of them. Half the employees I see around Mountain View are asians or
indians. (I am indian.)

------
devgutt
<sarcasm/> :)

