> Having worked with people like this, I have to call BS. There are a lot of people with the distinct skill of being able to effectively imitate the speech patterns of actual programmers. Asking questions, engaging in productive discussion, etc. But when faced with an empty editor, they simply cannot produce working code.

Having never worked with anyone like that, I will have to call BS on this because it is simply too hard to believe, without evidence, that someone can understand this level of detail and not know how to create working code. A parrot cannot engage in productive discussion, and aping speech patterns only goes so far. Plus, if they're so good at aping speech patterns, who says they aren't equally good at aping code patterns?

It's all too true. There are, in my estimation, probably twice as many people who can talk around in circles and make it sound like they know what they are talking about, as people who can actually knuckle down and get things done. There's a little bit of overlap in the Venn diagram there, but not as much as you might think, for whatever reason. Probably because the people who can actually do things are too busy implementing all the shit that the bullshitters get their teams on the hook for.

> Plus, if they're so good at aping speech patterns, who says they aren't equally good at aping code patterns?

One is a social skill; the other requires understanding. Even in a technical conversation, a very large percentage of the interaction is social if the conversation is taking place face-to-face. I have also worked with people who could talk the talk, but not produce the code. Without social skills, those people seem to fail from job to job while not really understanding that they are failing: things just inexplicably go wrong all the time. With social skills (which is much more common), those people bafflegab their way into being system architects, middle or upper managers, and executives, where a lack of detailed low-level knowledge is more of an asset that keeps them from getting bogged down in details.

I've worked with people like this, and it's still hard to believe with evidence. I've changed my interview style from asking questions about programming to one that has candidates do a small design, then write one or two small programs implementing the design they just did. A surprising number of candidates are able to complete the design part well and then unable to make any real progress on the code. Most of them were phone screened before my interview; some had multi year careers in the industry. This feels different than people who are nervous or otherwise having a bad day, as they are exuding confidence while simultaneously being unable to write a while loop.