> People who read a lot of blogs so know the lingo, but never code

I think this is where my definition of "talk like a professional" may be more strict. I'm interested in understanding, in opinions, in the actual engineering.

> People who get the theory but can't actually implement something that works without bugs

Having spent most of my career working with PhDs trying to design and implement signal processing and NLP algorithms, I have experienced a lot of that. Given the proper attitude, it is fairly easy to correct coding deficiencies if someone really understands what they are supposed to be doing.

> People that over-engineer simple things

The greater offenders are fairly easy to detect in a directed technical discussion. The lesser offenders are fairly easy to correct in code review, again given the proper attitude, as they are unlikely to be doing things that require major refactoring.

In short, I think I place much more emphasis on engineering as opposed to coding. My experience has been that any coding issues people with good engineering skills and an attitude worth hiring have are quickly and easily corrected. You cannot really understand the engineering of a system without being able to code it. You might not be as efficient as someone else, but you are capable.

Also:

* People who have been on a team long enough to learn how things should work but lack the skills to really do the coding.

I phone screened a guy fairly recent who had a very long background (~20 years) in a pretty security-conscious field. He did very well in open-ended design discussions and was able to explain his prior work very well. He couldn't code trivial binary tree operations, though. I can only assume that someone else on his team is carrying most of the coding burden. This guy might be great at a PM-type job (or not, I don't interview for those jobs), but not as a dev.

I feel like there is some detail missing here. What constituted doing "very well" on the open-ended questions? How deep into the engineering did you get? Since you mentioned he "might be great at a PM-type job" it sounds like you didn't go very deep on int.

That one was a phone screen, so no it was not the deepest technical dive ever. But in fairness a 1-hour interview is rarely the deepest technical dive possible. I normally pose some big problem like "design a system that accomplishes X at high scale" and then drill into some area iteratively until we're discussing fairly specific details. At the high level I'm looking for the candidate to recognize tradeoffs between centralized/distributed designs, sanely choose the major components, deal with stateful and stateless components, recognize security tradeoffs, etc. As we drill in we might talk about data partitioning, georeplication, or high availability and implementation tradeoffs there. We might get down to the level of something like handling out-of-order change notifications. Rarely do I drill down to the level of file I/O or memory management strategies.