path: root/_articles/2020-10-19-how-to-not-interview-engineers.md

---
title: How to not interview engineers
date: 2020-10-19
layout: post
lang: en
ref: how-to-not-interview-engineers
published: false
---
This is a response to Slava's
"[How to interview engineers][how-to-interview-engineers]" article. I initially
thought it was a satire, [as have others][poes-law-comment], but he has
[doubled down on it][slava-on-satire]:

> (...) Some parts are slightly exaggerated for sure, but the essay isn't meant
> as a joke.

If that is really true, and I'm still not sure if it is, he completely misses
the point on how to improve hiring, and proposes a worse alternative on many
aspects. It doesn't even qualify as provocative, it is just wrong.

I was comfortable taking it as a satire, and I would just ignore the whole thing
if it wasn't (except for the technical memo part), but friends of mine
considered it to be somewhat reasonable. This is a adapted version of parts of
the discussions we had, risking becoming a gigantic showcase of
[Poe's law][poes-law-wiki].

In this piece, I will argument against his view, and propose an alternative
approach to improve hiring.

It is common to find people saying how broken technical hiring is, as well put
in words by a phrase on [this comment][hn-satire]:

> Everyone loves to read and write about how developer interviewing is flawed,
> but no one wants to go out on a limb and make suggestions about how to improve
> it.

I guess Slava was trying to not fall on this trap, and make a suggestion on how
to improve instead, which all went terribly wrong.

[how-to-interview-engineers]: https://defmacro.substack.com/p/how-to-interview-engineers
[poes-law-comment]: https://defmacro.substack.com/p/how-to-interview-engineers/comments#comment-599996
[slava-on-satire]: https://twitter.com/spakhm/status/1315754730740617216
[poes-law-wiki]: https://en.wikipedia.org/wiki/Poe%27s_law
[hn-satire]: https://news.ycombinator.com/item?id=24757511

## What not to do

### Time candidates

Timing the candidate shows up on the "talent" and "judgement" sections, and they
are both bad ideas for the same reason: programming is not a performance.

What do e-sports, musicians, actors and athletes have in common: performance
psychologists.

For a pianist, their state of mind during concerts is crucial: they not only
must be able to deal with stage anxiety, but to become really successful they
will have to learn how to exploit it. The time window of the concert is what
people practice thousands of hours for, and it is what defines one's career,
since how well all the practice went is irrelevant to the nature of the
profession. Being able to leverage stage anxiety is an actual goal of them.

That is also applicable to athletes, where the execution during a competition
makes them sink or swim, regardless of how all the training was.

The same cannot be said about composers, though. They are more like book
writers, where the value is not on very few moments with high adrenaline, but on
the aggregate over hours, days, weeks, months and years. Even though a given
composer is supposed to finish a given song in five weeks, it doesn't really
matter if it is done on a single night, every morning between 6 and 9, at the
very last week, or any other way. No rigid time structure applies, only whatever
fits best to the composer.

Programming is more like composing than doing a concert, which is another way of
saying that programming is not a performance. People don't practice algorithms
for months to keep them at their fingertips, so that finally in a single
afternoon they can sit down and write everything at once in a rigid 4 hours
window, and launch it immediately after.

Instead software is built iteratively, by making small additions, than
refactoring the implementation, fixing bugs, writing a lot at once, *etc*.
all while they get a firmer grasp of the problem, stop to think about it, come
up with new ideas, *etc*.

Some even specifically plan for including spaced pauses, and call it
"[Hammock Driven Development][hammock-driven-development]", which is just
artist's "creative idleness" for hackers.

Unless you're hiring for a live coding group, a competitive programming team, or
a professional live demoer, timing the candidate that way is more harmful than
useful. This type of timing doesn't find good programmers, it finds performant
programmers, which isn't the same thing, and you'll end up with people who can
do great work on small problems but who might be unable to deal with big
problems, and loose those who can very well handle huge problems, slowly. If you
are lucky you'll get performant people who can also handle big problems on the
long term, but maybe not.

An incident is the closest to a "performance" that it gets, and yet it is still
dramatically different. Surely it is a high stress scenario, but while people
are trying to find a root cause and solve the problem, only the downtime itself
is visible to the exterior. It is like being part of the support staff backstage
during a play: even though execution matters, you're still not on the spot.
During an incident you're doing debugging in anger rather than live coding.

Even though giving a candidate the task to write a "technical memo" has
potential to get a measure of the written communication skills of someone, doing
so in a hard time window also misses the point for the same reasons.

[hammock-driven-development]: https://www.youtube.com/watch?v=f84n5oFoZBc

### Pay attention to typing speed

Typing is speed in never the bottleneck of a programmer, no matter how great
they are.

As [Dijkstra said][dijkstra-typing]:

> But programming, when stripped of all its circumstantial irrelevancies, boils
> down to no more and no less than very effective thinking so as to avoid
> unmastered complexity, to very vigorous separation of your many different
> concerns.

In other words, programming is not about typing, it is about thinking.

Otherwise, the way to get those star programmers that can't type fast enough a
huge productivity boost is to give them a touch typing course. If they are so
productive with typing speed being a limitation, imagine what they could
accomplish if they had razor sharp touch typing skills?

Also, why stop there? A good touch typist can do 90WPM (words per minute), and a
great one can do 120WPM, but with a stenography keyboard they get to 200WPM+.
That is double the productivity! Why not try [speech-to-text][perl-out-loud]?
Make them all use [J][j-lang] so they all need to type less! How come nobody
thought of that?

And if someone couldn't solve the programming puzzle in the given time window,
but could come back in the following day with an implementation that is not only
faster, but uses less memory, was simpler to understand and easier to read than
anybody else? You'd be losing that person too.

[dijkstra-typing]: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD512.html
[j-lang]: https://www.jsoftware.com/#/
[perl-out-loud]: https://www.youtube.com/watch?v=Mz3JeYfBTcY

### IQ

For "building an extraordinary team at a hard technology startup", intelligence
is not the most important, [determination is][pg-determination].

And talent isn't "IQ specialized for engineers". IQ itself isn't a measure of how
intelligent someone is. Ever since Alfred Binet with Théodore Simon started to
formalize what would become IQ tests years later, they already acknowledged
limitations of the technique for measuring intelligence, which is
[still true today][scihub-paper].

So having a high IQ tells only how smart people are for a particular aspect of
intelligence, which is not representative of programming. There are numerous
aspects of programming that are covered by IQ measurement: how to name variables
and functions, how to create models which are compatible with schema evolution,
how to make the system dynamic for runtime parameterization without making it
fragile, how to measure and observe performance and availability, how to pick
between acquiring and paying technical debt, *etc*.

Not to say about everything else that a programmer does that is not purely
programming.

[pg-determination]: http://www.paulgraham.com/determination.html
[scihub-paper]: https://sci-hub.do/https://psycnet.apa.org/doiLanding?doi=10.1037%2F1076-8971.6.1.33

### Ditch HR

Slava tangently picks on HR, and I will digress on that a bit:

> A good rule of thumb is that if a question could be asked by an intern in HR,
> it's a non-differential signaling question.

Stretching it, this is a rather snobbish view of HR. Why is it that an intern in
HR can't make signaling questions? Could the same be said of an intern in
engineering?

Extrapolating that, it is common to find people who don't value HR's work, and
only see them as inferiors doing unpleasent work, and who aren't capable enough
(or *smart* enough) to learn programming.

This is equivalent to people who work primarely on backend, and see others working on
frontend struggling and say: "isn't it just building views and showing them on
the browser? How could it possibly be that hard? I bet I could do it better,
with 20% of code". As you already know, the answer to it is "well, why don't you
go do it, then?".

This sense of superiority ignores the fact that HR have actual professionals
doing actual hard work, not unlike programmers. If HR is inferior and so easy,
why not automate everything away and get rid of a whole department?

I don't attribute this world view to Slava, this is only an extrapolation of a
snippet of the article.

### Draconian mistreating of candidates

If I found out that people employed theatrics in my interview so that I could
feel I've "earned the privilege to work at your company", I would quit.

If your moral compass is so broken that you are comfortable mistreating me while
I'm a candidate, I immediately assume you will also mistreat me as an employee,
and that the company is not a good place to work, as
[evil begets stupidity][evil-begets-stupidity]:

> But the other reason programmers are fussy, I think, is that evil begets
> stupidity. An organization that wins by exercising power starts to lose the
> ability to win by doing better work. And it's not fun for a smart person to
> work in a place where the best ideas aren't the ones that win. I think the
> reason Google embraced "Don't be evil" so eagerly was not so much to impress
> the outside world as to inoculate themselves against arrogance.

Paul Graham goes as far as saying that an even better motto than "don't be evil"
is to "[be good][pg-be-good]".

Abusing the asymetric nature of an interview to increase the chance that the
candidate will accept the offer is, well, abusive. I doubt a solid team can
actually be built on such poor foundations, surrounded by such evil measures.

And if you really want to give engineers "the measure of whoever they're going
to be working with", there are plenty of reasonable ways of doing it that don't
include performing fake interviews.

[pg-be-good]: http://www.paulgraham.com/good.html
[evil-begets-stupidity]: http://www.paulgraham.com/apple.html

### Personality tests

Personality tests around the world need to be a) translated, b) adapted and c)
validated. Even though a given test may be applicable and useful in a country,
this doesn't imply it will work for other countries.

