
Destroy all hiring processes - ubernostrum
http://www.b-list.org/weblog/2015/oct/19/destroy-all-hiring-processes/
======
dx211
A couple of years back, I was hiring some vendor developers for my team, and
since I had some flexibility in the interviews that wouldn't be allowed for
full-time employees, I tried an experiment: For one of the vendor candidates,
I told him a day ahead of time that I'd be asking him to implement
System.Collections.Hashtable in C#, with behavior equivalent to the one in
.Net. The day of the interview came, and he whiteboarded it flawlessly, to a
degree that I'd never seen any other candidate accomplish, and he was able to
have a deep conversation about the implementation and all of its nuances. He
then proceeded to bomb the rest of his interviews and didn't get the position.
What this illustrates to me is that the typical programmer interview, where we
come up with some weird problem and toss it to the candidate while they have
no references to look at, no IDE to type into, and a 45 minute deadline
looming over their head, is totally divorced from the actual work we actually
really want them to do. If I need someone to implement a widget, I'd rather
they took some time to research it and do it right, versus trying to crap out
a solution in five minutes on a whiteboard.

~~~
thaumasiotes
I recently interviewed with a company that had advertised (in my paraphrase)
"we've noticed that a lot of perfectly good developers do poorly in interviews
for reasons that appear to be unrelated to job performance. So you can now
interview with us by completing a project on your own time, and during the
interview we'll talk about that".

My project was a regex matcher. I ended up getting the following feedback:

> We thought you wrote a great, very full featured regular expression matcher.
> It was especially impressive how much you dug into the academics behind
> regular languages.

> However we made the decision because we felt that while going through the
> project together during the interview, we didn't see the fluency of
> programming when adding to it that we had hoped for. While we specifically
> designed the take home project track to help overcome the difficulties of
> coding under time pressure with someone watching, we do still need to see a
> certain level of programming during the interview. This didn't seem to be
> the case here.

It's hard to know what to do with that. :/

~~~
1stranger
Wow, that really sucks. So they basically took the old process and just added
more to it.

~~~
sokoloff
Disagree (on the second part). Rather than giving you the equivalent of a
walk-up pop quiz on a random topic, they are giving you followup questions and
discussions on code that _the candidate_ wrote recently.

That seems quite a bit more representative of regular work than a pop quiz.
Yes, you still need to be able to talk live about code with other developers.
That's unchanged and shouldn't change, IMO.

------
Mithaldu
> even if we don’t have a sense of ethics we do have a problem of numbers, and
> more desks and seats and spots than people to fill them

I get this a lot, but it is amazingly self-inflicted. Almost all of the random
job offers i seem to be getting from people i don't know are from clients who:

\- underpay

\- demand on-site only

\- don't even look at the copious provided code samples, only at the CV

The reason for that is simple: A lot of companies view developers as identical
to factory workers. There is nothing more to it.

\--

Sadly i think this is not something that writing blog posts about can possibly
help. The people making these mistakes when looking for developers make them
because they are ignorant and do not care enough to gather the required
knowledge. Until they realize their "illiteracy" and wish to fix it
themselves, the scale of this education problem makes it unassailable.

~~~
xacaxulu
>> demand onsite only!!

The companies making the most demands usually offer the least. My favorite new
flavor is recruiters saying "well for remote the pay rate is lower" to which I
answer, "will I be doing less work in that case?".

~~~
MCRed
Interesting... as I have taken to giving the random LinkedIn recruiters two
rates-- one an on site rate and one a remote rate. The remote rate is my
normal rate, which is lower than the on-site rate which has a healthy have-to-
go-into-an-office premium.

When you couple that with the higher productivity of remote work, the smart
employer will let me work remotely (at least most of the time.)

~~~
Mithaldu
Same here, i quote them my current rate for remote work, and for on-site work
they get a markup.

------
msoad
I'm working on open source stuff for two years now. Everything I do is public
for everyone to see. Including my responses to bug reports and design
documents.

Yet I get the same algo/ds puzzle questions that you should've solved before
in order to solve it in an interview setup. Google reached to me and said
based on my profile I can skip the phone interview but I'm so afraid of the
interview that I postponed it multiple times.

