
On Secretly Terrible (Old) Engineers - leothekim
http://techcrunch.com/2015/03/15/gray-beards/
======
tptacek
The basic thesis as I read it is:

You're a 55-year old engineer who graduated from school in '81\. You're being
interviewed by a 24-year old engineer who graduated 2 years ago. You're asked,
in an "algorithm interview", to explain some detail of the implementation of
an AVL tree.

In reality, despite the fact that they're covered in CS courses, virtually
nobody uses AVL trees in industry. In fact, people barely use balanced binary
trees at all, and when they do, they use red-black trees, and they use someone
else's implementation, because they're a bear to debug.

The 24-year old has an advantage with this question because they were recently
taught about, and perhaps had to do exercises/homework/tests based on, AVL
trees.

That this happens is stupid, because it's very unlikely that conversance with
AVL trees is going to make much of a difference to your on-the-job
performance. Almost all the narratives you can come up with about this involve
reading tea leaves and are shot down easily by better
selection/hiring/interviewing techniques that answer questions more directly.

This line of questioning can go too far; I don't, for instance, think knowing
the big-O characteristics of an AVL tree is unreasonable (it's a balanced
binary tree, and you should have the complexity of operations on those in
resident set throughout your career).

(AVL trees are just the first example of algorithmic trivia that came into my
head. Substitute Kruskal's Algorithm, or k-means clustering, or whatever,)

~~~
hacknat
I like what you are onto here. Algorithm questions get universally panned or
praised quite often, but there is a good deal of nuance in fact. Some are
much, much better than others. Some are pure trivia. I don't think most of us
would bat an eyelash at the idea that most engineers need to know that a hash
table is a O(c) look up, but it is an algorithm question that I've seen people
fail. Conversely, your examples of what is a poor question are probably
accurate in most domains.

~~~
RogerL
So what if they fail?

I had an programmer that didn't know that. I went to the whiteboard, explained
it, and now she is perfectly competent at it (and the rest of her job). What's
the problem?

Where do we get the idea that if someone doesn't know some arbitrary fact that
they are incapable of learning it? Hire people that are smart, have good work
ethics, and play nicely with others, and everything else will take care of
itself.

~~~
richardjordan
The last point is key, and overlooked by young insecure startup hirers too
often. Hire smart people with good work ethics that play nice with others.

Having built technical teams numbering in the dozens this is literally the
ONLY strategy that delivers long term success in my experience. Unfortunately
experience is discounted nowadays...

------
unoti
Here's an often overlooked technique for older, self-taught engineers like me:
study. Go get this book, The Algorithm Design Manual by Skienna. Also pick up
a whiteboard, and a nice set of dry-erase markers.

Read the book, and do whatever exercises you can from the book on the
whiteboard. Talk out loud, the way you will in the interviews. After a few
weeks and 60 hours of doing this, you'll be ready to blow the minds of the
people interviewing you.

When you go to your interview, you will bring your own markers. Then you don't
have to deal with the fat, half dried out stuff you encounter during the
interview. Also, warm up for an hour or two before you go to the interview, by
doing problems from the book on the whiteboard, out loud. This helps you leave
nothing to chance, and be ready for whatever they throw at you.

Yeah, it's a waste of time. But you have to play the game. Similarly, when
they ask you why you left your last job, lie and tell them you'd accomplished
all your goals there, got everything lined up and nailed down, and you're
ready to make something happen somewhere else. Don't tell the truth if it's
because your managers couldn't care less about doing what's best for the
business. If you want to work at the circus, sometimes you gotta jump through
some hoops. Big deal, you'll be ok!

Yes, the interview process is broken, but you can actually work at it and do
well, even if you're old.

Buy this book even if you're not planning to take my advice and study. Even if
you don't study, this should become one of your most treasured books. I myself
was amazed at how many things turn out to be graph problems, and had a great
time going through this book.

[1] [http://www.amazon.com/Algorithm-Design-Manual-Steven-
Skiena/...](http://www.amazon.com/Algorithm-Design-Manual-Steven-
Skiena/dp/1849967202)

~~~
balls187
> Here's an often overlooked technique for [...] engineers like me: study.

This is fantastic advice, for everyone.

Preparing for interviews isn't wasted time, because ultimately the goal is to
land a job that furthers your own personal goals in some fashion.

I wouldn't recommend lying. If you're leaving a job, you should stand by your
convictions. In my market, it's small and everyone knows everyone, so claiming
you nailed everything down is easy enough to verify. Just remember one simple
truth: "You are the only common link between all your failed jobs."

~~~
unoti
The difference between "I nailed it all down" and "everybody between myself
and the CEO was an idiot" may simply be a matter of perspective. Let's say
both are true. Focus on the former, rather than the latter, in interviews. Be
positive. Maybe that's a better way to phrase it, rather than saying "Lie."
Heaven's no, never lie during a job interview; that simply won't do at all!

~~~
anonbanker
Lawyers never lie. that would be unethical.

Instead, lawyers "speak colorably"; If one takes the pure white light of
truth, and puts it through a prism, all of those colors in the spectrum of
truth, while not 100% of the truth, still contain a very strong thread of it.

for example, I was in court recently settling a criminal charge for someone
about two months ago, and that someone asked the crown prosecutor (during the
hearing) why the crown has gone silent on the civil process settling the
charges. The crown, unable to lie, or even acknowledge a commercial default,
stated colorably that the paperwork was "not necessarily valid" in a criminal
case. not only was this true, but this kept the prosecution in honor, the
court in honor, and the defendant in honor, all while allowing him his
"Section 11" remedy (canada criminal code).

I'd suggest using colorable language any time you feel the need to lie.

TL:DR - In the eyes of the law, telling a spectrum of truth is still
considered telling the truth.

~~~
balls187
So what I told you was true... from a certain point of view.

------
nl
_As we enter a more mature phase of the internet’s progress, it may be time
for us to reconsider our strong bias toward the new. Maintainability and
reliability are increasingly the edges needed to serve internet users
accustomed to highly-reliable systems. New approaches to programming will
still have their place, but they are entering a more crowded market where they
really have to prove their value in order to be received.

We need to have a conversation about working with people of different
experience and talent levels. We need to address our industry’s lust for shiny
(i.e. young) over reliable. For in the process of that conversation, I believe
that we will begin to address the odd inequities that plague our industry._

Wow.

And there exactly is a perfect example of the bias that older engineers
complain about.

By using the same argument for older technologies and older engineers he
conflates the two, implying that older engineers are really better off working
on older tech.

~~~
tptacek
Yes, this is not a good example of an intrinsic structural bias against older
programmers in interviews. Plenty of older programmers also hopelessly
captivated by the current NoSQL-du-jour. :)

