git mv src/content/* src/content/en/

8 files changed, 912 insertions, 0 deletions

diff --git a/src/content/en/blog/2020/10/05/cargo2nix-demo.tar.gz b/src/content/en/blog/2020/10/05/cargo2nix-demo.tar.gz
new file mode 100644
index 0000000..43677ec
--- /dev/null
+++ b/src/content/en/blog/2020/10/05/cargo2nix-demo.tar.gz
diff --git a/src/content/en/blog/2020/10/05/cargo2nix.adoc b/src/content/en/blog/2020/10/05/cargo2nix.adoc
new file mode 100644
index 0000000..a2d478e
--- /dev/null
+++ b/src/content/en/blog/2020/10/05/cargo2nix.adoc
@@ -0,0 +1,72 @@
+= cargo2nix: Dramatically simpler Rust in Nix
+:sort: 1
+
+:empty:
+:swift2nix: link:swift2nix.html
+:cargo2nix: link:cargo2nix-demo.tar.gz
+
+In the same vein of my earlier post on {swift2nix}[swift2nix], I was able to
+quickly prototype a Rust and Cargo variation of it: {cargo2nix}[cargo2nix].
+
+The initial prototype is even smaller than swift2nix: it has only 37 lines of
+code.
+
+Here's how to use it (snippet taken from the repo's README):
+
+[source,nix]
+----
+let
+  niv-sources = import ./nix/sources.nix;
+  mozilla-overlay = import niv-sources.nixpkgs-mozilla;
+  pkgs = import niv-sources.nixpkgs { overlays = [ mozilla-overlay ]; };
+  src = pkgs.nix-gitignore.gitignoreSource [ ] ./.;
+  cargo2nix = pkgs.callPackage niv-sources.cargo2nix {
+    lockfile = ./Cargo.lock;
+  };
+in pkgs.stdenv.mkDerivation {
+  inherit src;
+  name = "cargo-test";
+  buildInputs = [ pkgs.latest.rustChannels.nightly.rust ];
+  phases = [ "unpackPhase" "buildPhase" ];
+  buildPhase = ''
+    # Setup dependencies path to satisfy Cargo
+    mkdir .cargo/
+    ln -s ${cargo2nix.env.cargo-config} .cargo/config
+    ln -s ${cargo2nix.env.vendor} vendor
+
+    # Run the tests
+    cargo test
+    touch $out
+  '';
+}
+----
+
+That `cargo test` part on line 20 is what I have been fighting with every
+"*2nix" available for Rust out there.  I don't want to bash any of them.  All I
+want is to have full control of what Cargo commands to run, and the "*2nix" tool
+should only setup the environment for me.  Let me drive Cargo myself, no need to
+parameterize how the tool runs it for me, or even replicate its internal
+behaviour by calling the Rust compiler directly.
+
+Sure it doesn't support private registries or Git dependencies, but how much
+bigger does it has to be to support them?  Also, it doesn't support those *yet*,
+there's no reason it can't be extended.  I just haven't needed it yet, so I
+haven't added.  Patches welcome.
+
+The layout of the `vendor/` directory is more explicit and public then what
+swift2nix does: it is whatever the command `cargo vendor` returns.  However I
+haven't checked if the shape of the `.cargo-checksum.json` is specified, or
+internal to Cargo.
+
+Try out the demo (also taken from the repo's README):
+
+[source,sh]
+----
+pushd "$(mktemp -d)"
+wget -O- https://euandre.org/static/attachments/cargo2nix-demo.tar.gz |
+	tar -xv
+cd cargo2nix-demo/
+nix-build
+----
+
+Report back if you wish.
diff --git a/src/content/en/blog/2020/10/05/cargo2nix.tar.gz b/src/content/en/blog/2020/10/05/cargo2nix.tar.gz
new file mode 100644
index 0000000..d7224d9
--- /dev/null
+++ b/src/content/en/blog/2020/10/05/cargo2nix.tar.gz
diff --git a/src/content/en/blog/2020/10/05/swift2nix-demo.tar.gz b/src/content/en/blog/2020/10/05/swift2nix-demo.tar.gz
new file mode 100644
index 0000000..cc8b4f1
--- /dev/null
+++ b/src/content/en/blog/2020/10/05/swift2nix-demo.tar.gz
diff --git a/src/content/en/blog/2020/10/05/swift2nix.adoc b/src/content/en/blog/2020/10/05/swift2nix.adoc
new file mode 100644
index 0000000..9a3c6fe
--- /dev/null
+++ b/src/content/en/blog/2020/10/05/swift2nix.adoc
@@ -0,0 +1,194 @@
+= swift2nix: Run Swift inside Nix builds
+:sort: 0
+
+:empty:
+:nix: https://nixos.org/
+:swift2nix: link:swift2nix.tar.gz
+
+While working on a Swift project, I didn't find any tool that would allow Swift
+to run inside {nix}[Nix] builds.  Even thought you _can_ run Swift, the real
+problem arises when using the package manager.  It has many of the same problems
+that other package managers have when trying to integrate with Nix, more on this
+below.
+
+I wrote a simple little tool called {swift2nix}[swift2nix] that allows you trick
+Swift's package manager into assuming everything is set up.  Here's the example
+from swift2nix's README file:
+
+[source,nix]
+----
+let
+  niv-sources = import ./nix/sources.nix;
+  pkgs = import niv-sources.nixpkgs { };
+  src = pkgs.nix-gitignore.gitignoreSource [ ] ./.;
+  swift2nix = pkgs.callPackage niv-sources.swift2nix {
+    package-resolved = ./Package.resolved;
+  };
+in pkgs.stdenv.mkDerivation {
+  inherit src;
+  name = "swift-test";
+  buildInputs = with pkgs; [ swift ];
+  phases = [ "unpackPhase" "buildPhase" ];
+  buildPhase = ''
+    # Setup dependencies path to satisfy SwiftPM
+    mkdir .build
+    ln -s ${swift2nix.env.dependencies-state-json} .build/dependencies-state.json
+    ln -s ${swift2nix.env.checkouts} .build/checkouts
+
+    # Run the tests
+    swift test
+    touch $out
+  '';
+}
+----
+
+The key parts are lines 15~17: we just fake enough files inside `.build/` that
+Swift believes it has already downloaded and checked-out all dependencies, and
+just moves on to building them.
+
+I've worked on it just enough to make it usable for myself, so beware of
+unimplemented cases.
+
+== Design
+
+What swift2nix does is just provide you with the bare minimum that Swift
+requires, and readily get out of the way:
+
+. I explicitly did not want to generated a `Package.nix` file, since
+  `Package.resolved` already exists and contains the required information;
+. I didn't want to have an "easy" interface right out of the gate, after
+  fighting with "*2nix" tools that focus too much on that.
+
+The final actual code was so small (46 lines) that it made me think about
+package managers, "*2nix" tools and some problems with many of them.
+
+== Problems with package managers
+
+I'm going to talk about solely language package managers.  Think npm and cargo,
+not apt-get.
+
+Package managers want to do too much, or assume too much, or just want to take
+control of the entire build of the dependencies.
+
+This is a recurrent problem in package managers, but I don't see it as an
+intrinsic one.  There's nothing about a "package manager" that prevents it from
+_declaring_ what it expects to encounter and in which format.  The _declaring_
+part is important: it should be data, not code, otherwise you're back in the
+same problem, just like lockfiles are just data.  Those work in any language,
+and tools can cooperate happily.
+
+There's no need for this declarative expectation to be standardized, or be made
+compatible across languages.  That would lead to a poor format that no package
+manager really likes.  Instead, If every package manager could say out loud what
+it wants to see exactly, than more tools like swift2nix could exist, and they
+would be more reliable.
+
+This could even work fully offline, and be simply a mapping from the lockfile
+(the `Package.resolved` in Swift's case) to the filesystem representation.  For
+Swift, the `.build/dependencies-state.json` comes very close, but it is internal
+to the package manager.
+
+Even though this pain only exists when trying to use Swift inside Nix, it sheds
+light into this common implicit coupling that package managers have.  They
+usually have fuzzy boundaries and tight coupling between:
+
+. resolving the dependency tree and using some heuristic to pick a package
+  version;
+. generating a lockfile with the exact pinned versions;
+. downloading the dependencies present on the lockfile into some local cache;
+. arranging the dependencies from the cache in a meaningful way for itself
+  inside the project;
+. work using the dependencies while _assuming_ that step 4 was done.
+
+When you run `npm install` in a repository with no lockfile, it does 1~4.  If
+you do the same with `cargo build`, it does 1~5.  That's too much: many of those
+assumptions are implicit and internal to the package manager, and if you ever
+need to rearrange them, you're on your own.  Even though you can perform some of
+those steps, you can't compose or rearrange them.
+
+Instead a much saner approach could be:
+
+. this stays the same;
+. this also stays the same;
+. be able to generate some JSON/TOML/edn which represents the local expected
+  filesystem layout with dependencies (i.e. exposing what the package manager
+  expects to find), let's call it `local-registry.json`;
+. if a `local-registry.json` was provided, do a build using that.  Otherwise
+  generate its own, by downloading the dependencies, arranging them, _etc._
+
+The point is just making what the package manager requires visible to the
+outside world via some declarative data.  If this data wasn't provided, it can
+move on to doing its own automatic things.
+
+By making the expectation explicit and public, one can plug tools _à la carte_
+if desired, but doesn't prevent the default code path of doing things the exact
+same way they are now.
+
+== Problems with "*2nix" tools
+
+:node2nix: https://github.com/svanderburg/node2nix
+
+I have to admit: I'm unhappy with most of they.
+
+They conflate "using Nix" with "replicating every command of the package manager
+inside Nix".
+
+The avoidance of an "easy" interface that I mentioned above comes from me
+fighting with some of the "*2nix" tools much like I have to fight with package
+managers: I don't want to offload all build responsibilities to the "*2nix"
+tool, I just want to let it download some of the dependencies and get out of the
+way.  I want to stick with `npm test` or `cargo build`, and Nix should only
+provide the environment.
+
+This is something that {node2nix}[node2nix] does right.  It allows you to build
+the Node.js environment to satisfy NPM, and you can keep using NPM for
+everything else:
+
+[source,sh]
+----
+ln -s ${node2nix-package.shell.nodeDependencies}/lib/node_modules ./node_modules
+npm test
+----
+
+Its natural to want to put as much things into Nix as possible to benefit from
+Nix's advantages.  Isn't that how NixOS itself was born?
+
+But a "*2nix" tool should leverage Nix, not be coupled with it.  The above
+example lets you run any arbitrary NPM command while profiting from isolation
+and reproducibility that Nix provides.  It is even less brittle: any changes to
+how NPM runs some things will be future-compatible, since node2nix isn't trying
+to replicate what NPM does, or fiddling with NPM's internal.
+
+**A "*2nix" tool should build the environment, preferably from the lockfile
+directly and offload everything else to the package manager**.  The rest is just
+nice-to-have.
+
+swift2nix itself could provide an "easy" interface, something that allows you to
+write:
+
+[source,sh]
+----
+nix-build -A swift2nix.release
+nix-build -A swift2nix.test
+----
+
+The implementation of those would be obvious: create a new
+`pkgs.stdenv.mkDerivation` and call `swift build -c release` and `swift test`
+while using `swift2nix.env` under the hood.
+
+== Conclusion
+
+Package managers should provide exact dependencies via a data representation,
+i.e. lockfiles, and expose via another data representation how they expect those
+dependencies to appear on the filesystem, i.e. `local-registry.json`.  This
+allows package managers to provide an API so that external tools can create
+mirrors, offline builds, other registries, isolated builds, _etc._
+
+"*2nix" tools should build simple functions that leverage that
+`local-registry.json`{empty}footnote:local-registry[
+  This `local-registry.json` file doesn't have to be checked-in the repository
+  at all.  It could be always generated on the fly, much like how Swift's
+  `dependencies-state.json` is.
+] data and offload all the rest back to the package manager itself.  This allows
+the "*2nix" to not keep chasing the package manager evolution, always trying to
+duplicate its behaviour.
diff --git a/src/content/en/blog/2020/10/05/swift2nix.tar.gz b/src/content/en/blog/2020/10/05/swift2nix.tar.gz
new file mode 100644
index 0000000..a22aaa0
--- /dev/null
+++ b/src/content/en/blog/2020/10/05/swift2nix.tar.gz
diff --git a/src/content/en/blog/2020/10/19/feature-flags.adoc b/src/content/en/blog/2020/10/19/feature-flags.adoc
new file mode 100644
index 0000000..972f693
--- /dev/null
+++ b/src/content/en/blog/2020/10/19/feature-flags.adoc
@@ -0,0 +1,306 @@
+= Feature flags: differences between backend, frontend and mobile
+:categories: presentation
+:updatedat: 2020-11-03
+
+:empty:
+:slides: link:../../../../slides/2020/10/19/feature-flags.html FIXME
+:fowler-article: https://martinfowler.com/articles/feature-toggles.html
+
+_This article is derived from a {slides}[presentation] on the same subject._
+
+When discussing about feature flags, I find that their costs and benefits are
+often well exposed and addressed.  Online articles like
+"{fowler-article}[Feature Toggle (aka Feature Flags)]" do a great job of
+explaining them in detail, giving great general guidance of how to apply
+techniques to adopt it.
+
+However the weight of those costs and benefits apply differently on backend,
+frontend or mobile, and those differences aren't covered.  In fact, many of them
+stop making sense, or the decision of adopting a feature flag or not may change
+depending on the environment.
+
+In this article I try to make the distinction between environments and how
+feature flags apply to them, with some final best practices I've acquired when
+using them in production.
+
+== Why feature flags
+
+:atlassian-cicd: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
+
+Feature flags in general tend to be cited on the context of
+{atlassian-cicd}[continuous deployment]:
+
+____
+A: With continuous deployment, you deploy to production automatically
+
+B: But how do I handle deployment failures, partial features, _etc._?
+
+A: With techniques like canary, monitoring and alarms, feature flags, _etc._
+____
+
+Though adopting continuous deployment doesn't force you to use feature flags, it
+creates a demand for it.  The inverse is also true: using feature flags on the
+code points you more obviously to continuous deployment.  Take the following
+code sample for example, that we will reference later on the article:
+
+[source,javascript]
+----
+function processTransaction() {
+	validate();
+	persist();
+	// TODO: add call to notifyListeners()
+}
+----
+
+While being developed, being tested for suitability or something similar,
+`notifyListeners()` may not be included in the code at once.  So instead of
+keeping it on a separate, long-lived branch, a feature flag can decide when the
+new, partially implemented function will be called:
+
+[source,javascript]
+----
+function processTransaction() {
+	validate();
+	persist();
+	if (featureIsEnabled("activate-notify-listeners")) {
+		notifyListeners();
+	}
+}
+----
+
+This allows your code to include `notifyListeners()`, and decide when to call it
+at runtime.  For the price of extra things around the code, you get more
+dynamicity.
+
+So the fundamental question to ask yourself when considering adding a feature
+flag should be:
+
+____
+Am I willing to pay with code complexity to get dynamicity?
+____
+
+It is true that you can make the management of feature flags as straightforward
+as possible, but having no feature flags is simpler than having any.  What you
+get in return is the ability to parameterize the behaviour of the application at
+runtime, without doing any code changes.
+
+Sometimes this added complexity may tilt the balance towards not using a feature
+flag, and sometimes the flexibility of changing behaviour at runtime is
+absolutely worth the added complexity.  This can vary a lot by code base,
+feature, but fundamentally by environment: its much cheaper to deploy a new
+version of a service than to release a new version of an app.
+
+So the question of which environment is being targeted is key when reasoning
+about costs and benefits of feature flags.
+
+== Control over the environment
+
+:fdroid: https://f-droid.org/
+:bad-apple: https://www.paulgraham.com/apple.html
+
+The key differentiator that makes the trade-offs apply differently is how much
+control you have over the environment.
+
+When running a *backend* service, you usually are paying for the servers
+themselves, and can tweak them as you wish.  This means you have full control do
+to code changes as you wish.  Not only that, you decide when to do it, and for
+how long the transition will last.
+
+On the *frontend* you have less control: even though you can choose to make a
+new version available any time you wish, you can't
+force{empy}footnote:force[
+  Technically you could force a reload with JavaScript using
+  `window.location.reload()`, but that not only is invasive and impolite, but
+  also gives you the illusion that you have control over the client when you
+  actually don't: clients with disabled JavaScript would be immune to such
+  tactics.
+] clients to immediately switch to the new version.  That means that a) clients
+could skip upgrades at any time and b) you always have to keep backward and
+forward compatibility in mind.
+
+Even though I'm mentioning frontend directly, it applies to other environment
+with similar characteristics: desktop applications, command-line programs,
+_etc_.
+
+On *mobile* you have even less control: app stores need to allow your app to be
+updated, which could bite you when least desired.  Theoretically you could make
+you APK available on third party stores like {fdroid}[F-Droid], or even make the
+APK itself available for direct download, which would give you the same
+characteristics of a frontend application, but that happens less often.
+
+On iOS you can't even do that.  You have to get Apple's blessing on every single
+update.  Even though we already know that is a {bad-apple}[bad idea] for over a
+decade now, there isn't a way around it.  This is where you have the least
+control.
+
+In practice, the amount of control you have will change how much you value
+dynamicity: the less control you have, the more valuable it is.  In other words,
+having a dynamic flag on the backend may or may not be worth it since you could
+always update the code immediately after, but on iOS it is basically always
+worth it.
+
+== Rollout
+
+:kubernetes-deployment: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment
+:play-store-rollout: https://support.google.com/googleplay/android-developer/answer/6346149?hl=en
+:app-store-rolllout: https://help.apple.com/app-store-connect/#/dev3d65fcee1
+
+A rollout is used to _roll out_ a new version of software.
+
+They are usually short-lived, being relevant as long as the new code is being
+deployed.  The most common rule is percentages.
+
+On the *backend*, it is common to find it on the deployment infrastructure
+itself, like canary servers, blue/green deployments, {kubernetes-deployment}[a
+kubernetes deployment rollout], _etc_.  You could do those manually, by having a
+dynamic control on the code itself, but rollbacks are cheap enough that people
+usually do a normal deployment and just give some extra attention to the metrics
+dashboard.
+
+Any time you see a blue/green deployment, there is a rollout happening: most
+likely a load balancer is starting to direct traffic to the new server, until
+reaching 100% of the traffic.  Effectively, that is a rollout.
+
+On the *frontend*, you can selectively pick which user's will be able to
+download the new version of a page.  You could use geographical region, IP,
+cookie or something similar to make this decision.
+
+CDN propagation delays and people not refreshing their web pages are also
+rollouts by themselves, since old and new versions of the software will coexist.
+
+On *mobile*, the Play Store allows you to perform fine-grained
+{play-store-rollout}[staged rollouts], and the App Store allows you to perform
+limited {app-store-rollout}[phased releases].
+
+Both for Android and iOS, the user plays the role of making the download.
+
+In summary: since you control the servers on the backend, you can do rollouts at
+will, and those are often found automated away in base infrastructure.  On the
+frontend and on mobile, there are ways to make new versions available, but users
+may not download them immediately, and many different versions of the software
+end up coexisting.
+
+== Feature flag
+
+A feature flag is a _flag_ that tells the application on runtime to turn on or
+off a given _feature_.  That means that the actual production code will have
+more than one possible code paths to go through, and that a new version of a
+feature coexists with the old version.  The feature flag tells which part of the
+code to go through.
+
+They are usually medium-lived, being relevant as long as the new code is being
+developed.  The most common rules are percentages, allow/deny lists, A/B groups
+and client version.
+
+On the *backend*, those are useful for things that have a long development
+cycle, or that needs to done by steps.  Consider loading the feature flag rules
+in memory when the application starts, so that you avoid querying a database or
+an external service for applying a feature flag rule and avoid flakiness on the
+result due to intermittent network failures.
+
+Since on the *frontend* you don't control when to update the client software,
+you're left with applying the feature flag rule on the server, and exposing the
+value through an API for maximum dynamicity.  This could be in the frontend code
+itself, and fallback to a "just refresh the page"/"just update to the latest
+version" strategy for less dynamic scenarios.
+
+On *mobile* you can't even rely on a "just update to the latest version"
+strategy, since the code for the app could be updated to a new feature and be
+blocked on the store.  Those cases aren't recurrent, but you should always
+assume the store will deny updates on critical moments so you don't find
+yourself with no cards to play.  That means the only control you actually have
+is via the backend, by parameterizing the runtime of the application using the
+API.  In practice, you should always have a feature flag to control any relevant
+piece of code.  There is no such thing as "too small code change for a feature
+flag".  What you should ask yourself is:
+
+____
+If the code I'm writing breaks and stays broken for around a month, do I care?
+____
+
+If you're doing an experimental screen, or something that will have a very small
+impact you might answer "no" to the above question.  For everything else, the
+answer will be "yes": bug fixes, layout changes, refactoring, new screen,
+filesystem/database changes, _etc_.
+
+== Experiment
+
+An experiment is a feature flag where you care about analytical value of the
+flag, and how it might impact user's behaviour.  A feature flag with analytics.
+
+They are also usually medium-lived, being relevant as long as the new code is
+being developed.  The most common rule is A/B test.
+
+On the *backend*, an experiment rely on an analytical environment that will pick
+the A/B test groups and distributions, which means those can't be held in memory
+easily.  That also means that you'll need a fallback value in case fetching the
+group for a given customer fails.
+
+On the *frontend* and on *mobile* they are no different from feature flags.
+
+== Operational toggle
+
+An operational toggle is like a system-level manual circuit breaker, where you
+turn on/off a feature, fail over the load to a different server, _etc_.  They
+are useful switches to have during an incident.
+
+They are usually long-lived, being relevant as long as the code is in
+production.  The most common rule is percentages.
+
+They can be feature flags that are promoted to operational toggles on the
+*backend*, or may be purposefully put in place preventively or after a
+postmortem analysis.
+
+On the *frontend* and on *mobile* they are similar to feature flags, where the
+"feature" is being turned on and off, and the client interprets this value to
+show if the "feature" is available or unavailable.
+
+== Best practices
+
+=== Prefer dynamic content
+
+Even though feature flags give you more dynamicity, they're still somewhat
+manual: you have to create one for a specific feature and change it by hand.
+
+If you find yourself manually updating a feature flags every other day, or
+tweaking the percentages frequently, consider making it fully dynamic.  Try
+using a dataset that is generated automatically, or computing the content on the
+fly.
+
+Say you have a configuration screen with a list of options and sub-options, and
+you're trying to find how to better structure this list.  Instead of using a
+feature flag for switching between 3 and 5 options, make it fully dynamic.  This
+way you'll be able to perform other tests that you didn't plan, and get more
+flexibility out of it.
+
+=== Use the client version to negotiate feature flags
+
+After effectively finishing a feature, the old code that coexisted with the new
+one will be deleted, and all traces of the transition will vanish from the code
+base.  However if you just remove the feature flags from the API, all of the old
+versions of clients that relied on that value to show the new feature will go
+downgrade to the old feature.
+
+This means that you should avoid deleting client-facing feature flags, and
+retire them instead: use the client version to decide when the feature is
+stable, and return `true` for every client with a version greater or equal to
+that.  This way you can stop thinking about the feature flag, and you don't
+break or downgrade clients that didn't upgrade past the transition.
+
+=== Beware of many nested feature flags
+
+Nested flags combine exponentially.
+
+Pick strategic entry points or transitions eligible for feature flags, and
+beware of their nesting.
+
+=== Include feature flags in the development workflow
+
+Add feature flags to the list of things to think about during whiteboarding, and
+deleting/retiring a feature flags at the end of the development.
+
+=== Always rely on a feature flag on the app
+
+Again, there is no such thing "too small for a feature flag".  Too many feature
+flags is a good problem to have, not the opposite.  Automate the process of
+creating a feature flag to lower its cost.
diff --git a/src/content/en/blog/2020/10/20/wrong-interviewing.adoc b/src/content/en/blog/2020/10/20/wrong-interviewing.adoc
new file mode 100644
index 0000000..4b8d855
--- /dev/null
+++ b/src/content/en/blog/2020/10/20/wrong-interviewing.adoc
@@ -0,0 +1,340 @@
+= How not to interview engineers
+:updatedat: 2020-10-24
+
+:bad-article: https://defmacro.substack.com/p/how-to-interview-engineers
+:satire-comment: https://defmacro.substack.com/p/how-to-interview-engineers/comments#comment-599996
+:double-down: https://twitter.com/spakhm/status/1315754730740617216
+:poes-law: https://en.wikipedia.org/wiki/Poe%27s_law
+:hn-comment-1: https://news.ycombinator.com/item?id=24757511
+
+This is a response to Slava's "{bad-article}[How to interview engineers]"
+article.  I initially thought it was a satire, {satire-comment}[as have others],
+but he has [doubled down on it]:
+
+____
+(...) Some parts are slightly exaggerated for sure, but the essay isn't meant as
+a joke.
+____
+
+That being true, he completely misses the point on how to improve hiring, and
+proposes a worse alternative on many aspects.  It doesn't 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 {poes-law}[Poe's
+law].
+
+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 {hn-comment-1}[this comment]:
+
+____
+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.
+
+== What not to do
+
+=== Time candidates
+
+:hammock-driven-talk: https://www.youtube.com/watch?v=f84n5oFoZBc
+
+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.  A composer may have a
+deadline to finish a song in five weeks, but 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 specifically plan for including spaced pauses, and call it
+"{hammock-driven-talk}[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.
+
+Although 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.
+
+=== Pay attention to typing speed
+
+:dijkstra-typing: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD512.html
+:speech-to-text: https://www.youtube.com/watch?v=Mz3JeYfBTcY
+:j-lang: https://www.jsoftware.com/#/
+
+Typing is speed in never the bottleneck of a programmer, no matter how great
+they are.
+
+As {dijkstra-typing}[Dijkstra said]:
+
+____
+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}[speech-to-text]?  Make them all use {j-lang}[J] 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.
+
+=== IQ
+
+:determination-article: https://www.paulgraham.com/determination.html
+:scihub-article: https://sci-hub.do/https://psycnet.apa.org/doiLanding?doi=10.1037%2F1076-8971.6.1.33
+
+For "building an extraordinary team at a hard technology startup",
+intelligence is not the most important,
+{determination-article}[determination is].
+
+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
+{scihub-article}[still true today].
+
+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.
+
+=== 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
+
+:bad-apple: https://www.paulgraham.com/apple.html
+:be-good: https://www.paulgraham.com/good.html
+
+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 {bad-apple}[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 beyond "don't be evil" with a better motto:
+"{be-good}[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.
+
+=== 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 also true within the same language.  If a test is shown to work in
+England, it may not work in New Zealand, in spite of both speaking 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, after
+all it has been proven to work" shows he throws all of that background away.
+
+So much as 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
+
+:cult: https://calteches.library.caltech.edu/51/2/CargoCult.htm
+:cult-archived: https://web.archive.org/web/20201003090303/https://calteches.library.caltech.edu/51/2/CargoCult.htm
+
+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
+{cult}[cargo-culting]footnote:cargo-cult[
+  {cult-archived}[Archived version].
+]?  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.
+
+== What to do
+
+I will not give you a list of things that "worked for me, thus they are
+correct".  I won't either critique the current "industry standard", nor 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.