I'm fine with algorithm questions only if I'm solving it in the same setup as
my actual work where I have access to internet and can write some quick
programs to test my ideas. I was good at solving pretty much any problem I had
in my actual work. Even if I had to read a paper on the topic or learn about a
new concept from ground up.

Google asks questions like pots of gold[1] where it's really impossible to
solve it on a whiteboard if it's your first time seeing the problem.

I'm on hiring side of equation also. I get it, it's really hard to judge
people. Even when the candidate have a GitHub page. I got a candidate from
Hack Reactor where he had tons of contributions. But when I looked closely at
those contributions they were mostly fake. Some other candidate had exactly
same codebase in their GitHub.

[1]:
[http://careercup.com/question?id=15422849](http://careercup.com/question?id=15422849)

~~~
eveningcoffee
* Google asks questions like pots of gold[1] where it's really impossible to solve it on a whiteboard if it's your first time seeing the problem. *

Ok, so here is an anecdotal sample. I have not seen this problem before.

After reading the problem description I tried one round of the game on the
paper (actually in the text editor) to get the feeling of the game play and
then it took me about few minutes to come up with one possible solution and
then after a little bit of thinking with a more optimal one.

So not impossible (but I was in comfort of my home).

I actually think that this is a rather classical CS problem that does not
require some thinking about more abstract mathematical corner cases.

I give an example of the later one.

You have an array or numbers [1 - n], that is not sorted. One of the numbers
got changed to 0. Given an array after the change return the changed number in
linear time.

Assume the some array but two of the numbers got changed to 0. Given an array
after the change return the changed numbers in linear time.

~~~
plonh
Do you allow linear space?

~~~
eveningcoffee
Nope. Constant space.

But there is a catch that is very likely not obvious here. All the numbers in
the array are (were) unique (and the zero was not present).

~~~
msoad
You didn't say all the array includes all numbers with no repeats ect ect...

~~~
eveningcoffee
This is also case with the job interviews.

Some information is actually missing/not obvious and interviewers may actually
evaluate your reaction to this situation because this would also model (to
some degree) a real life situation.

So I added the missing bits (and fixed typos).

You have an array size of n of integers from 1 to n, that is not sorted. There
are no duplicate numbers in this array.

One of the numbers got changed to 0. Given the array after the change return
the changed number in linear time and constant space.

Assume the same array but two of the numbers got changed to 0. Given an array
after the change return the changed numbers in linear time and constant space.

The first part of this problem should be simple. The second part is more
tricky.

~~~
Schwolop
FWIW I've had this same question in an interview years ago in Australia. Don't
recall seeing the second part (which is more interesting, mathematically), but
it just goes to show how many questions end up re-used by different companies
as their employees travel.

------
gfodor
"People who have a master’s degree in CS but seemingly can’t code their way
out of a paper bag probably actually aren’t bad; more likely they had an
education which de-emphasized practical hands-on programming in favor of heavy
theory. People who post “please give me the code” questions on mailing lists
and forums probably actually aren’t bad; more likely they had an education
which was based around memorizing and regurgitating stock answers to stock
questions."

What does this even mean? When someone lacks a certain skill, they aren't
"bad" in some objective sense, they are misqualified for the job. If someone
can't code their way out of a paper bag, should we be hiring them anyway for a
programming position because they're not "bad"? What's the point of the
interview in the first place? I don't understand the argument.

To the other points, I completely agree there are many ways to screw up
interviews and few ways to get them right. I'm still a believer that an
interviewer who administers a coding question, one that is reasonably
realistic, in both form and the environment the candidate has (ie they have
their own laptop) can be a good way to assess someone's skills if you are
doing it right. You let them work, let it be a humane environment, and don't
get too hung up on the details. Usually if someone can hack it bleeds through
pretty clearly, even if they don't get to the exact solution you wanted. (And
of course, this is just one data point, that should be distilled into a larger
picture of the person's history, accomplishments, etc.)

~~~
ubernostrum
For much the same reason that someone who has no CS background can
productively do a short coding bootcamp and be employable, someone who has a
theory-heavy and practice-light CS background can almost certainly pick up
practical skills quickly. It's more of an educated vs. educable thing, and
anyone who's demonstrated that they're educable is probably worth at least
looking into a bit more even if they don't come with the full practical
skillset already.

(and I say this, ironically, as a lifelong opponent of theory-heavy CS
programs which churn out people who can derive an answer to your question
straight from the Church-Turing thesis but couldn't code it up to save their
lives)

~~~
morgante
> For much the same reason that someone who has no CS background can
> productively do a short coding bootcamp and be employable, someone who has a
> theory-heavy and practice-light CS background can almost certainly pick up
> practical skills quickly.

I don't think they're equivalent at all.

The truck driver simply never had the opportunity or exposure to programming.
He didn't know what it was like and hence couldn't do it.

The theory student did have exposure but was either incapable or uninterested
in pursuing it. Even in the most theory-heavy of programs, you program a
little. The kids who actually understand and like the programming aspect latch
onto it and continue to learn and grow, ending up employable. The kids who,
having been exposed to programming and realized that it's not for them, never
learn any more and continue to flail around in masters programs teaching
mathematics in the guise of CS.

------
aurelianito
When an actor goes to an interview (aka: casting) twice, he gets paid. I think
we need this in this industry. A lengthy interview should be remunerated.

~~~
kyllo
That's because actors have a union.

~~~
aurelianito
We need a union then.

------
fishtoaster
I'm of the opinion that pretty much every interview technique has at least
_some_ tradeoffs. Too many false positives, too many false negatives,
selecting for or against certain groups, etc.

At my current company, we don't do any phone-coding or whiteboard-coding, for
which I am very thankful (for the reasons the article laid out).

We _do_ do a take-home dev test (4-6 hours). This has the benefits of being
low-pressure, repeatable, and similar to the real work we do. It has the
tradeoff that we might miss out of great devs who don't have the time to do
it. We're working on shortening it to offset that.

We also do a bit of paired programming on-site (using the candidates computer
and dev environment of choice). This has a distinct tradeoff, since it can be
a bit high-pressure. We try to do everything we can to ease candidates, but I
haven't found anything else that works well for getting a feel for what it's
like to work with someone in a technical capacity.

Every interviewing technique has issues, and I think phone and whiteboard
coding are among the worst still actively used (now that brainteasers are
mostly dead). I think what we have is the least-bad, but we're still iterating
on it (and hopefully always will be).

------
aggieben
> a belief that memorizing a bunch of that stuff and being an automaton who
> spits back the correct algorithm name and a pseudocode implementation is all
> there is to programming. Because what companies really want is to hire a
> Fisher-Price See-‘n-Say toy, right?

I get the overall rant. I understand the frustrations - but this is wrong-
headed. If you can't see the value of understanding algorithms - learning both
how to write them and how to evaluate them (including proving their
correctness), then you've misunderstood computer science education altogether.
Nevermind all the rest of CS, which encompasses far more than just "names of
algorithms".

~~~
ubernostrum
It's more that there's a lot of cargo-culting and "Google did this, so it must
be good" flying around, and a _lot_ of really bad CS programs which revolve
more around the Feynman-rant memorize-and-regurgitate style than actually
understanding performance characteristics. Which in turn produces interview
processes that really are of the See-'n-Say variety.

Though to be honest, for a lot of what I do my working set in memory
(metaphorically) involves very very little algorithms/data-structures stuff
and a lot more quirks of libraries/frameworks/protocols stuff. When I need the
algorithms and data structures, I pick up the reference I keep on my desk and
look up the thing I'm thinking about to double-check that I'm using the right
approach.

~~~
aggieben
Fair enough, but then you should explain that what you're against is mindless
regurgitation, not good CS education (which again, has algorithms at its core,
but goes far beyond that).

~~~
ubernostrum
I think that what you seem to be treating as "good CS education" is something
I'd be more likely to call "good math education, but probably not great
training for programming".

A big part of the problem is over-generalization. Here's a reddit comment I
posted in a similar discussion not too long ago, touching on that:

[https://www.reddit.com/r/Python/comments/3nfbkr/patreon_is_a...](https://www.reddit.com/r/Python/comments/3nfbkr/patreon_is_a_flask_app_and_was_hacked_because/cvobo03)

The person I was replying to there had made the mistake of assuming that
because in _these_ fields of programming, knowledge of data structures,
algorithms and big-O characteristics is one of the most important things for
performance, that must be true of _all_ fields. When, in fact, it's not true
of all fields, and I provided an example of one where it isn't true and where
quizzing someone on their big-O cheat sheet wouldn't actually reveal whether
the candidate has the most relevant knowledge for what's going on.

------
raygull
I've been interviewing recently and it does suck just as described here, so
I'm glad somebody called out these issues.

One company I talked to was like a caricature of the bad startup interview: we
have a billionaire founder, we have wine on tap, a totally disorganized 4-hour
series of discussions where the first person just sat down and started
quizzing me with hardly an introduction, and I had to ask the second
interviewer how many people I'd be talking to, technical questions ranging
from the simple to somewhat difficult (using paper and pencil), with less and
less time for each because they couldn't follow their own schedule, followed
by an interview with an arrogant, hypercaffeinated CTO, consisting of two
brain teaser questions and a series of elevator pitches, all in a tiny glass
room near the back storage area, devoid of oxygen. And the following week I
found out, sorry, they'd cut funding for the position the day before I came
in.

------
dustywusty
As both an interviewer and interviewee at Weebly, I'm pretty confident in
saying I prefer our approach of the trial week. It really gives a great
opportunity for the candidate to show off their skills without the on-the-spot
pressure of a coding interview. A great side-effect is the candidate gets to
determine if they like the team, and vice versa. I honestly wouldn't work
somewhere else where I couldn't come in for at least a few days to meet and
work with the team.

~~~
weebelo
<em>I'm pretty confident in saying I prefer our approach of the trial
week.</em>

A full week is pretty close to insane. It means that application is
effectively limited to the currently unemployed (or those who are willing to
burn what might be all the vacation they can take for months).

That said, it does make pretty clear that Weebly doesn't give a single shit
about employee's lives; so it's kind of Weebly to make clear, right out of the
gate that they expect to be the only thing that matters in your life.

~~~
dustywusty
As a pretty happily employed Weebly for a few years now, I'm frustrated that
you think that, but I'm glad that you went out of your way to register an
account to reveal your thoughts. In this case, I guess we'll just agree to
disagree.

------
flippyhead
It's funny, I've tried tons of different approaches to solving this problem
and the only thing I now do is spend about 30 minutes with someone then decide
to hire or not (usually I'm able to express this on the spot to whomever I'm
interviewing). For better or worse, my instincts about who is smart, honest
and kind seem at least as good (and often better) than any other approach
we've tried.

~~~
fishtoaster
I'm curious how you validate that approach. I'm not saying you're wrong– just
that I don't know if you'd be able to tell if you're wrong.

Do you measure the performance of people hired through that method, and have
you done so for a long period with a significant sample size? Do you manage to
measure your false-negative rate (by somehow following up on candidates you
passed on)?

~~~
flippyhead
Well, the false-negative rate is something we never did even when we tried all
kinds of other "standard" interview approaches. If you had a solution for that
it'd be useful generally I expect. I'm only make anecdotal comparisons to the
quality of persons hired by all other approaches vs. me just using the massive
pattern matcher in my head. And to be sure, my company is small and it's my
company so the ultimate determinant of hiring quality is really just me. I'm
not sure this approach would work for medium+ organizations.

------
blizkreeg
> Even among the most common demographics for developers (American, male,
> white, skewing young and middle-class background), we are absolutely abysmal
> at this..

How does nationality, gender, race, age, and income level have _anything_ to
do with this _at all_?

~~~
ubernostrum
People tend, consciously or not, to recruit most heavily from among people
like themselves (for lots of reasons which aren't necessarily bad: a lot of
referrals are based on knowing someone, for example, and a lot of peoples'
social circles/contacts tend to be pretty homogeneous to begin with).

In other words, even on the easiest default approach (recruiting from people
similar to ourselves), we suck. God help us as we try to recruit from people
dissimilar to ourselves.

~~~
blizkreeg
IMHO you are subconsciously profiling if that is what you're doing in your
hiring i.e., making assumptions about people's skills/talent based on any of
those attributes.

~~~
URSpider94
That's exactly what you are doing, and there is copious data out there to say
that we all do it. The generally accepted term is "unconscious bias."

I saw a summary of a study recently in which people were asked to rate top
character indicators of success for male and female candidates for a job,
things like "aggressive," "nurturing," "outspoken," "mediator." Not
surprisingly, the adjective sets for male and female candidates were
substantially different.

------
JB8130
I didn't read the entire article, I stopped after a couple of paragraphs. The
problem as I see it is companies are trying to hire coders when they really
want Software Engineers. Or maybe I should say they are trying to buy a
Software engineer but only willing to pay the coder rate.

A good Software engineer can design a program or system and not even have to
know the programming language, they understand software and how it should
work. I have on many occasions told our SQL coders/programmers where problems
are and how to fix them without ever having programmed in SQL.

The key is the Software Engineer understands the fundamentals of the system as
an engineer and understand how everything goes together and should work. For
example, if you are designing a business system, you engineers understand how
the business works and how the program can help it. The coders know how to
implement the design but not the why's.

If you are hiring outside vendors then it is even worse. They are coders that
know nothing about your business or your project or what you are trying to do
but they do know how to code something, let you try it, have you change it and
try it again and change it again and try it again an...you get the picture. If
you hire a software engineer that understands software and learns your
business, they can develop design documents that can then direct your vendor.
This creates a better product the first time and at a lower cost.

The schools today are creating more and more programmers and fewer Software
Engineers.

------
jvanderbot
I would offer that the subtle point missed in coding interviews is the ability
of the interviewer to judge the flexibility, poise, and social skills of the
interviewee. That seemed very important during my interviews. This may be why
the best advice is to "talk it out"

Any yay-or-nay judgements based on hastily-written program output should be
taken with a grain of salt by both parties.

------
DrJokepu
I disagree with this. Coding interviews are great. The interviewer needs to
realise though that they're not there to be an adversary or a judge, but to
help the candidate demonstrate their skills, to help the candidate get the
job.

~~~
toolz
I feel like all you're saying is 'Coding interviews could be great' not
'coding interviews are great'.

------
NullCharacter
As someone in the computer science/cyber security field who _didn 't_ go to
college, I tend to agree with this article in a few ways. Having no college
degree has really hindered me in terms of landing interviews, but once I'm
given a chance on the job I'm always flourished and proved my worth.

I've also found it strange that it didn't matter what my degree was in, just
having one wold have secured me interviews. A theoretical degree in Turfgrass
Science would have benefited equally as a proper degree in CompSci.

------
dkarapetyan
Try triplebyte. Their process is actually pretty good.

------
Overtonwindow
Perhaps I missed it, but I didn't see anything mentioning certification. With
that be an alternative? If you're hiring someone to code in Java, is there not
a certification they can get?

------
tpiha
There might be a solid startup opportunity here. I completely agree with the
author, from both employee and employer point of view.

------
teen
this article is awful. it cites a single bad coding interview as a problem
with all coding interviews. as someone who gives tons of code interviews, they
are absolutely invaluable, and are a strong indicator in weeding out people
who can't write code. you can't blame bad interviewers for the entire process
not working.

~~~
gqvijay
Slippery slope fallacy...You are incredibly oversimplifying what he is saying.
Sure, he is generalizing but he isn't citing a _single_ coding interview to
judge the _entire process_.

Having said that, I actually agree with him because I've learned that it's not
always simple as _who can 't write code_. I would much rather assess a
candidates' ability to learn (sharpness) than the current skill-set.

~~~
fieryeagle
Second this, but Joel Spolsky said it much better
[http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...](http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html)