~~~
nl
Indeed.

Though I think Stonebraker's VoltDB supports SQL as well.. ;)

------
codeonfire
If companies actually tracked the exact questions that are asked and how they
are asked, then bias would be easy to spot. People they want to hire get
softball binary tree or linked list questions. People they don't want to hire
get disqualifier questions that are not in any textbook (and not in journals
either) which definitely can't be white-boarded to their satisfaction in 40-45
minutes. I've gotten both. The latter I research afterwards to make sure that
it's in none of the 30-40 textbooks I have or in any journals, ACM library, Dr
Dobbs, etc.

The worst are interviewers who refuse to accept a correct answer. "Oops, I
didn't expect the person to have the answer so I better make it more
complicated." It's so ridiculous that it's hard to believe people would sink
that low. Until you've experienced it though, you won't believe. I think it
suffices to say anything that deals with distribution of money, which
employment does, is going to have lots of bullshit.

~~~
bcg1
Couldn't agree more. These type of questions/interviews are a total waste of
time, and probably poison to most development teams.

I've been on more than one interview where I know that I've hit it out of the
park, and I swear that the lead dev torpedoed my prospects out of fear that
somebody might know enough to call him out on his BS.

Even in the best of scenarios, I think that this type of questioning has
little value. Unless it is the most basic of questions to determine if the
candidate actually knows the languages that they've listed on their resumes,
what value is there in testing if someone knows something can be easily looked
up and/or researched in a relatively short period of time if it was really
important for the task at hand?

Please don't take my comments as minimizing the high level of detailed
technical knowledge necessary for some tasks... but for most I would take a
humble hacker who can quickly inhale new knowledge over the goofballs who end
up doing these interviews, hands down.

------
angersock
Author invokes comparisons with the medical industry.

Look, we _really really really_ don't want to be taking _anything_ from those
folks. The hierarchies are rubbish, the talent questionable, and the egos
immense. At least in software we can _show_ that code does or doesn't work
irrespective of who wrote it.

~~~
michaelochurch
_Look, we really really really don 't want to be taking anything from those
folks._

You don't want a doctor's salary? And her level of respect from society at
large?

I also don't believe that the industry-wide talent level, or quality-of-work
level, is lower in medicine than in private-sector software. In fact, I'd be
shocked if it were the case. Look, there are some very smart people in our
industry (as in theirs) but there are also a lot of idiots.

~~~
angersock
Even with the salary, the shitty hours, bureaucracy, student loans, and
terrible customers kind of make it a wash.

The nice thing about software engineering is that we don't _have_ to spend ten
years getting educated enough to deal with customers that don't want to take
our advice...we can basically start there.

~~~
fsk
But on the flip side, as a programmer, your career can be mostly over at age
35-45.

Do doctors have the problem that the stuff they worked on 5-10 years ago is
considered obsolete now?

