When hiring senior engineers, you’re not buying, you’re selling

Re:When hiring senior engineers, you’re not buying, you’re s... by mbell on Sunday January 20, 2019 @07:05PM (#18956473)

> Strongest possible disagree. There are people who can talk all the way down to the point where they're basically dictating code to you, who nevertheless cannot deliver on a real project. There's a difference between knowing, intellectually, how to solve a problem with code, and actually being able to deliver working code.

I'm a little confused by this statement. Is your issue that they aren't _capable_ of writing the code or that their job performance isn't there once hired? i.e. Are the technical chops not there or is the work ethic not there? It seems like you are describing the later to me, or we are talking about different levels of conversation.

[ Parent | on HN ]

Re:When hiring senior engineers, you’re not buying, you’re s... by tptacek on Sunday January 20, 2019 @07:07PM (#18956484)

Being able to talk intelligently, in depth, and at length about code is not the same skill as being able to write or debug code.

[ Parent | on HN ]

Re:When hiring senior engineers, you’re not buying, you’re s... by mbell on Sunday January 20, 2019 @07:23PM (#18956555)

I haven't experienced this, not if you are digging into detail on how they solved previous issues. I'm not saying it doesn't exist, but I've never dug into detail and had coding be the problem. If you leave the conversation at a conceptual level, then I can see it happening much more often.

[ Parent | on HN ]

Re:When hiring senior engineers, you’re not buying, you’re s... by camgunz on Monday January 21, 2019 @12:52AM (#18957973)

I'm not OP, but when I've experienced this, it's very similar to something like "I've seen a million heist movies, but absolutely could not steal shampoo from a CVS". There's a very big difference between talking about doing something and actually doing it; there's a level of executive function that's required.

More specifically, you make so many small executive decisions when coding. Naming, how functions and classes are designed, which file/module this goes in, is this already tested, oh I found an unrelated bug, do I make a ticket, a new PR, or include it in this one, etc etc etc. The only thing I've seen that can answer those questions is homework--maybe previous work, but homework is better.

But I think you're remiss if you're not asking your senior engineering candidates how they make those decisions, not because the answers to relatively trivial questions are important, but because you should know--and they should be able to articulate--how they make those decisions, and they should know the pros and cons of their approach and other approaches.

[ Parent | on HN ]