Not only tests usually come with translation guidelines, but also its
applicability needs to be validated again after the translation and adaptation
is done to see if the test still measures what it is supposed to.

That is true even within the same language. If a test is shown to work in
England, it may not work in New Zealand, even though both speak english. The
cultural context difference is influent to the point of invalidating a test and
making it be no longer valid.

Irregardless of the validity of the proposed "big fived" personality test,
saying "just use attributes x, y and z this test and you'll be fine" is a rough
simplification, much like saying "just use Raft for distributed systems, it even
has proofs that it works" shows he throws all of that background away.

Even applying personality tests themselves is not a trivial task, and
psychologists do need special training to become able to effectively apply one.

### More cargo culting

He calls the ill-defined "industry standard" to be cargo-culting, but his
proposal isn't sound enough to not become one.

Even if the ideas were good, they aren't solid enough, or based on solid
enough things to make them stand out by themselves. Why is it that talent,
judgement and personality are required to determine the fitness of a good
candidate? Why not 2, 5, or 20 things? Why those specific 3? Why is talent
defined like that? Is it just because he found talent to be like that?

Isn't that definitionally also [cargo-culting]? Isn't he just repeating whatever
he found to work form him, without understanding why?

What Feynman proposes is actually the opposite:

> In summary, the idea is to try to give **all** of the information to help others
> to judge the value of your contribution; not just the information that leads
> to judgment in one particular direction or another.