------
jasonlotito
Reading this, I couldn't help but think of why there is a shortage of
programmers. I think a large part of it is the technical interview. So many
places intend it to be a challenge, as if getting through it should be
considered a right of passage. "We only hire the best."

No, you only hire people who apply, get through the process, and accept your
offer. That's the best you can do.

People who interview a lot are going to be good at interviews. People that
spend years at places will look at a job offer and see the process of proving
themselves to new people. And that's a giant hurdle.

A part of me wants to do an interview, just to throw the interviewer a
technical question back at them. I have a few good ones in my back pocket.
When they start with whatever challenge they have, I stop them politely and
say:

"Wait a minute. You invited me here, so before we go any further, I want to
see if your company is worth my time."

And hit them with my question. Oh, that would be fun.

------
analog31
I wonder if, instead of focusing on the secretly terrible engineer, we focus
on the secretly good engineer. This is the good engineer who you hire,
_despite_ your elaborate hiring process.

Your entire business could be staffed with SGE's, and you would never know it.

------
bitwize
I spend a lot of time thinking about big-O performance of my algorithm
implementations. Not all the time, but the concern comes up frequently. If the
job is just gluing framework bits and bobs together to stamp out CRUD apps,
maybe we shouldn't be so surprised when low-skill programmers step up to take
it?

~~~
kevinpet
I got caught up on that line as well, especially the authors use of "we". As
far as I can tell, the author has certainly studied algorithms, but has never
worked as a software engineer.

------
richardjordan
There's definitely inherent bias in much of the interviewing process, whether
deliberate or not, for many tech startups. But there's also a high degree of
bias once inside them. Older engineers with families often can't really do a
team bonding that involves Saturday night playing games getting drunk and
stoned, for example. Many startups, as they grow, provide things like health
insurance plans optimized for 25 year old healthy males, that are just not
that good for families and make it harder on older employees. And there are a
lot of younger engineering managers who feel uncomfortable leading teams with
older more experienced members in them. I've seen teams grow and older
engineers pushed out for fairly arbitrary reasons, despite being good coders.
And yes, even in this crazy environment where it's hard to hire.

(And yes when I was young and early in my career I never really paid much
attention to it and shrugged it off, but now it's my friends and I see myself
getting up there in age now, it is so very obvious, and a lot more prevalent
than I ever noticed.)

