Ask HN: When did 7 interviews become “normal”?

The second paragraph, the one you seem to have an issue with, a combination of 2 things:

- a few examples of extremely senior, extremely successful engineering leaders who stayed at or near the top of the game technically, and those are but a few examples from a very long list

- an observation that in other fields, law for example, they call in the highly-knowledgable, highly-expensive, person capable of solving problems few in anyone else in the organization can and that this person carries titles like "partner" and makes the most money.

I know this is a touchy subject and I've been trying to be less flamey on HN so I didn't go hard like the GP, but they're fundamentally right even if the language is a bit intemperate: there is a prestigious and important job track for people who are pretty damned technical/quantitative but not wildly hands-on and generally concerned as much or more with coordination and communication, particularly in cross-functional or externally-facing scenarios than software systems per se: product manager. As a wild oversimplification: when an EM becomes senior enough they end up as a CTO, and when a PM becomes senior enough they end up as a CEO. This is natural and healthy division of labor.

An EM is concerned first and foremost with the health, happiness, and therefore productivity of engineers. On the foundation of the trust and rapport and deep knowledge that comes from that kind of engagement with their team, they are able to also be concerned with how their team fits into the bigger business picture: is this the right team for the needs of the business, what hiring and performance management would be necessary to make it so if not, what is a realistic schedule for the work that needs to be done given the strengths and weakness of the team members both generally and at this moment in time?

When I'm wearing my hacker hat I have no interest in reporting to an EM who couldn't do my job in a pinch, I might respect that person on a lot of levels but I won't be interested in their opinion of how I should do my job. And at no time in my career has it been so easy to identify such managers: they are the "back to the office damn the torpedos" crowd. When the task tool, and the code review tool, and the oncall/incident situation, and the build wiki are not sufficiently comprehensible to an EM to form an opinion of who is doing a good job, the instinct to do "ass-in-seat" performance evaluation is strong, the instinct to be "visible" is strong, and narrative that there's value add looks very threadbare over Zoom.

This bloc is probably too big and too entrenched to dislodge, but WFH for 2 years working out just fine is the best chance we're going to get. IMHO.

(Assuming the dispute is about $50k).

And in many areas companies must hire attorneys to represent them. They can't represent themselves.

I'm all for resolving actual issues, and I think the solution here is: - make it so parties do not need to hire attorneys - use things like fairclaims.com to arbitrate (must faster and cheaper)

Every career move is life-changing, and I want to get as good a sense as I can about the people, environment, and company.

I want to hear from different levels and facets of the company, get a feel for the team members or representative other boots-on-the-ground ICs (what they're like, what the environment is like, how they feel about the company), and also try to see their initial impressions of how I'd fit in.

What doesn't work for that is being on the receiving end of a barrage of "whiteboard this Stanford new-grad shibboleth 'so I can see how you think'".

The current Leetcode interview tells me only a little bit about the company -- and it's negative (but, relativism-wise, I don't fault people much for defaulting to currently popular ideas). But it doesn't tell me much more than that (unless the interviewer is also being rude as they go through the ritual, which would be another negative).

The Leetcode interview also isn't a very effective way for the company to get a sense of what I can do that a second-year CS student probably can't.

I don't know that there's like one leading term, but I think everyone knows what "diff" means both literally and as a connotation that it's a rebase rather than merge workflow.