Hacker News Reader

Comment by ng12 | Hacker News Reader

It's a balancing act, right? After being a hiring manager for 5 years I've learned that what a candidate says about themselves means jack-all. You could be a genuinely great hire or some guy who spent 25 years banging their head against the wall going from one failed project to another and your elevator pitch will be roughly the same.

Trust but verify. I'm sure some companies overdo it but if you're going to be touching code in any capacity I want to do the best I can to verify your abilities in a reasonable amount of time. A 1-hour coding exercise fits that criteria pretty well.

View on HN

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.

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.

You are right it is a balancing act.

It would depend on the coding exercise; you cannot just have a 30min chat about a relevant practical example? I'm not sure I have met someone who can bullshit his/her way verbally out of a random practical coding issue which I can just describe in a few minutes and they can talk with me about. But that's not some 'pen down a tree balancing algo with the following time/space constraints'. Which you might not have been talking about anyway but which the OP was about.

Reply on news.ycombinator.com