When someone has nearly 20 years engineering experience (not talking about me,
I don't) it is ridiculous to make them jump through some of these interviewing
hoops. Sure, some kid fresh out of college might pad his resume - because
there's not much to it. But an older veteran with a long resume, not so much.
Experience does count. The ins and outs of the latest technology might vary
slightly, but the patterns repeat. So much of engineering goes beyond the code
on the screen anyway.

------
rhizome
Since the author ingratiatingly uses "we," but is actually a Public Policy
student and Techcrunch writer, I predict this is part 2 in a maybe 5-part
series where he ends up writing about tptacek's conclusions without mentioning
him by name.

That said, it's interestingly telling to push "STE" as "secretly-terrible
engineer" rather than "self-taught engineer." The author's ideal is for the
negative case to be the soundbite, but then again: techcrunch.

~~~
tptacek
He mentioned me by name in part 1 of this series, with a link to my post, and
I didn't write anything about ageism. I'm pretty OK with the props I'm getting
as is.

------
dreamfactory2
The main problem I see with technical interviews is that they are based on an
assumption of individual technical knowledge adding value to an organisation.

Working instead from an assumption that the whole is greater than sum when it
comes to groups of people - I'd be far more interested in what a candidate is
like to work with and what unique qualities they bring that we don't already
have and which can act as a multiplier for the organisation.

------
madengr
So why don't programming jobs have the equivalent of technicians like most
other engineering fields?

~~~
jayvanguard
This is a good point. It would be useful to have a lower skilled, named role
for a lot of the rote programming jobs that just involve gluing frameworks
together.

------
killface
Shitty interviewers ask:

1\. Anything related to trees 2\. Big-O trivia and errata 3\. Reinventing the
wheel 4\. Bit-twiddling operations

Seriously. If I go into your interview and you ask me to reverse a string, and
it's not <string>.reverse(), I'm not taking your stupid job. I don't care if
you want me to know the tricks for an in-place string reverse with no
temporary variables, that just shows that you don't have a clue how to
interview.

Good interviewers? The best I've found so far:

1\. Ask people to do real-life problems 2\. No "gotcha" questions 3\. Let
people use the environment they'll be using for the job -- this means an IDE,
the internet (including stack overflow), and any library they want.

What I want to see when I'm interviewing is whether or not you have the
ability to solve a problem. I'm going to look at how you abstract and break
down problems, how you solve them, and at what point you say, "I think this is
done."

Yes, I expect good engineers to know when to use a tree or a list or set --
but if you're explicitly quizzing for that, you're probably filtering in more
terrible developers than you're filtering out.

~~~
balls187
> Shitty interviewers ask:

Google does none of what you prescribe for "good interviews" and they have
interviewing down to a science. Yes they've admitted they err on false
negatives, but that is acceptable because they have little to no false
positives.

From what I gather you want an easy interview. What you wrote is impractical
(though I agree gotcha questions can be a bit much).

As a candidate, I get 1-hour with you and I need to accomplish the following:

1\. Does your resume reflect your experience?

2\. Can you code?

3\. What is it like to work with you to solve a challenge?

4\. Sell you on joining us.

Real life problems may fit in an hour, but may not.

There are so many resources on programming interviews that spending an hour or
two during the week prior would pay off dividends in a candidates success
rate.

~~~
deciplex
I interviewed with Google last year and the interviewer did two of the four
things listed in killface's post. I actually do not agree with killface that
those four things are necessarily bad (programmers should at least be able to
make really good guesses at complexity, and know about trees), but at any
rate, Google definitely had no fucking idea what my capabilities are as a
developer after that interview, so incompetent was the interviewer.

It was actually one of the more terrible interviews I've been a part of, and I
was not disappointed by the negative result. Google certainly _believes_ they
have interviewing down to a science, but I suspect that belief is itself not
scientific, and instead just the usual bullshit and collective delusion.

------
michaelochurch
I would like the difficult interviews if there were upside to them. Let's say
that I'm a Level 6 engineer (on an abstract scale) and you're hiring me for a
Level 7 position-- a small promotion to offset the risk of changing jobs. If
the technical interview, I might fail (false negative). If that came with
_upside_ \-- really nailing that machine learning brainteaser would make me
eligible for Level 8 or 9 and the comp increase along with it-- then I'd be
fine. My issue with the tough, multi-day interview processes is that there's
often only downside. Why throw 4 hours into a company's take-home code test
just to (possibly) get the same standard-issue, market-level offer I could get
somewhere else?

A few years ago, I submitted a code sample that was ranked among the top 3
submissions ever-- I worked hard on that fucker-- only to receive a junior-
level offer with <0.05% equity. So what was the point of doing the code
sample?

On age and the quality of engineers, I generally find that older engineers are
very good. That said, I'd be skeptical of someone who did "regular old"
corporate engineering for 20 years. Why didn't he get out? I completely
understand not wanting to move into management, but why didn't he look for an
R&D job or move into an architectural role or try to become a consultant? (He
may have good reasons, like wanting to stay in Ohio with his family, and
therefore having fewer career options; I'd just try to figure out what they
are.) Corporate engineering has a low ceiling and anyone good is going to have
at least the desire (some may not have the ability, like someone tied to a
geographical area) to break through it.

The cult of neoteny-- Agile and open-plan offices and the all of the other
subtle signs of an age-discrimination/permanent-junior culture-- is somewhat
of a self-fulfilling prophecy. Mainstream engineering, in most organizations,
is a user-story ridden ghetto, a backlog-retrospective meeting that never
ends. By 35 or so, the good engineers have either gotten out of it (possibly
moving into R&D, data science, management, or independent consulting roles) or
left the industry entirely. The culture of short-termism, open-plan offices,
and business-driven engineering provides no exit. You don't get to escape it,
in most companies, by being good at your job-- unless you become a manager.

What's happening is that tech's "thought leaders" are creating conditions that
are hostile to older talent (which is necessary if you want your technology to
be any good) with "Agile"/Scrum micromanagement and bullpen office layouts,
then saying, "See, no one over 40 is any good". (In fact, there are a lot of
good people over 40; they just don't want to work for jackasses.) This is
congealing into a pernicious cultural assumption, based on shitty data, when
we should actually be blaming the VCs and the mediocre middle-managers-I-mean-
founders they fund instead of "old programmers".

~~~
jnbiche
I never get tired of reading your stuff, man. Will you run for office?

Nah, scratch that. You're too honest for politics.

------
swatow
I think algorithmic interviews are good, because they are a kind of
intelligence test. In spite of liberal dogma, some people are more talented
and intellegent than others, and tests can shed light on this. However, the
article does expose some flaws. Here are two bad kind of algorithm questions

1) Questions that rely too much on background knowledge. Knowing the exact
properties or implementation of the more complex algorithms in the canon of
undergraduate CS knowledge is not a particularly useful skill in itself.

2) Questions that have some trick that you either get or don't get. These
aren't always terrible, but they give a big advantage to someone who has seen
the question before.

So what is a good algorithm based question?

1) Implementing something basic but non-trivial, like N-Queens with
backtracking. Basically, something anyone should be able to do.

2) Something that mixes in domain knowledge. E.g. problems calculating
probabilities than can be solved with dynamic programming.

3) Pure domain knowledge, but in programming form. E.g. how to implement
k-means clustering.

