Hacker News Reader

Comment by cerrelio | Hacker News Reader

Hiring someone with that much (or even half that much) experience shouldn't include a coding exercise. If it does, the results should contribute ~5%-10% weight to the final decision. Seniors'/leads' skills diverge from engineering over time. You shouldn't even be coding as a lead. You direct the coding of juniors. When I interview those upper levels, I talk more about design and how they work with other departments (ops, product, UI) to get things done; how they overcome people and process problems.

I know several leads who can write great code, but they can't lead a project to completion for the life of them. And if you discover that during the interview, you have to determine whether it was genuinely their lack of competence or because of poor management. Personally, I'd rather spend that hour allotted to coding digging more deeply into their non-coding skills.

View on HN

If the leaders of programmers can't code, then they can't evaluate them, and can't help them grow very well, and can't pass on the experience of developers over time.

It's crucial for first level leads to be able to code.

I would argue that a 'lead' would work with the juniors and need to code to help them whereas a 'manager' would not need to code.

The role name may vary between company, but I believe we can agree that there are different roles to fill.

If writing some code is that much of a pain why am I hiring you in an engineering role at all? This seems like a terminology problem more than anything.

>Seniors'/leads' skills diverge from engineering over time.

That's exactly the kind of "senior" person we _don't_ want.

Then your senior rung is probably unpromotable and will become useless; you're just paying a premium on entry level skills. Architects don't code; they care about broader, higher level things. So it's natural that seniors move away from coding to those more abstract tasks over time. Your juniors should be generating most of the code. If I had a lead/senior who wrote most of a system's code, I would be alarmed. He's not distributing the work (and knowledge of the codebase) and doesn't seem to understand his role.

Where my opinion differs from yours manifests itself in industry in the practice of separating "technical leadership" from "people leadership." Your architects (and leads) should be people managers. They should have authority in how their subordinates' time is spent. They should be able to resolve disagreements, both technical and interpersonal, among engineers. A "technical leader" designing large systems/platforms to be built by a team that's led by a "people manager" is pointless. I mean, who wants to design something without the authority to execute that design? That's a toothless fluff position.

Reply on news.ycombinator.com