Interview article: Fix link to match title

1 files changed, 0 insertions, 330 deletions

diff --git a/_articles/2020-10-20-how-to-not-interview-engineers.md b/_articles/2020-10-20-how-to-not-interview-engineers.md
deleted file mode 100644
index bd1fffd..0000000
--- a/_articles/2020-10-20-how-to-not-interview-engineers.md
+++ /dev/null
@@ -1,330 +0,0 @@
----
-title: How not to interview engineers
-date: 2020-10-20
-layout: post
-lang: en
-ref: how-to-not-interview-engineers
----
-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 "judgment" 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 90 WPM (words per minute), and
-a great one can do 120 WPM, but with a stenography keyboard they get to 200
-WPM+. 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. Saying high IQ correlates with great programming is a stretch, at
-best.
-
-[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 tangentially 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?
-
-In other words: is the question not signaling because the one
-asking is from HR, or because the one asking is an intern? If the latter, than
-he's just arguing that interns have no place in interviewing, but if the former
-than he was picking on HR.
-
-Extrapolating that, it is common to find people who don't value HR's work, and
-only see them as inferiors doing unpleasant work, and who aren't capable enough
-(or *smart* enough) to learn programming.
-
-This is equivalent to people who work primarily 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 asymmetric 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 five" 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,
-judgment 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][cargo-culting][^cargo-culting-archive]? 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
-[^cargo-culting-archive]: [Archived version](https://web.archive.org/web/20201003090303/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 engineering 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 employer'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.