[closeparen]

Recently I have been musing about a SlateStarCodex-ish "compensation systems very different from ours."

One is Oxide [0], which has uniform compensation across the board, explicitly with reference to this problem about how performance processes influence work and culture.

Another might be to take LeetCode-style interviews more seriously. We have already concluded that the most important criteria for whether we want to work with someone is their ability to solve algorithmic programming tests under time pressure. Why stop at initial hire? Maybe they got lucky with familiar material. Maybe they crammed and didn't actually internalize it in a stable way. We should probably be giving coding interviews continuously to existing employees. Further, since we have concluded that shades of interview performance are a good way to determine seniority and responsibilities, we could also use these continuous tests in place of the promotion process. Knock it out of the park? Congrats, you're a staff engineer now. Barely squeak by? Back to intern. It sounds facetious but it also addresses the "promo criteria distort architecture" problem and the "YOE isn't ability problem." The civil service is not too different. Officials get to the next level by passing written and oral exams.

Another might be to have stakeholders bid on talent per project. This would match e.g. the creative industry where teams are constantly created and disbanded, and your next gig is based on the department head or director’s assessment of the quality of your work or the experience of working with you in a previous project.

[0] https://oxide.computer/blog/compensation-as-a-reflection-of-...

[TheOtherHobbes]

Assuming you're being serious - all of that sounds nightmarish and extremely subjective and failure-prone. Subjective assessments can easily skew towards politics and patronage. Your dept head is very likely indeed to confuse likability with technical ability.

The leetcode stuff doesn't necessarily correlate to actual productive capacity. Good teams tend to be a mix of complementary talents, and if you put a group of algo hackers together you'll get a lot of algo hacking. You won't necessarily get a lot of maintenance or debugging.

All of which highlights that the industry has no clue how to quantify talent either during hiring or after. And even less clue how to quantify the business value of talent. It has even less clue how to quantify needed talent - in the sense of creating teams with a productive mix of interlocking skills.

Abstract discussions about comp are meaningless from a business POV without that information.

This applies particularly to management. Some managers are clearly better than others, but in spite of all of the books, lectures, and general opportunism around management theory, many corps struggle with creating a sane productive culture.

[closeparen]

The relative virtue of workers and work products is in fact subjective and not a measurable quantity. Creative fields embrace this openly. Success in a creative project is highly related to the reactions it inspires in people (public, funders, critics, etc). A good creative leader has access to the same subjective reactions that the audience does. She also has them at a higher level of detail. That way she can give actionable feedback on specific elements, emphasize what works and cut what doesn't, to optimize the overall subjective experience. I came to know this process through the performing arts but I'm also pretty confident that it describes Steve Jobs. Personally I don't think we have nearly enough respect for practitioner judgement in the tech world. Software also succeeds and fails in many cases based on its subjective resonance with users and maintainers. (Though not all, contractor-maintained enterprise software exists). Good taste is also part of the virtue of a senior engineer.

Now in tech we are shy about subjectivity. One way to get a measurable quantity related to virtue is to construct a game. Within the framework of the game we can all agree on what is a win or a loss. We can also rank players according to their track record of wins and losses. Someone who wins when most others would lose is a good player. Someone who loses when most others would win is a bad player. We can have neat quantitative encodings of this, like Elo. And we can agree that winning or losing the game we have constructed has something to do with the virtues we care about. But unless we're talking about professional sports, the game is only a proxy. The subjective judgement now lives in the choice of this game, and not some other game, or this rule, and not some other rule, as our proxy.

This is obviously what we have done with LeetCode. LeetCode's fidelity as a proxy for working-programmer virtue is of course doubtful. The promo packet's fidelity seems like it should be higher. But the promo packet is also a constructed game and an imperfect proxy. When programmers play to win the LeetCode game they engage in not-very-constructive studying and practice in their free time, and perform the weird ritual for a few hours in a conference room. It is mostly the programmer's loss. When programmers play to win the promo packet game they do things contrary to working-programmer virtue in their capacity as working programmers. They design overcomplicated solutions, involve too many stakeholders in their execution, deprecate and replace things instead of maintain them, leave obvious defects in their products because there is no causal inference proving their dollar value, etc. The company loses. It loses big. Given that we have already accepted the tradeoffs of LeetCode interviews with respect to hiring, are you sure it's so ludicrous that they're a better set of tradeoffs than the ones we currently use for leveling?