The problem with this piece is that it sounds vaguely Machiavellian. defmacro.substack.com/p/how-to-inter
The other problem with it is that it passes all my taste tests: it matches my experience with designing hiring systems for software engineers. Slava's process is likely to work.
Conversation
(Of course, it goes without saying that his process is highly adapted to his context (US, hard database problems); if I were to apply it to Singapore or Vietnam, it would need to be modified. But that's true of every practically useful thing.)
3
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
On the contrary: if you find a technique that allows you to reduce management problems earlier in the value chain, you should test that first, instead of settling for downstream techniques. (This is a core principle in Grove's High Output Management; and it's really useful.)
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
Actually, I disagree on this. 'Technical taste' is not that difficult to evaluate if you're a decent programmer.
In my prev company, you could ask engineers "rank colleagues according to acumen" and come to a consensus pretty quickly (with maybe slight disagreements).
1
Replying to
Slava's context was that he built RethinkDB — which took on MongoDB directly. Databases are hard technical products, and so I get why he's using his process.
I wouldn't personally use such a rigorous process. But I would definitely try out his 'judgement' filter.
1
Replying to
Also, the 10x engineer discussion is irrelevant here. It's not useful. In practice, we worked backwards from what we *needed* in our company to a hiring process that optimised for those needs. e.g. We needed people who could embed with customers, so you can imagine the reqs.
1
Show replies