> can't communicate well

Or, perhaps the person thinks (solves) in abstract concepts rather than linear words. Just because many people mouth words when reading or can't think without hearing words in their head or aloud, doesn't mean others should have to handicap their own efficacy of thought while working it out. Two conceptuals can communicate in a kind of ultra condensed shorthand liner verbal thinkers struggle to follow. Less can't communicate, more can't conceptualize squared off with can't verbalize.

Both groups should synthesize simply and clearly at the end, both should work to get in sync. And both ways of thinking have their uses in a team. Catch: conceptual thinkers can interview verbal thinkers, the other way around is more challenging.

> I have interviewed dozens of engineering candidates.

I have too. Stating this doesn't give you the credibility you probably think it does. Interviewing/hiring in general is a pretty broken process, and extremely susceptible to subjective interviewer bias.

> If someone can't communicate well on technical matters, that's generally a negative.

Your interview method doesn't test if someone "can communicate well on technical matters." I can see why you think it does, but it does not. "Good communication" is not the ability to produce the correct sequence of thoughts/words when given 45 minutes to solve a problem in a hostile environment (surrounded by strangers, with your livelihood on the line).

What you're actually selecting for is a very specific type of candidate who thinks and communicates like you in a way that you can easily understand. You're basically selecting for vibes. And when you structure your interviews this way, you specifically end up preferring candidates who are better at bullshitting and "selling themselves" as opposed to candidates who are actually the most technically sound.

The biggest indictment against your interviewing mentality is that it's limited by how good you are at listening and understanding. You're probably worse at it than you think you are, and spending too much time in the interviewer position and not enough in the interviewee position makes it easy to fall into this trap.

I've interviewed and placed dozens of candidates on teams I've led. I've also interviewed and gotten offers at dozens of companies in the past 10-15 years. The more offers I get, the more I realize how broken interviewing is.

The mistakes you're making won't necessarily cause you to hire bad candidates, but it will undoubtedly allow you to reject/ignore very strong candidates just because they don't talk/think like you. Maybe you have a problem with diversity of thought, but generally that's a desirable characteristic on most engineering teams.

My advice is to spend more time on objective measures, and to check your ego at the door before conducting your interviews. Spending so much time as a gatekeeper makes it easy to get a superiority complex, which comes across quite plainly in your original comment.

If you need to people to think out loud on the spot, go hire salesman. A person's ability to do this in real time has zero correlation with their ability to actually do engineering and communicate on technical matters. Real communication encompasses more than verbal stream of consciousness.

I have ~15 years experience with hands on engineering. I also served as a hiring manager in a couple of roles, and interviewed dozens of candidates.

I would love to live in a world where every candidate represented their experience accurately, and every applicant was capable of fulfilling the role, but sadly it's not the case.

I agree there's some filters which are mostly performative (like leetcode), but being able to talk through the kind of work you do is table stakes. And not just for engineers, for any professional role.

"Working well on a team" is something completely uncorrelated with the ability of explaining your thinking during the time when you are solving a problem.

All the teams in which I have ever worked have greatly appreciated my contribution precisely because I was always willing to spend a lot of my time explaining to other colleagues, in a differentiated way appropriate for the understanding abilities of each of them, how I had solved my problems or how they should solve their problems.

On the other hand, I am also completely unable to explain my thinking while it is in progress, because reformulating it to become intelligible to the interlocutor would slow me down far too much.

Explaining on-line my thinking would require even a kind of language translation, because when I am speaking to myself I use a special language with precise non-ambiguous words, whose meanings correspond in many cases with old meanings of those words, because in the modern language a very large number of words have vague meanings, which have become very diluted due to the frequent use of those words in inappropriate contexts.

So when I describe some technical solution to others, I typically do not use the words with which I think about it, but whatever words are more fashionable today, so I expect familiarity with them, even when I think that those are not the right words.

Doing such a translation while I think is too difficult, and I do not attempt to think with whatever words become fashionable from time to time, without any good reasons, because in my opinion using the right names for concepts is very important for understanding and using them properly.

I mean, communicating/collaborating with upper management and turning their requests into solid code? That's what I get paid to do. Communicating/collaborating with other coders? Not so much. Note that I specifically said I don't work for tech firms.

So, my policy has always been that if I sit through a meeting where a client asks for new feature "X" and I figure out a way to avoid building the new feature, and either use existing business logic / day-to-day processes, or else find some new way that doesn't involve code, I don't bill for that time. I'd say that I probably give up about 35-40% of potential coding work just by helping them work through that. Which is fine, because it leaves me free time to do other things.

On the other hand, I don't have the option to fail even slightly. I deployed a patch yesterday for an old, rare, logic bug in one reservation system, and within an hour I was being bombarded with edge cases of people seeing their reservations as cancelled during the 15 minute switch-over period.

Sometimes I feel like the job of a programmer for a company is just very different from what I do. If anything goes wrong with anything I deploy, I'm awake for however long it takes to make sure it's right. On the other hand: No PRs, no teamwork. Just a click to deploy once I'm relatively sure. And a lot of responsibility.

I have aphantasia so anendophasia sounds like such a nightmare to me, though I imagine those so have it would likely feel the opposite of me. I've met some folks in the past who I'd suspect have anendophasia, but I'm not sure how I'd ever bring that up without coming across as uncouth.

Anyone with anendophasia care to opine on their experience?

Good thing IQ has nothing to do with solving novel programming or architectural puzzles :)

Who's "we"? I am not in that group...

My experience: intuitive thinking it's a shortcut, but it's less reliable when it comes to complex problems, especially involving multiple concepts that have to be reasoned about with non trivial relationships or rules. In a way I see a spectrum of approaches that range from fast to reliable:

1. Intuitive thinking

2. Language based internal monologue

3. Written scratchpad

4. Explaining the problem to another person until they understand it (rubber ducking)

I completely lack the 'critical self narrator' that many people report being distressed by. If I make a bad decision there is nobody 'punishing' me for it internally. I also feel like I am better than average at very stressful dangerous situations - i find that i dont particularly analyze things in the moment, or at least the conscious part i aware of doesn't. I just act on 'autopilot' if that makes sense.

It does have an enormous mountain of downsides, though.