
On Secretly Terrible Engineers - minimaxir
http://techcrunch.com/2015/03/08/on-secretly-terrible-engineers/
======
patio11
It is, regrettably, not the case that all people who work as software
engineers can e.g. code a for loop which counts the numbers of lower-case As
in a string. This is true even if you spot them the syntax for a for loop and
finding the Nth character in a string. It is equally true if you allow them to
complete the task in isolation, at their own computer, given an arbitrary
amount of time to complete it.

I am, naturally, constrained from saying "Here's a list of three of them." It
would not be difficult.

It is also, regretfully, not the case that all applications one receives to an
advertised position of Senior Ruby on Rails Programmer would be from people
who had ever opened a command line.

Both of these are very difficult things to accept. They may be even more
difficult to accept if one is extraordinarily smart/diligent and one
studies/works solely in organizations which apply brutal IQ/diligence filters
before one is granted even a scintilla of the admission committee's time.

I remember, rather vividly, the first time I figured out that an engineer
couldn't program. I was attempting to tell him where a value was being
assigned in a program. After failing to do so over email, I went over to his
desk and asked him to navigate to the file at issue. He was unable to do so. I
told him I would do it, assuming that he was unfamiliar with the directory
structure in that part of the program, and opened the file. I then said "So
you see, the assignment is made in the fooBar subroutine." He couldn't find
the fooBar subroutine. I said "It is the third method on your screen." He
couldn't find it. I said "It is this one, here, which I am pointing to with my
finger." He said "OK, that one. Where is the assignment?"

The fooBar subroutine was one statement long.

A coworker, having overheard the conversation, stopped at my desk later, and
explained to me that, if I had pressing engineering issues, coworkers X and Y
would be excellent senior systems engineers to address them to, but that Z
should be allowed to "continue to devote his full attention to work which he
is well-suited for."

The industry has many destructively untrue beliefs about hiring practices.
That there exist at least some people who are not presently capable of doing
productive engineering work is not one of these beliefs.

~~~
vonmoltke
> I am, naturally, constrained from saying "Here's a list of three of them."
> It would not be difficult.

I can't. Over my career I have worked with hundreds of engineers and
scientists who wrote code. I know zero who are in positions where they have to
write code at all, let alone as software engineers, who cannot do that.

> Both of these are very difficult things to accept. They may be even more
> difficult to accept if one is extraordinarily smart/diligent and one
> studies/works solely in organizations which apply brutal IQ/diligence
> filters before one is granted even a scintilla of the admission committee's
> time.

I spent my first 9.5 years at Raytheon, a company that is very light on the
detailed technical aspects of interviewing and very heavy on the behavioral
aspects. There are not committees, just the hiring managers and the
interviewers. You know, the system that is supposed to have companies awash in
these people who supposedly can't construct a basic for loop but can bullshit
a good game. Never met one. Not at Raytheon, or Northrop, or Lockheed, or
Boeing, or any of the other companies I worked with during that period.

Sure, most of them were what this community would disparagingly label as "9-5
engineers", but they all produced code that basically worked and provided some
value to the program they were on. Normally if there was a problem it was a
political or attitude problem, not one to technical ability.

~~~
tptacek
The Matasano hiring process (to which this article refers) was designed in
part because of this bad experience you've never had. I've seen it happen
repeatedly over my career; people who'd pass interviews and then, over 15-20
minutes of face-to-face discussion a couple weeks on the job, not be able to
comprehend the idea that a C pointer needs to point to valid memory.

That's what's so mind-blowing to me about our terrible process today. It
aggressively tries to find and dispatch unqualified candidates, so much so
that it forcefully repels talented people. And it _fails miserably_ at
screening out people who can't code! It is the worst case scenario of
processes.

It's also really important to remember that the problem is People Who Can't
Code, not "People Not Smart Enough To Code". Time and again I've "worked" with
people who could very effectively critique my own code, who could participate
in design meetings down to the bits-and-bytes layer, and, having taken
responsibility for actually implementing some portion of those designs, could
not commit usable code to save their life. I don't know what the deal with
these people is, but they are out there: plenty smart, totally fluent, and
completely ineffective.

I was talking to Erin this weekend about the phenomenon and realized that
these people not only exist, but are actually favored by the way the market
works. A smart person can last many months in a dev role before anyone
realizes they're ineffective. Then, it takes many, many more months to manage
them out of the team. By the time the story plays itself out, the bad team
member has more than a year on the job, and when they parlay that resume line
item to another prominent job elsewhere, their previous teammates aren't
outraged but instead relieved. They end up with gold-plated resumes and tons
of credibility.

~~~
cpprototypes
The software industry is broken for older engineers. Look at the typical
algo/CS heavy interview today. It favors and selects for these
characteristics:

1) Young, fresh graduates who still remember well the CS material. Or those
who have a lot of free time and can study for these interviews (for example
look at this Quora link [http://www.quora.com/How-much-time-did-you-spend-
preparing-f...](http://www.quora.com/How-much-time-did-you-spend-preparing-
for-Googles-interviews) the first reply mentions spending 28.5 hours per week
for 5 weeks, which is 142.5 hours total) From a senior software engineers
perspective that's a ridiculous commitment for something where an arrogant
asshole interviewer can shutdown a whole onsite interview process because
they're having a bad day or have some favorite question they think is the One
True Question for determining if someone is a software engineer.

2) The software industry tends to overvalue youth. It has a very high salary
at start, but also a very quick salary cap. And most companies have no
technical ladder, and even those that do it's a joke compared to the manager
ladder. All of this is not surprising. Since the industry is so heavily biased
towards hiring and rewarding youth, older experienced engineers are not
valued.

3) Senior software engineers have heavy pressure to leave the software field.
I'm feeling this now. I'm a senior at my current place and my salary is
basically capped. There would be little to no benefit going to another
company. And even if I wanted to, I have a family now and don't have the free
time to study for software interviews. My options are basically go into
management, consulting, or start a business. I have no desire to start a
business or go into consulting because I simply don't like doing those
business related things. I want to be an engineer not a business person. But
if I just stay an engineer, I will probably get laid off someday due to
ageism. And if I'm an old engineer who is laid off, job mobility is basically
gone due to ageism and the CS heavy interviews that I don't have the time or
motivation to study for. So the only safe path is management. A lot of senior
engineers face this decision. Which again reduces the number of mentors and
experienced engineers to teach the new younger engineers.

4) And doesn't anyone notice just how wrong whole concept of studying for an
interview is? There's a whole book publishing industry dedicated to technical
interviews such as Cracking the Coding Interview. The technical interview has
become like the SAT. Many could just study to pass it, but be horrible
engineers.

~~~
tptacek
Interestingly, the author of that book also wrote the top comment on the
TechCrunch story, disagreeing pretty strongly with me about hiring processes.
I got to talk to her a bit about it on Twitter:

[http://www.conweets.com/tqbf/gayle/](http://www.conweets.com/tqbf/gayle/)

(I'm having a pretty bad day, which I hope doesn't show through _too_ much in
that summary).

~~~
dpritchett
Bummer. Her career seems to be predicated on a correlation between algorithm
tests and performance. Can't expect her to seriously entertain disagreement as
long as the current model is profitable for her.

Google is no more a proof of the value of algorithm tests than Github proves
the value of manager-free organizations.

I was a bit horrified at the acquisition coaching comment. I did not realize
that happened but of course it makes sense. Can't manage an acquihire if your
devs can't pass the algorithm tests at the big acquirers. Shame.

~~~
gaylemcd
Your assumptions are false.

It is actually _more_ profitable for me if I say that these algorithm tests
are BS and completely study-able, and even the worst engineer can pass them.
That easily translates into "here! buy my book and even YOU can get a job at
Google!"

It's actually a much harder sell when, really, it's more like studying helps
someone perform better, but only to an extent.

Oh, and the acquirers _encourage_ studying and prep, just as most of the top
tech companies do for their normal dev (and non-dev) candidates.

To be clear: my experience is that the algorithm interviews, when done
properly, work reasonably well to identify intelligence/problem solving and
coding skills. Those are more important at some places than others. They can
work well for _certain_ places -- but not at all. I do not think that _all_
companies should use this process. It's not right for all places, but it's
reasonably good for some.

As for Google being proof of the value of algorithm test: I think you're
pulling that from a twitter conversation very much out of context.

Context: Some people were arguing that the algorithm interviews offer _zero_
value - that you'd be at least as well off, if not better off, hiring at
random.

If they truly believe that (and they appeared to be sticking to this
argument), then it's absolutely relevant that not just Google, but basically
all the top tech companies, use this hiring process. Could a randomly selected
group of engineers build the technology at companies like Google, Facebook,
Amazon, etc? I suppose that's what they must believe, and I find that pretty
absurd.

 _If_ they had argued that these interviews sort of work, but aren't nearly as
good as some other interview processes, then you're right that the company
about Google and other companies wouldn't be relevant. And I also wouldn't
have brought it up.

~~~
andrewprock
"To be clear: my experience is that the algorithm interviews, when done
properly, work reasonably well to identify intelligence/problem solving and
coding skills."

Given that there is no correlation between job performance and interview
score, are you saying this based on your gut instinct, or do you have
objective data somewhere?

My best estimation is that the Google interview process is just a glorified
fizzbuzz presentation, and that the hiring decisions are more or less made by
arbitrary factors, including the nebulous "culture fit".

While it may be amusing to work through the details of doing a merge sort on a
linked list in 30 minutes, it's certainly not germaine to the quotidian
experience of an SWE at Google.

~~~
gaylemcd
>> Given that there is no correlation between job performance and interview
score, are you saying this based on your gut instinct, or do you have
objective data somewhere?

That's not a correct assumption. I suspect that you are referring to the
(infamous) Google studies on this that were alleged to show this. The articles
about this got many details wrong, and the study was fundamentally flawed.
Remember: they only studied the people who did very well. That's like finding
no link between exercise and health when you only study people who run regular
marathons.

Merge sort on a linked list is a bad interview question, so I agree with you
there. Good questions are problem that actually make you design a new
algorithm.

~~~
andrewprock
It may be that the studies were flawed, and that the reporting was bad, but
that flavor of study has been replicated in other venues besides Google. Given
that, it essentially comes down to culture being the deciding factor in these
interviews. Given the stark cultural skew at Google, it's possible that the
pseudo-analytic SWE interview is actually masking systematic bias in the
hiring process.

------
MCRed
I've gotten interviewed by people who thought they were great but didn't know
what they were doing. And I mean for serious companies like Pebble. 22 year
olds who can't even properly phrase interview questions.

Whose the terrible engineer? Me with a patent and 25 years of innovation in
key major products like the playstation network? Or the guy who interviewed me
who gave me a thumbs down for being "terrible"? Or maybe it was just cause I
have grey hair in my beard?

I see a lot of attitude about how there are "bad engineers" that seems to come
from younger people who are very ... proud ... of their skills, but are more
bluster than brains in my opinion.

I don't think they're terrible- I think they have potential. But they have the
wrong attitude.

~~~
angersock
_" 25 years of innovation in key major products like the playstation
network?"_

So, I'm going to have to come off as the punk-nosed kid here, but I've gotta
ask: What does that mean? That literally read like biztalk.

What algorithms did you develop? What code did you write? What systems did you
architect? How did you make design tradeoffs?

I can't tell a "stakeholder" who did real engineering work apart from a
"stakeholder" who got their name attached to the patent for political reasons.

~~~
001sky
Lets say the dude invented something important? are you to have a better
follow up question?

If your point is that they commenter is delusional, and at once over-
estimating himself and under-estimating others, you should come up with a
better way communicating it.

A _proper_ punk-nosed-kid would certainly be more clever.

~~~
d23
He asked some pretty straightforward questions, like what the poster's
concrete contributions to the project were.

~~~
001sky
It adds nothing to the discussion. If the guy did something major (case#1),
the discussion is over. It just makes the person asking the question look like
an ass.

The other issue is that anyone who would have a reply of that caliber most
likely wouldn't reply...why bother...? Thats the (#2) second case. Again, the
discussion is over.

The third best case is that the guy is bluffing, and doesn't bother to answer
the question. This is case (#3) but isn't really any different in motivating
the discussion than case #2. Game theory says the bluff plays to look like the
win, right? So just don't answer (and mimic #2).

So there are no rational replies to this question.

As an interrogation-style question its a failure.

------
mkozlows
It's notable, and obvious, that this guy has never actually tried to hire a
developer. He has the luxury of thinking that these "secretly terrible" people
are rare and misjudged. He's wrong, though.

(That's not to say that industry standard interviewing techniques are perfect
-- they're definitely not, and they're often awful -- but "lots of
professional programmers simply flat-out can't program" is a true fact, and a
hiring process needs to deal with that reality.)

~~~
FLUX-YOU
>simply flat-out can't program

This phrase is seriously abused and it needs to stop because our field has
anything but standardized and well-known competencies that we expect people to
know before they commit anything.

Compiling main() with an assignment and a print is technically programming,
but has extremely little to do with what is actually being developed in real
products. You aren't going to give anyone a job if this is all they can do. As
soon as you get out of the absolute basics (IMO, if/for/assignment/operators),
your demands are simply arbitrary with what you think will indicate that
someone can do the job.

You might only consider someone who can pass FizzBuzz as a 'real programmer'.
Someone else might only consider someone who knows and can implement advanced
patterns and quickly absorb an unfamiliar API as a 'real programmer'.
Programming-Genius-32 might only think someone's a 'real programmer' when he
can implement every algorithm from MIT's curriculum from scratch.

And if I had to make a wild guess, I would guess that people create their own
standards of what a 'real programmer' is based on things they have already
solved or things they read from someone else. Then they go make hiring
decisions based on this standard. It is very likely that someone can look down
on many of us and call us fake programmers because they're just so much
further ahead.

Convincing someone that you are a real programmer of a certain skill level is
a social exercise, not a technical one.

~~~
mkozlows
No, I mean it literally, as in can't do do a loop/if/assignment level
operation. ("Write a function that returns the sum of the two largest numbers
in an array" is the literal question I would ask that the majority of
candidates -- all with years of experience doing software dev -- were unable
to answer.)

They simply flat-out could not program. Full stop.

~~~
FLUX-YOU
And if I did this in your interview, how would you feel about that?

    
    
        List<int> blah = new List<int> { 3, 8, 2, 1, 5, 9, 0, 12, 14 };
        // pretend I don't know the numbers :)
    
        blah.Sort();
        blah.Reverse();
    
        return blah[0] + blah[1];

~~~
mkozlows
Congratulations, you are now better than 2/3 of applicants I saw.

I'd follow up by asking whether there's another way you could have done this
(the obvious loop and store method); if you didn't come up with it, I'd
explain it to you, paying attention to how well you seemed to understand it.
I'd go on to ask about what characteristics make one of those solutions better
than the other, hoping you'll mention the performance characteristics of sort
vs. simple iteration, and maybe also the maintainability/extensibility of the
two methods.

And then I'd move on to my next question with cautious hope.

~~~
ryandrake
2/3 is generous. That implementation probably puts you in the top-90% of
candidates that make it to a technical interview.

~~~
madcaptenor
You mean the top 10%?

------
et2o
> doctors are asked trivial questions just a handful of times in their careers
> during their bar examinations and boards.

This is incredibly inaccurate. Physicians have to take a series of
comprehensive, extremely difficult licensing exams just to graduate medical
school and get a residency. Then, to be board certified, you have to take and
pass comprehensive and expensive board exams in your specialty every couple of
years, depending upon the specialty. Furthermore, they keep increasing the
frequency of the required examinations. Doctors take tests to prove their
knowledge their entire careers.

~~~
gfodor
You are too polite. Where I come from, we call this "a pile of horse shit."

~~~
et2o
You said it, not me :-)

------
morgante
It's painfully obvious that the author has never tried to hire developers and,
in fact, has never worked on an engineering team.

This line, in particular, is blatantly false:

> In all my years immersed in the tech industry, I have never once heard a
> firm talk about the idiots lurking in their own offices.

Firms might not talk about it (nobody wants to say they have bad employees).
But people certainly will. Nearly every developer I know has horror stories of
working with incompetent colleagues who literally couldn't program. And there
are even more incompetent churning out job applications—FizzBuzz exists for a
reason.

So it's clear to me that we need some sort of clear technical test before
hiring people. But I also think FizzBuzz could be sufficient for that test.
There's no need to administer an algorithms exam if all you're trying to do is
find out if someone is an incompetent engineer or not (there are plenty of
competent engineers, including myself, who would have trouble writing a trie
on the spot).

------
neaanopri
This article is juxtaposing our fear of hiring an incompetent developer, vs.
our indifference to the skills of developers once they join our organization.
That's what he's saying when he says that everyone's afraid of secretly
terrible engineers.

If each company spent a (comparatively miniscule) amount of resources on
consistently training their current developers, then the team would be
constantly improving.

We think that miraculously, good developers become good, sometimes by
heroically hacking on their own, sometimes by going to a prestigious school,
never by practice within a big company. Then, one we hire them, their skill
level freezes. This is why it's important to hire good people.

This is the same illusion that keeps the US public school system focused on
hiring good teachers and even more focused on firing bad ones, without
focusing on improving current teachers' skills. We, as an industry, need to
focus on practice within the organizations we control, we need to focus on
making everyone better, and we need to kill with fire the idea that hiring
good people is all you have to do to have a good team.

~~~
XorNot
This is also the same problem with the entire H1B situation and why Google,
Apple et al. have made some pretty poor justifications of the price-fixing
collusion: because they've avoided investing in on-going education to such an
an extent that the only thing they've been able to imagine for getting talent
is poaching it from other companies (leading to the on-going upwards price
war).

They could easily solve their problems if they actually wanted to train
people, and promoted those who would/could mentor more aggressively.

------
steven2012
One of my co-workers is a terrible engineer.

The thing is, he's very smart. He talks like a smart person, and he's very
knowledgeable. And he can code well, and destroyed every question when we
interviewed him. He even works long hours, to the point where he broke up with
his girlfriend.

The problem with him is that every feature he has worked on is buggy and ends
up causing more work to fix because his implementations are terrible. This is
something that doesn't come up in interview questions.

I don't understand, because he's a smart guy. But he worked on 3 features in
2014, and all of them are disasters. A year later, we still run into bugs
caused by poor implementation.

The thing that really boggles my mind is that people don't realize it, and
think he's a guru. Even in a company filled with people that I think are
smart, they can't see through his ruse and realize that for the most part, the
work he does is not good, and the decisions he makes are poor. He even got a
raise and a promotion. It's infuriating, but I guess things like this happen
all the time.

~~~
Zombieball
Cue impostor's syndrome kicking in for many HN'ers:

"Crap, do I work with this guy? Is he talking about me? Did I miss any bugs in
the code I shipped this week?"

------
lambda
I have worked with a few Secretly Terrible Engineers over the past couple of
years. One of those was hired before we had instituted any kind of
standardized technical screen, another was senior enough that we decided to
skip the technical screen (and regretted that decision later), and a third
passed the technical screen but was unable to get anything done, in large part
because he spent most of his time on Reddit and HN. That of course indicates
that passing a technical screen is not a guarantee of success, but it does
seem to be at least one good filter.

Our technical screen consists of 6 questions on a few different topics, and is
designed to probe a variety of different areas. I consider it fine if someone
fails one or two, as I don't expect someone to be strong in all areas; some
people may be really good at actually coding, but not know what big-O notation
is, or someone may be fresh out of college and so not have much hands on
experience yet but if they do well at the algorithms and data structures
questions it indicates they were paying attention and absorbing their
classwork.

But people who don't know the big-O complexity of basic operations on basic
data structures they use every day, and can't put together a coherent class
hierarchy for modelling files and directories, and don't know how to interpret
a system call that they see in a stacktrace, don't know what TCP is, and can't
write a simple program on demand with access to Google, StackOverflow, in any
language they want, using any tools they want, are definitely going to be more
work to bring up to speed than they are going to be worth. And I've talked to
people who have degrees in CS and several years worth of experience who have
failed every one of these questions.

~~~
mattmanser
Mainly because a lot of the things you just listed are incredibly stupid
requirements.

If I spent my life doing ruby sites that save basic data into a mysqldb, why
does it matter whether I use sometching that takes 100,000 operations or
10,000 ones, when the web page still opens in 0.5 vs 0.51 seconds?

Or who gives a damn about system traces when I can put echo's in a PHP page
and just view source?

Who gives a fuck about TCP when the browser abstracted that all away?

And when you say write a program, you clearly mean a console app, which again,
unless you've written one, which junior programmers may never have done
because someone else always wrote the helper & utility apps, it's pretty
daunting the first time if you don't even know about main. Which suddenly
makes it pretty easy. Imagine asking a front end developer to make a console
app in their interview.

You do a particular type of programming. You seem to want to judge everyone
else by your niche without understanding that a lot of the skills you list as
essential are actually almost completely irrelevant to huge swathes of
programmers. And they haven't learnt about them, because they don't need them.

~~~
ac2u
They're really really not stupid requirements.

The poster you're replying to isn't narrowing to a niche, he/she is simply
trying to catch a red flag. You're right to be concerned that there are many
interviewers who will climb way down the ladder of abstraction to their own
particular niche and then crucify a candidate. But this isn't one of them. The
poster even explained that it was only really a negative if all were wrong. I
use a similar process as a quick pre screen.

Sailing through all questions allows us to proceed at a relaxed pace. Having
nothing to say for one or two questions tells me nothing (it could easily be a
fault of my question rather than the candidate). But no coherent answer to any
question? Red flag.

~~~
lambda
Exactly. I've had several candidates that I have passed who on the TCP
question have said "I don't know, networking is not my strong point." That's
great! Knowing when you don't know something and should just move in is a real
strength.

As long as someone does fine on most of the rest of the questions, having one
or two gaps in knowledge is not a problem, I can tell from the other questions
that they'll be able to pick it up if they need it, or ask for help when they
need it.

------
cornellwright
I think one thing the author fails to realize is how much worse it is to hire
a terrible engineer than not hire a good engineer. I've seen a terrible hire
cause more than $1M of damage in the year it took for him to get fired.

While I think that these sorts of people are rather rare within the population
of engineers at large, they appear much more often in the interview process as
they are more likely to need a job, and probably have to interview many more
times before they find their way into a company.

That said, I do agree with the author that extremely deep technical interviews
are also unreasonable. Variants of FizzBuzz are generally enough to weed out
the terrible engineers and it's pretty hard to tell the good from the great
until you've actually worked together.

~~~
vonmoltke
> I've seen a terrible hire cause more than $1M of damage in the year it took
> for him to get fired.

As I have said in these discussions before, that sounds like a process
problem. What does it say about the competency of management and the maturity
of processes if it took a year to figure this out? I don't think you can lay
most, let alone all, of the blame on the engineer and the hiring decision.

~~~
cornellwright
It took a year for management to figure it out. It took much less time for his
coworkers to figure it out. You're definitely right. "Blame" for the damage
done falls mainly on management inaction.

I definitely learned a ton from that job.

------
kragen
I’ve worked with secretly terrible engineers. I’ve seen _lots_ of code samples
submitted by secretly terrible engineers. I’ve been told that putting asserts
in the code is bad practice because it means that the code is making
assumptions, and I’ve seen my co-workers exult because they were successfully
able to change the simple implementation of an interface without having to
change the client code. I’ve heard software project managers claim they’d
never seen a project fail for technical reasons, and I’ve seen them openly
promoting waterfall development. And if you look at the kind of abysmal
nonsense that fills sites like w3schools and developerWorks, not to mention
the questions on StackExchange, it’s obvious that there’s such a huge volume
of Openly Terrible Engineers out there that they frequently don’t know _any_
reasonably good engineers _at all_.

I’ve also had the privilege of working with a lot of really super awesome
people. They didn’t work at the same companies as the total incompetents, for
the most part. And they weren’t all geniuses. A lot of them were just regular
schmoes who worked every day to get a little bit better.

In almost 20 years in the field, I’ve also actually _been_ the “secretly
terrible engineer” — although I’ve been pretty successful in most of my jobs,
I’ve also had a couple where I just stunk.

Different people do well in different environments, and software development
is a wide enough field that it has a wide variety of environments in it.

------
analogwzrd
One solution to all of this is for the applicant to do a few things to avoid
being confused for a terrible engineer. The last time I looked for a job, more
and more companies were asking for an engineering design portfolio. Instead of
waiting for the employer to ask you to talk intelligently about things you
haven't learned yet, show up to the interview with a portfolio of things you
can discuss on a detailed level for hours on end.

I've only been working professionally for a little under 4 years, but I've
encountered a handful of terrible engineers - engineers who only know one
solution and apply it to every problem that presents itself, very smart,
technical people who know enough to hack something together and leave the
difficult, last 20% for other people to solve, etc.

Another issue, especially in larger companies, is you have to allow a bad
engineer to fail in order to justify firing them. In a fast paced environment,
sometimes you can't allow a project to fail simply to provide cause to fire an
engineer. And even after the failure, HR will require you to implement a
performance improvement plan, etc.

~~~
morgante
The problem with the portfolio approach is that many incompetent engineers can
easily point to code that they "wrote." Often it was part of a larger team
carrying them, but sometimes they wholesale copy it.

A similar problem applies to pure project interviews: the total incompetents
are also the ones most likely to get someone else to "help" them with it.

~~~
analogwzrd
Yep, there also needs to be a way to detect bat-boy syndrome (where the team
goes to the world series, but the guy you interviewed was just there to lug
the equipment around).

I've always heard that you learn more in an hour of playing(as in a sport)
with someone than you will in ten hours of conversation. I like the idea of
being paired with an engineer to solve a problem because it let's someone see
how you think, what your process is, and, most importantly, how you learn.

------
hiringcat2
I think the article starts to highlight the real issue, when it compares with
other industries, but then ducks out at the last moment. So I will try my best
to fill in:

In all industries, in all professions, there are a range of abilities for
those working within it. From the truly gifted, to the hard-working reliable
folk who mostly deliver consistently, to those who need support and guidance
to deliver well consistently, to those who deliver sometimes, to those who
frankly cannot and will not deliver despite support time and guidance.

I have met incompetent doctors, unreliable engineers, lawyers you would not
trust to compile a shopping list, and programmers you would not ask to develop
any kind of program beyond hello world.

I have also met people I could always learn from, and they too remain fixed on
the idea they too are always learning, improving, on a knowledge and
experience journey, without a fixed endpoint.

A final point - no one is truly useless, you just cannot find a good match for
their skills and experience within your team at that point in time.

------
logicallee
The article started ranting, so I stopped reading it after getting through
about two thirds of it. But one difference between software and the other
mentioned professions is that software developers can earn $140K just by
_doing_ , by performing. And they can often start soon out of high school. And
it doesn't matter where they learned it. It's about doing.

I don't know much about dance, but maybe software engineers should be compared
to dancers, and the technical interview should be compared with an audition.
Actors and dancers still audition for roles, years after they have made it.
And the audition is still as far removed from day-to-day work as a technical
interview is from the job. I guess the reason that it's done is because the
work is like a performance.

------
mockery
The article spends most of its time criticizing interview techniques that
focus on knowledge of particular facts, which is fine - I agree that's
generally not a good predictor of job success. But somehow the article
concludes that since bad interviews can exclude good candidates, there's no
such thing as a truly bad candidates.

The existence of bad interview techniques at some companies doesn't preclude
the simultaneous existence of bad candidates in the market.

Yes, good people can fall through the cracks, and otherwise-talented people
may not be good at being interviewed. Those are unfortunate realities that you
should be aware of and vigilant about if you're involved in hiring. But there
are also bad candidates out there, and they're capable of doing a huge amount
of damage (anyone who has worked on even a medium-sized engineering team can
verify this) so the ugly truth is that being conservative with hiring makes a
lot of sense.

~~~
pekk
Why is asking about particular facts considered a reliable way of finding bad
candidates?

~~~
azernik
It is not. That's the point of the comment you're replying to.

There exist _good_ interview questions, where you give lots of facts to the
candidate and make it clear that they can ask if they don't remember the order
of arguments to reduce(). (In fact, a good way to put them at ease is to admit
that _you_ don't remember either, and are just looking up the documentation
:-P )

But if, given those bare facts, they can't write a legible and correct binary
search even over multiple iterations, or reason about O() complexity of an
algorithm they either just implemented, or just _came up with_ , they are
probably an STE.

In my experience, these people fall into one of two categories: new graduates
who just barely scraped through their college classes, and people
misrepresenting their past jobs in QA or product management as programming
experience. (That isn't to say that non-CS-majors shifting into coding can't
be great engineers - I know several! But when interviewing one, you can't make
the assumption of basic competence, and it's a red flag if they play up their
non-programming work rather than talk about actual coding experience/studies.)

------
gargarplex
This is bizarre to me. Yeah, I've worked on teams with people who couldn't
ship code, and they got fired. But I'm looking for work now. Let me tell you
what it's like. There are companies who provide automated coding tests that
require you to pull out bizarre algorithms that I haven't needed in 15+ years
of shipping code and creating MM's of value for employers.

After weeks of searching, I'm finally at a second-stage interview with a
company where they intend to hand me a spec, put me in a room, and see if I
can come out a few hours later with a functioning prototype. And it's a
relief; that's a sane test. Can I produce or not?

------
davidgerard
The really horrifying thing about FizzBuzz is that it actually has useful
power as a screening tool. No, I don't know how the hell these people
accumulated years on their CV while being literally unable to even
approximately code a FizzBuzz. But they're out there.

(I suspect Joel Spolsky's theory that it's the same 100 terrible guys applying
for _all_ the jobs.)

It's the same for sysadmins, by the way. We just went through a hiring round
for a good Windows sysadmin. (Us Unix guys could all do Windows to pointy-
click level, but needed someone who knew its evil little ways when something
went _subtly_ wrong.) Holy crap, you would not believe how many clearly
useless bastards have literally twenty years as a Windows admin on their CV.
We got someone who's great (and picked up the Linux side in short order), but
it was slightly trepidatious.

~~~
leereeves
Or perhaps they have learned the solution to FizzBuzz, and simply don't code
well under stress.

~~~
rogy
FizzBuzz has to be the simplest coding exercise out there after hello world.
No matter how much pressure you feel it can't be hard to figure that out?

~~~
iopq
I believe this should cover all bases: [https://bitbucket.org/iopq/fizzbuzz-
in-rust](https://bitbucket.org/iopq/fizzbuzz-in-rust)

~~~
kibwen
Or if that fails:
[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

------
DanielBMarkham
I was talking to a team a couple of years ago. This team had a bad reputation
at the organization, and I was supposed to come help them.

So I did a day of light training. Then I offered some free books -- with the
caveat that they email or ask me for them.

Nobody asked for the books. Out of 20 folks, 2 of them bought the books
(instead of getting them for free). They didn't want the rest of the team to
know they were interested!

I firmly believe two things: 1) just about anybody can become a programmer
given the right environment, and 2) Due to social issues, teams get "out of
whack" and suck really big time. And when #2 happens, the other programmers
always blame it on technical skills.

At a recent conference, I saw a guy talk about "mob programming". Mob
programming is where you take the entire team, say 3-7 guys, and work on one
story at a time. There's one terminal. One guy is typing and everybody else is
planning and navigating.

He said it created a huge training opportunity for everybody because everybody
was involved in every little detail all at once. People got the chance to
compare notes. Poor programmers got better. Good programmers learned cool
stuff from each other.

But the really interesting part was when he described doing this _in teams
where not everybody was a programmer_. He said out of several experiments, in
every case within a few hours the noobs were picking up how to program in that
language. Within a week they were able to actively and helpfully participate
along with everybody else. It wasn't just that weak programmers got better,
_it was that most anybody could learn how to program_.

I don't think most people in the industry are ready to hear that.

------
zaroth
No question in my mind that completely inept engineers are everywhere. It's
mind numbing how many people will respond to a opening for an experienced
coder and literally cannot code in any capacity.

In a previous life we were hiring C# WinForms guys, and I would always ask to
code "Explorer". Some people couldn't get past creating the solution in Visual
Studio, others couldn't figure out how to get the directory listing at C:\,
but some got _remarkably_ far along in just an hour or so, with directly &
file listings, navigation up/down the tree, context menus, rename, copy/paste,
etc..

I never ask trick questions, I just come up with cute apps. I think my new
interview question forever henceforth will be to code and launch "Magic", I'll
be back when it's time to get lunch, and help yourself to the espresso. Write
it in whatever language you want, using whatever tools you want, on your
laptop, with a full internet connection. If you want external keyboard and
monitors, please use them.

The only rule is you can't claim someone else's solution as yours. You _can_
use Stackoverflow, or any other resource you want to build up the parts, but
you have to cite any code which carries a license.

Find a task which you can describe at 30,000 ft in 2 or 3 sentences, then
spend 5 minutes sketching out ideas (not code!) on the whiteboard of what the
components are and how they fit together. Then, probably best to leave them to
it and not stare over their shoulder making them nervous.

------
fsk
Quite a few times, after getting a technical screen, the interviewer's
attitude was "You loser! Why are you wasting my time interviewing here?" But I
know that I'm really productive and really know my stuff.

When my employer was interviewing, the two best candidates (by my analysis)
failed their technical screening.

I don't see any easy solution.

It also seems weird that employers complain of a talent shortage, but they
always are looking for every little excuse to reject someone.

------
drawkbox
You know those college groups and side projects where there was a group of
people and then only a couple or a few actually did anything and the rest
attached on for the easy layup? Yep those people end up doing the same thing
in the workplace and probably in life.

If you were the deliverer in the college group or project then you will have
the same thing in the workplace. Usually people who don't want to be doing it
at the time, they might be good but uninterested. I imagine it is extremely
unsatisfying to just sit around and not contribute. I work to create and ship,
otherwise why do it?

A bad part of this is it isn't always the shippers and doers that get the
credit or the notice either, same people like this jump up and take credit to
justify their contributions.

Some people go full Costanza.

~~~
kyllo
Ugh, you're right, and this is exactly why I _hated_ group projects in school.
4-6 people taking credit for the work of 1-2, and everyone gets the same
grade.

------
learc83
Pair the candidate with an interviewing engineer, give them an hour or two to
solve a problem as a team. The interviewer isn't an adversary; their job is to
assist the candidate like they would if they were working on a real problem.

Repeat this process if necessary.

Get everyone together and talk about past projects the candidate has worked
on. Have the interviewers evaluate the candidate, and make your decision.

You know whether the candidate can code, and you've removed the adversarial
nature and unnecessary stress from the interview process. Most importantly,
you got to see them work in a much less artificial environment that's closer
to what they'll be doing day to day.

~~~
locahost
I'd be over-the-moon thrilled to interview at a company that does this. Any
recommendations for this front-end dev in California?

------
jacques_chester
> _Lawyers and doctors are asked trivial questions just a handful of times in
> their careers during their bar examinations and boards._

I get the very real sense that this person has never sat a law exam.

A law exam is based on applying case law to a set of facts, which corresponds
to the day-to-day work of millions of lawyers. What the author calls "trivia"
is literally _the law_.

~~~
leereeves
I think trivial questions meant FizzBuzz and count the A's.

What's the legal equivalent of that?

~~~
jacques_chester
In your introductory course you might be asked what precedent is, but after
that it's cases, statutes and IRAC: Issues, Rules, Application and Conclusion.

------
habitue
I think the biggest issue with this article is that most places aren't trying
to hire people who aren't bad, they're trying to hire people that are _good_.
You might use fizzbuzz as a weed-out question, but then you have to determine
whether the person is good or not. I don't think there's a pervasive fear that
terrible engineers will accidentally be hired. There's a desire to weed those
people out and then sift through what's left for the best.

------
dkhenry
This article is incorrect from beginning to end. As a simple counterpoint to
this idea that "I have never once heard a firm talk about the idiots lurking
in their own offices"

Here is the well documented _policy_ held by major (not just tech companies
mind you) firms to fire the bottom 10% of their employees.
[http://en.wikipedia.org/wiki/Vitality_curve](http://en.wikipedia.org/wiki/Vitality_curve)

By the way a form of that is used at Microsoft and Google, probably others as
well, but the idea that Silicon Valley and Computer Programming are the only
place where people are on the look out for "Secretly Terrible Engineers" is
absurd, its just as absurd as the comments I am reading where no one has ever
worked with one of them. As a hiring manager I turn away over 95% of
candidates and even with a very selective hiring process you get people we
need to let go because they can't perform at the level I expect them to even
after passing a rigorous interview process, so to say they don't exist is
stupid, its like claiming that no one ever gets fired for not performing their
job well enough.

------
calinet6
It strikes me that in the same day (albeit one filled with hiring articles) we
get an article about the success of Greyston Bakery, which will literally hire
anyone and train and support them as much as needed to be successful—and this,
which is along similar lines but is about software development, which,
obviously, requires special individual aptitude that only a chosen few can
succeed at, and must be protected from the pretenders to the throne. /s

Somehow, it feels warm and fuzzy to support the social justice of the little
bakery that could, but when it comes to our own companies, our true colors
shine.

Continue to take the systematic approach. It is still the best way. Of course,
of course you should hire as effectively as possible, and try to have a
baseline of aptitude, but there are always going to be outliers and bad fits.
It's far more effective to optimize your system for the success of all
employees than to focus on weeding out the 'bad ones.' Sure, there will be
people that won't fit your system, but they made it through the hiring process
for some reason—figure out their true aptitude and transfer them to something
they'll be effective at.

The article may be wrong about the existence of fakes and bad
programmers—anyone who has filed through a stack of resumes knows that—but
it's right on the unreasonableness of the fear and the weight we give it.

I say it all the time to our CEO: if hiring is really a huge problem we want
to focus on, how did we get all these great people? Hm.

And if hiring is really the solution to all our problems, then, well, what do
we do with all these idiots standing around here?

Ha. That really is the question. The real problem is organizational and
systematic. Stop worrying so much about hiring, optimize your process and be
done with it, and focus on what happens afterward instead.

------
dominostars
Something getting lost in the responses here is the "stress" factor of these
interviews. When encountering a difficult architectural or algorithm decision,
experience has taught me to develop slowly, prototype often, investigate
previous work, and even step away from the issue. Meanwhile, engineering
interviews require you to code immediately, in isolation, and then be judged
on the first solution you crap out of your brain.

In a recent interview, my solution to a question was bad, I knew it was bad,
and I informed my interviewees it was bad. It was difficult for me to come up
with other solutions on the spot under pressure of judging eyes and limited
time. Immediately after getting off the phone I was able to assess better ways
to approach and solve the problem, but too late, those 45 minutes were more
important to them than my many years of provable, directly related experience.

------
bitwize
I was on the interviewer side of the developer interview equation once. This
guy came in, mid-40s, claimed to have a long and storied career designing
radar imaging systems and the like. Even claimed to have a patent to his name.

He was a fucking idiot.

We gave him our standard simple programming task, which requires a trivial
amount of quasi-low-level byte-banging in C(++). But even a fresh-out-of-
college kid who only knew Java could get it with a bit of prompting and a few
hints.

This guy came nowhere near a workable solution, but he could generate
mountains of chatter and BS about what pattern to use and such.

I had never encountered such a flagrant BS artist trying to land a developer
role wver in my life. I doubt that most "secretly terrible engineers" even
approach his level. But the experience was a teachable one.

------
neurotech1
Elon Musk's rule works pretty good for finding a "terrible engineer"

"How Elon Musk Can Tell If Job Applicants Are Lying About Their Experience"

[http://www.businessinsider.com/elon-musk-job-interview-
rule-...](http://www.businessinsider.com/elon-musk-job-interview-rule-2013-12)

------
CurtMonash
Similar issues arise in finance.

I started as a stock analyst in 1981 at a fairly elite firm (PaineWebber,
usually top 5 and always top 10 in the equity research rankings). We didn't
get computers and spreadsheets -- Visicalc! -- until I'd been there a few
months.

After a while I started publishing annual growth rates, based on formulas like
(EndValue/StartValue) ^ (1/5) - 1, formatted in percent. Multiple colleagues
asked me to teach them this amazing trick.

And by the way -- when writing this comment, I made a mistake in the formula
above until I rechecked my work. :)

------
milesf
What a terrible article! Writing code is not about good vs. bad, incompetent
vs. incompetent, great vs. garbage. It's about communication between people.

The best programmers I've known are never happy with their work. We ALL write
terrible code! Anyone who says different is lying.

Good coders are those who welcome critique, who push themselves through self-
set goals and challenges. My fav quote from Dan Kubb is "if I'm not
embarrassed by code I wrote 6 months ago, I'm not pushing myself hard enough".

~~~
ansgri
And then some day you'll have to visit a psychotherapist. Not being happy is
destructive, being happy and greedy in your happiness is not. Attain a level
of expertise where you can reliably predict task durations and then go lead a
team to teach every team member the same. Then be a CTO. Then the world will
be a calm, happy and steadily progressing place.

------
rpcope1
I think one thing that really bugs me about this article (and a lot of the
stuff coming out of the valley in general) is the unqualified use of
"engineer" when describing developers. Most software development seems to lack
the rigors of what (atleast used to) fall under the domain of engineering (EE,
ME, ChemE, etc.); I also don't think the culture is this antagonistic in other
engineering fields, especially where people are licensed as professional
engineers (ME, Civil, etc.).

------
thanatosmin
Side point: The author throughout nearly all of the article uses engineer
(without any further qualification) and programmer interchangeably. A vast
range of engineering has nothing to do with the design of software, and
engineering is not programming.

~~~
sgustard
It's an interesting point, since I don't know how much other engineering
fields are beset with this problem. The article features a photo of a
collapsed bridge, but obviously its topic is software. Do civil or aerospace
engineering firms have the same problem of incompetent coworkers who manage to
pass all their interviewing hurdles? It seems hard to imagine -- I don't know
how I'd fake the math on static and dynamic loads without actually knowing
what I was doing. Why is software so different, lacking basic shared and
provable prerequisite skills?

~~~
mgkimsal
"Why is software so different, lacking basic shared and provable prerequisite
skills?"

It shouldn't be; I think we generally don't have enough people that yet
recognize this as a Real Problem(tm), and therefore don't know how to do good
filtering/interviewing up front. I think it may be another generation or two
before there's really enough pushback to start demanding the same level of
scrutiny other industries may have.

Now, a bad doctor, lawyer, engineer, etc might slip through the cracks now and
then, but there's pretty strong proof that at one point they did Know
Something (tm) about their field, more through professional licensing than
standard higher ed, for example, but it was there.

I have so little faith in the value of most higher-ed degrees as higher-ed
seems primarily profit and ratings driven, vs capabilities driven.
Professional orgs like bar associations actually have some economic incentives
to keep people _out_ of practicing law. Universities seem to have no incentive
to fail people out, and every incentive to continue grade inflation.

~~~
omegaham
> Universities seem to have no incentive to fail people out, and every
> incentive to continue grade inflation.

Ostensibly, the idea is that if you don't weed out the idiots, you are going
to end up with people with degrees from your university who are garbage, and
this hurts your brand. You see this happening with for-profit colleges, where
grade inflation is particularly egregious. "Well, we've given a bunch of DeVry
grads a chance, and they've all done terribly. We're not going to be
considering DeVry grads anymore unless they can really, really prove that
they're any good."

This should, in turn, get back to prospective students, who won't go to a
college if it can't get them a job.

Unfortunately, you're now at three steps that are pretty opaque and difficult
to measure, and the rewards for lowering standards are immediate and vast.

~~~
mgkimsal
> You see this happening with for-profit colleges, where grade inflation is
> particularly egregious

I see it happening with people all sorts of colleges and universities. It's
gotten to the point where if/when I meet a young graduate who has good
communication and thinking skills, I consider them an anomaly, or suspect
strongly that they already had these skills before college.

------
rogy
We send out a coding test to candidates that pass a phone screening. We
provide a template file and a run file that contains tests.

I'd say 1/3 of the entries we receive (from people that have passed a semi-
technical phone screening!) return an answer along the lines of 'if input =
test1, return answer1' and another 1/3, who submit code that is also 'fakes'
the correct results, they just pad it out with a bunch of filler code to make
it look like they'd done more.

We rate each entry out of 10, its insanely frustrating how many 0's I had out.

I assume that they assume we just check the tests pass and thats that. (Do any
companies do this without checking the code? The sheer amount of people that
try suggest it must work sometimes!)

~~~
poikniok
Presumably you also have other tests that you run the code on too, that are
not sent to the candidates right? That would save some time, say if the code
passes all 10 tests sent to the person, and fails all 20 tests that you keep
for yourself, then that person's resume would go in the trashbin with little
time wasted.

------
linuxhansl
Where I work we have a "programming test". You get a simple problem, two
hours, your own laptop (or one provided to you, as you like), full access to
the internet, and a room by yourself.

The problems are doable in about 1/2 the time.

Still not quite like a real situation where you bounce ideas off other folks,
take a break and go for a walk when you're stuck, etc, but it's closer than
the whiteboard coding nonesense.

But I have seen folks coming highly recommended with "architect potential",
"top of the heap", etc, who turn out to be 100% useless. And I mean useless as
in "it's more work overall when they work on something than if they wouldn't
have worked on it in the first place".

~~~
Luyt
> I have seen folks coming highly recommended

Who did recommend those useless candidates to you? A recruiter, perhaps? Read
this horror story: [http://bostik.iki.fi/aivoituksia/pages/recruiter-
anxiety.htm...](http://bostik.iki.fi/aivoituksia/pages/recruiter-anxiety.html)

 _The good developers generally have no trouble finding jobs, and therefore
don 't need recruiters' help. With the best and the brightest taken off the
pool, the recruiters are mostly left with merely the mediocre and the bad
ones. This in turn has collateral effects: any developer coming in via a
recruiter already carries the stigma of "not good enough to find job on their
own"._

------
ChainsawSurgery
> Lawyers and doctors are asked trivial questions just a handful of times in
> their careers during their bar examinations and boards.

Of course, this obviously means there are examinations and governing boards
that certify laywers and doctors as fit to practice. I doubt most people in
the industry would prefer that we start moving towards that.

Or maybe not. I dunno. Those of us who went through traditional CS programs
would certainly benefit from such a system greatly. But the lack of formal
entry barriers is part of what makes the industry fantastic, and perhaps the
very fluid and sometimes irritating interview process is just part of keeping
those entry barriers away from tech.

~~~
straws
Ah, but what about Official Scrum Master Certification panels?

------
bsdpython
I've been seeing the same basic topic come to the top of hacker news over and
over. I thought the with the advent of GitHub, Stack Overflow and easily
sharable web and app projects that this would make vetting software developers
easier. Are these resources not being utilized at all in the hiring process?
Am I to believe that a software developer with several years of professional
experience, references, and some sort of work portfolio can't code at all? I
don't get it.

~~~
mkozlows
Many, many dev candidates do not have a Github account with any code on it,
nor do they have an SO account with any answers on it. And past work often
belongs to the employer (and was written by a team anyway), so.

If you want to say "don't hire those people," you're being far more
restrictive than those who want to do fizzbuzz-style weed outs.

~~~
ashark
Github-centric candidate filtering is _great_ for the tiny percentage of
programmers who get paid to work on open source, and _terrible_ for the much
larger percentage who can't write open source code _even on their own time_
without risking a lawsuit from their employer. Only way to fix that's
unionization or getting an awful lot of laws passed in a an awful lot of
states (for US devs, anyway), thanks to employer/employee power imbalances and
incentives to defect from any strictly voluntary resistance movement.

~~~
gaadd33
Wow most programmers aren't allowed to have any sort of hobby involving
programming without risking a lawsuit from their employer? That seems pretty
crazy, I'm surprised places like California permit that.

Any ideas what companies tend to have such onerous conditions in their
employment contracts? I've never seen something similar but I've only ever
worked for smaller (less than 500 people) companies.

~~~
walshemj
It's the default state in English and American Labour law hint on one of the
key legal acts is named "Masters and Servants Acts"

And this is from some one I worked with was a GC and a lawyer.

~~~
gaadd33
That doesn't seem right, at least in America. All companies I've worked for
have required me to sign an agreement giving them ownership over any work or
inventions produced using their technology or on their time.

If that was the default state why would everyone require those too?

~~~
walshemj
Lawyers covering their asses mostly and it also makes it much harder to try
and fight any disputes.

America is a tiny bit more liberal than the UK but of course most people can't
afford the lawyers to dispute.

------
stcredzero
_We need to move beyond the algorithm bravado to engage more fundamentally
with the craft. If people are wired for engineering logic and have programmed
in some capacity in the past, they almost certainly can get up to speed in any
other part of the field. Let them learn, or even better, help them learn._

What you want are people who are able to perceive the functioning of the
entire group, and act in ways that optimize _that_. Bands of highly talented
musical savants that don't like each other and don't "gel" can still sound
worse than a group of friends with "pretty good" talent who have become really
good at playing with each other.

After having interviewed and taught, I now realize that interviewing and
teaching are involved and deep disciplines, that take significant insight in
order to do them well. (Including some personal insight.) Most programmers
haven't been concentrating in the areas that would make them good at either.
In fact, my experience suggests to me that a great many programmers use the
occasions of teaching and interviewing to vent aggression against "the
stupids" of this world.

------
alanh
I'll pile in here to note that I worked with someone back in in junior year of
college on a group project. This person insisted that our entire project
(which was quite large) needed exactly four classes as we identified four
types of users for our classes. "J., we also discussed how Smith over here was
going to build a database access layer, which means at least one more class.
What you are saying does not make any sense." He refused to see reason. Not
only did he graduate, but he is now overseeing a team of engineers at a
corporation where he was first an engineer for 3 years. I pity them.

I also worked with an individual who could not code to save his life and had
to "work with" (read: copy) a friend to complete even the simplest
assignments. This person went on to work for a major US financial institution.
In fairness, he only works in IT, but I am sure his software incompetencies
can't be good for the company.

------
mncolinlee
Most fields have reached the right conclusion. Colleges do not adequately
prepare candidates for work. If tech employers never train or improve their
employees and the employees don't take responsibility outside of work, then
it's possible for starting programmers to be passed from job to job without
ever learning core concepts.

There needs to be an understanding that a Computer Science degree often does
not teach job skills and that addressing the problem early with extra reading
or training is critical. There is a tendency for people to start CS majors who
have no abilities or interest in the subject other than liking the money
involved.

When I was in college, I took CS electives as an English major undergrad and
routinely had CS graduate students attempting to cheat off of me during exams.
Anecdotally, a lot of tech leads seem dumbfounded by the results of
programming candidates with CS versus unrelated degrees.

~~~
TazeTSchnitzel
> Anecdotally, a lot of tech leads seem dumbfounded by the results of
> programming candidates with CS versus unrelated degrees.

Are you saying people with degrees other than CS tend to be better
programmers?

------
optimusclimb
I think that article makes a number of faulty assumptions, but one stuck out
to me:

>We need to start with the assumption that engineers are smart learners eager
to know more about their craft

I have encountered many people in the field that do not support this
assumption. Code reviews for these people always end up with them defensive -
you will see a lot of remarks along the lines of, "isn't it good enough
though?", "it works with the one input I tried", "yeah that would be better
but that would require me to do more work to change something, vs just hit
merge on the pull request", etc.

You can try and help improve their workflow, give tips, point out faster or
better ways of doing something, only to come by to help them 2 weeks later and
see them still stubbornly doing something the slow way.

They treat code they don't write as a black box, or "owned" by the person that
wrote it. You will encounter, "Hey, I was having a problem with X, and I
traced it down to this function in the Foo subsystem. I think I heard you
wrote the Foo subsystem. Could you take a look at this?" When you try to help,
you realize they navigated to this point and then didn't spend 1 minute trying
to read the code and see what's going on. You might take time and give a good
overview of it, how it works, offer to answer further questions, etc. It goes
in one ear, out the other. Three days later the exact same question comes up.

I've seen a programmer get thrust into the node.js world without prior
experience. I offered a few suggestions for learning resources, and offered to
loan a book. He said, "Yeah, I really try not to read books like that or spend
that kinda time outside the office. I'll figure it out."

I could go on and on with anecdotes, but I think the reality is there are
people who are very into the craft, and WILL be quick learners (of that which
they don't already know), and there are plenty that don't. For those of us
that do strive to improve and get better, working with the former is a
terrible demotivator.

A step further, I think that the former group will slowly attribute to
technical debt, or just over time make your code base harder to work with. You
can't micromanage forever, and having to harp on the same things time and time
again in code reviews is draining for both parties. Eventually you start
giving in, and letting sub-standard work through, because to do otherwise will
make you seem like a nagger, nit-picker, etc. Then one day you have to edit
something they touched, and your own task takes 10 times longer due to tons of
coupling, faulty assumptions, things they didn't bother to learn about how the
overall component works, etc.

The "hazing" style of interview surely does suck, and I myself don't go for
standard library trivia, or ask algorithm questions that would never come up
on the job. But more and more, I feel that they are used throughout the valley
for lack of a better way to defend against someone joining the team that's
going to be a net negative. I think the thought might be that it's extremely
hard to detect the person that can't be bothered to read through the code
base, and figure out how things work a little before giving up and asking
someone else to hold there hand - yet if one can make it through one of these
tough interviews, there's a higher chance they aren't that person.

Another aspect is that I feel like once people get IN in tech, few companies
are willing to make corrections. Someone can consistently write bugs, or
submit code to the repo it was clear they didn't even test against the base
cases of input/usage, give estimates that are WAY long for simple tasks, not
pay attention in meetings, etc - but many companies are afraid to fire, or
give harsh feedback. From what I've read, Netflix is one company that does not
seem to operate this way.

Perhaps we'd all be more trusting in our interviews if we didn't know that the
false positive would be so hard to correct.

~~~
angersock
_When you try to help, you realize they navigated to this point and then didn
't spend 1 minute trying to read the code and see what's going on._

I'll take the other side here...

I track my problem to a particular part of a submodule. The person that owns
it didn't document it well, didn't write an overview of how the thing works,
and generally has made "just reading the code" a poor and error-prone
substitute for asking them directly about context they've chosen not to share
with anyone else.

The person becomes annoyed at my continued questioning instead of "reading the
code", and eventually complains about my lack of motivation. The code,
meanwhile, never gets fixed, and is a ticking timebomb of technical debt.

Whose fault is this? Mine for not "reading the code" and breaking
encapsulation, and changing my code to match undocumented behavior? Or the
other person's, for failing to behave professionally like an engineer and
identify that they are knowledge-hoarding?

Who's to say, really. It doesn't matter...I've got another gig lined up.

~~~
optimusclimb
I think what you described exists, it's just not what I was referring to.
Quite the opposite, I've seen this happen when there WAS very clear
documentation, possibly a link to a wiki or readme file in a comment that
points to an overview, and yet the person clearly hadn't bothered to read any
of it.

------
barrkel
There is a large pool of incompetent developers going from one job interview
to another. Finding the decent developers amongst this herd is painful.

It's not that there are loads of awful developers lurking in companies
(although there are a few). It's that awful developers pollute the waters when
hiring.

------
henrik_w
Sure, you can ask companies to give their new hires books to read and pointers
on what to learn. However, it's even better if the new hires _already_ read
books to improve their craft. On their own initiative. There is still plenty
of stuff to learn when you start at a new place, the new codebase for example
(and possible the domain). So it is good if you are already up to speed on the
programming part.

This is an example of the three dimensions of programmer knowledge:
Programming, Domain and Codebase. I recently wrote more about this in
"Programmer Knowledge" here: [http://henrikwarne.com/2014/12/15/programmer-
knowledge/](http://henrikwarne.com/2014/12/15/programmer-knowledge/)

------
ap22213
It's probably a systematic issue with how programming work is paid for. There
are lots of 'software companies', but there are orders of magnitude more
contracting and consulting and IT companies - companies that charge work based
on what some sales guy can get through the front door. After that point, it's
about filling in seats with whomever can charge the most.

Software companies need people who can code, as well as do other things. Other
types of companies that do 'IT' need people who can look good in a seat. This
causes lots of incompetent people to get jobs for many years.

------
obi1one
The idea that there are lots of great engineers out there who just need
mentoring and guidance to excel sounds great, but the reality of the industry
seems to be that people dont stay in one place very long.

I think there is an opportunity there, but you would need to use contracts or
something to make sure the time and effort you are putting into making this
person great isnt just a gift you are giving to the company they move to next
year. Also, I dont think startups are at all well placed to do this, given
their time pressures. Google, Apple and Facebook could totally be doing this
though.

------
memracom
I think it is far more useful to build a process for software engineering that
continually reviews itself and makes things better. A fizzBuzz test is useful
to figure out how a person approaches a coding problem and something like that
should be part of hiring new developers, but most whiteboard interviews take
the whole thing way too far and approach it as an exam that you have to pass.

Fact is that everyone has their 10X moments and their doldrums. Only by
working on processes and team building, can you create an environment that
lifts your engineers to the 10X level more often.

------
gcr
I read this article, and I think to myself: "My goodness. This sounds just
like graduate school."

In CS grad school, impostor syndrome is everywhere. Nobody talks about it.
Everyone -- from the professors to the masters students -- is _strongly_
affected by it.

The more you advance, the more taboo it is to talk about it, even though it
doesn't go away. I understand the successful people just "get used to it"
after a while.

Or maybe it's just me. If it is, wouldn't that be a certain kind of delicious
irony?

------
frou_dh
For starters we shouldn't be allowed to run around calling ourselves
"Engineers" just because we feel like it.

Secretly Terrible Doctor exposed: Not actually a Doctor!

------
gnicholas
> Lawyers and doctors are asked trivial questions just a handful of times in
> their careers during their bar examinations and boards.

True, but they are also asked lots of tough questions when they go to
interview for jobs. It's not like you walk into a law firm, say "I passed the
bar", and they hire you. Comparing the legal/medical licensing requirements to
the software engineer interview process is apples-and-oranges.

------
yoklov
I'm not sure I've ever interviewed anybody who can't program _at all_ , but a
large number of people I interview are shockingly bad.

My go-to question to detect this is to remove the odd numbers from a dynamic
array of integers in-place, in their language of choice.

The ideal candidate writes an O(n) function, a less ideal (but still good)
candidate writes an O(n^2) function, and if they're struggling I say that they
can return copy of the array with the odds removed (this is worse, but they
could easily make up for it later).

Not only can most candidates not do any of these, but most _don 't even know
how to tell if a number is odd_. I had one suggest that maybe he needed a loop
(I don't know what he was planning, because immediately I told him he didn't
need a loop to know if a number is odd).

This is for a game programming position, and most of these are people who have
(or claim to have) programmed games. Every game has a loop like this
somewhere. Most have many! I feel like all I do is iterate over arrays and
remove things from them, and yet, this is one of those questions that over 95%
of people don't get. It boggles my mind.

~~~
poikniok
How is making a returning a new dynamic array worse than doing a O(n^2)
implementation? The former would be perfectly fine in production, the slight
increase in memory use is negligible, the n^2 solution would lead to me
wanting to fire said person.

Edit:

In addition if the O(n) in place solution that I am thinking of is the same as
what you are thinking of, the downside is that the remaining even elements do
not remain in the same order. So overall it is hard to imagine ever wanting to
use this solution over the standard create new array with just the even
elements.

~~~
Klockan
You can easily make an O(n) solution without reordering them by using two
pointers; one to read numbers and the other to keep track of where to put the
next even number.

------
skybrian
I can think of one that I worked with briefly, but not at my current company.

Ten years ago, today's interviewing style wasn't standard and we saw them
more. They seem pretty rare today, so perhaps we should be focusing on other
problems in the interview process rather than fighting the last war?

------
sidcool
Reminds me of another article:

Do Tech employers want too much from Candidates?

[http://news.dice.com/2015/03/09/do-employers-want-too-
much-f...](http://news.dice.com/2015/03/09/do-employers-want-too-much-from-
candidates/)

------
hnnewguy
Some percentage of the population are incompetent, so they end up in _every_
business in _every_ field, _everywhere_ on the planet. In other words, it's
reality. Why does it still surprise people?

------
mark-r
This needs to be highlighted:

> “We expect every employee to be ready on day one.” What a scary proposition!
> Even McDonalds doesn’t expect its burger flippers to be ready from day one.

There's no other explanation for the buzzword bingo.

------
alexnewman
Rather than working against the interviewer I work with them. Rather than
picking a pitiful problem I pick real ones. The only way to know who you want
to work with is to work with them.

------
rapidally2
Engineers have engineering degrees. Programmers are programmers. I have gone
to school for, and worked as, both. They are two different worlds.

~~~
dekhn
More succinctly: there should be no term "software engineer", unless people
need certifications to become them, and face legal consequences when their
engineering product breaks and kills people.

~~~
Luyt
Okay, but real engineers can rely on the quality of their building materials,
like mortar, brick, concrete and iron, with constant quality through decades
or even hundreds of years.

Contrast that with the building blocks the 'software engineer' has to work
with. Microsoft might upgrade some DLLs your product depends on, overnight.
Will your product still work? Your application probably relies on components
written by others. Are they infallible? Can you even inspect the components
for defects?

I sometimes have the idea that software is built upon quicksand, and the
building blocks can and probably will change before the project is completed.

~~~
dekhn
I don't think real engineers can rely on the quality of their building
materials. They do calculations to specify what quality of building materials
and assembly is sufficient to surpass a safety threshold, then contractors use
the specs are used to procure materials and assemble to meet the threshold.

Real problems occur when an engineers specifies a particular quality and lower
quality is used. Or the engineer designs for a set of conditions, and that set
is exceeded.

------
joeyspn
I wonder what this guy would have thought about Dustin Moskovitz when he was
learning to code while launching FB in the early days...

------
jorgecastillo
I think technical interviews will be obsolete in the future, your technical
competence will be evaluated with GitHub or other public projects. So the
interviews will be only about culture fit. I don't know if I will ever be in a
position to hire anyone or even if I'll ever work as a programmer, but this is
how I would interview. Send me a link to your GitHub, if I like what I see, I
want to know if we would get along well, if we do your hired.

~~~
joesmo
You're effectively eliminating 99% of your potential candidates then, as most
developers do not do public open source work, including many talented ones. I
can't imagine any sane company doing this, yet there are some that do indeed.

~~~
walshemj
And in Anglo Saxon legal system code you do at work belongs to your employer
and so possibly does anything related to your job you do out of work.

I would be breaking my contact with my employer if at an interview I showed
you for example the Ml code I wrote to optimise our clients Ad words
Campaigns.

------
Firegarden
My heart goes out to the author and is someone I will dub the "Harvey Milk" of
the computer software industry.

------
sidcool
Honestly, I did not get the gist of the article. I am combing through the
comments to understand more.

------
morninj
In no way is it true that the CA bar exam is an exercise in "trivial
questions."

------
LargeCompanies
There's too many egos, creative flakes and the alike for this to be ever
called a stable work environment/career. Especially in the agency world!

Just speaking from my experiences, where I was given trials and then told I
rock, then many months later being let go because we no longer clicked and or
my side projects hurt their egos.

For me this field and my side projects has been soul crushing!

 __* Loved if developers /designers could be apart of a union, one that
provided a shield from all the bullcrap noted above. Thus, providing better
job security and life/work balance.

------
michaelochurch
There are two separate points here. One is the false-positive problem: people
whose social skills and connections get them a series of good jobs despite a
lack of merit. And even in companies like Google those people can make $500k
and up if they become managers, PMs, or non-programming celebrity engineers
whose code sucks but who are good at making executive types (who value
confidence over ability, because they can judge the former) listen to them.
The other problem raised is the false-negative rate that comes from finicky
and stressful (for some; I always liked hard technical interviews) interview
tactics, due to our internalized low status.

These problems may be related but they're superficially opposite and this
should probably be two separate essays. One about our industry's severe false
positive problem (especially in management and PM roles) and another about why
our extreme but mostly cosmetic selectivity (doesn't know MongoDB? Worked at
Oracle? Forty-seven? No hire!) is so stupidly ineffective.

------
joesmo
"If people are wired for engineering logic and have programmed in some
capacity in the past, they almost certainly can get up to speed in any other
part of the field. Let them learn, or even better, help them learn."

I couldn't agree more with this and the article in general. So many people who
have the capacity and potential to continue to be good engineers are
overlooked because they don't know a specific framework or language or because
they worked with unpopular tools in the past. It seems to be a trend to do
absolutely zero training these days and expect the engineer to not only learn
on his own, but to teach himself outside of the job. Some companies even
expect extensive open source work from candidates while at the same time
requiring incredibly long hours. The idea that candidates might be doing
other, non-programming things outside of work, want time to do those, and
might not be interested in pursuing their craft 24/7 is looked down upon. I
can't think of a single profession that's so demanding.

The irony is that most jobs in the field are incredibly easy for someone who
is even moderately skilled and hardly ever use the skills being tested for.
When these things are eventually needed, all that one needs to do is a bit of
research to come up with a good solution, but somehow this is looked down
upon. Most programming jobs and professions that do not require knowing how to
build algorithms, jobs in which if you're writing search algorithms or any
other kind you're simply doing it wrong and wasting time. Why would we expect
all programmers to know how to write certain algorithms or solve certain
unfamiliar problems off the top of their head when that isn't what they've
focused on in years, if ever? You wouldn't expect a cardiologist to be an
expert in neurology, yet many software companies are really only seeking the
equivalent of neurology experts when they actually need a variety of
expertise. Sure, a general background is good, and most good developers will
have a broad understanding of many topics, but expecting a deep understanding
of every topic is simply ridiculous. The companies with such expectations end
up hiring the same type of expert while ignoring a ton of talent.

Let's not forget that in the end, this is a job. Despite all the rhetoric
about loving the work and other such nonsense, 99% of programming positions
are just another job that no one would do if they didn't pay well. It's not in
the workers' best interests to be emotionally invested in their work as this
only benefits the employer to the detriment of the employee. Thus, most things
will still be learned on the job, either with the support of or more commonly,
in spite of the employer. People work the job because they want to provide for
themselves and their family. If the job is enjoyable, it's mutually
beneficial, but that's not something that can generally be expected. Yet many
employers expect employees to both love their job and love the profession
enough to put in a ton of additional time outside of work learning and coding
for free because they are too cheap to provide proper training and their
working conditions are generally to abysmal for them to retain workers long-
term.

The solution here is to hire people with a good general background and invest
in their education on the job. To do so, employers need to find people who can
actually see the potential in others and who know how to interview, not people
whose idea of a good interview is asking whiteboard questions and insisting
the candidates talk them through the problem instead of letting them think it
through and actually solve it. This requires employers to actually respect
employees once they are hired so they can be retained long-term and their
training is worth the investment. This would be an even bigger change than
changing the interview process. Employers would have to stop asking employees
to work for free (salaried overtime). They would have to stop being childish
themselves and literally yell at or threaten employees. Employers would have
to afford their employees basic human respect, something that is severely
lacking in technology companies, especially in Silicon Valley. Those changes
would indeed be radical, and employers who implement them quickly find out
what the rest of us have known for years: there is no shortage of talent or
good engineers.

------
idibidiart
If you hire someone and they can't code then you're the first person who
should lose their job. Sorry to say.

------
ExpiredLink
> _In all my years immersed in the tech industry, I have never once heard a
> firm talk about the idiots lurking in their own offices. They always seem to
> be elsewhere. For everyone._

When you point one finger, there are three fingers pointing back to you. Hey
author, _you_ are on of them!