What Slava did was just another form of cargo culting, but this was one that he
believed to work.

[cargo-culting]: http://calteches.library.caltech.edu/51/2/CargoCult.htm

## What to do

I will not give you a list of things that "worked for me, thus they are
correct". I won't even critique the current "industry standard", or what I've
learned from interviewing engineers.

Instead, I'd like to invite you to learn from history, and from what other
professionals have to teach us.

Programming isn't an odd profession, where everything about it is different from
anything else. It is just another episode in the "technology" series, which has
seasons since before recorded history. It may be an episode where things move a
bit faster, but it is fundamentally the same.

So here is the key idea: what people did *before* software engineering?

What hiring is like for engineers in other areas? Don't civil, electrical and
other types of engineers exist for much, much longer than software engineering
does? What have those centuries of accumulated experience thought the world
about technical hiring?

What studies were performed on the different success rate of interviewing
strategies? What have they done right and what have they done wrong?

What is the purpose of HR? Why do they even exist? Do we need them, and if so,
what for? What is the value they bring, since everybody insist on building an HR
department in their companies? Is the existence of HR another form of cargo
culting?

What is industrial and organizational psychology? What is that field of study?
What do they specialize in? What have they learned since the discipline
appeared? What have they done right and wrong over history? Is is the current
academic consensus on that area? What is a hot debate topic in academia on that
area? What is the current bleeding edge of research? What can they teach us
about hiring? What can they teach us about technical hiring?

## Conclusion

If all I've said makes me a "no hire" in the proposed framework, I'm really
glad.

This says less about my programming skills, and more about the employee's world
view, and I hope not to be fooled into applying for a company that adopts this
one.

Claiming to be selecting "extraordinary engineers" isn't an excuse to reinvent
the wheel, poorly.