Isn't that kind of odd? I've worked with software engineers who are good talkers but their code and problem solving skills leave something to be desired. Meanwhile, I've worked with guys who took a while to get comfortable with in terms of having conversations and yet they were some of the most productive members of the team both in code output and skill.

Ultimately, most of the time I 'talk' with my team members, we're actually writing which is very different from talking due to the async nature of the former.

You don't intentionally choose weak engineers, but a strong engineer working on the wrong thing because they can't communicate effectively is less useful than a slightly less strong engineer who's always doing the thing that's actually needed.

This hold true as pretty much every level. A junior engineer who will never say "No, I don't understand, can you explain that to me again please?" and spends days/weeks writing code that doesn't meet a requirement is less productive than someone who'll talk to you to understand properly before starting to code. A senior engineer or technical cofounder who can't communicate well with customers will be much less effective in solving real customer problems or finding product/market fit.

Being a great engineer isn't just about writing good code, its about writing the right code - and to know what that is you need good communication skills.

Whether someone will ask for help at the appropriate time is really not shown by how good they are at talking in an interview.

Asking for help is more about humility and willingness to look dumb, than about being gregarious or chatty or socially open.

You can categorize "humility and willingness to possibly be perceived as dumb" as non-communication skills, but in my mind they are:

A) the most important indicators of likely success on the team B) very correlated with comfort in speaking

If I can't get you to talk at all when you're uncomfortable, you're unlikely to tell me you don't understand in the often uncomfortable iterating on a feature process.

It's possible to be gregarious AND be unable to ever admit that you lack critical information, which is why interviews, for me, are mostly about asking questions until we get to the point you don't know/don't understand, and see how you work with me from there on.

What a lot of people who get stressed about interviews don't realize, though, is that WHERE PRECISELY you reach your limits is unimportant. It's that you engage thoughtfully, without getting overly defensive, and don't bullshit. Not about whether you got the right answer at any given spot.

You will want to adjust the knob depending on the specific role. You might look for different things in a candidate that will be person #1 on a one person project version person #49 on a 50 person project.

Remember that most of us that are self-taught are pretty good at being person #1 on a one person project. That's what self-teaching teaches us, after all. But, a successful business might not be possible built around one programmer, so as you progress in your career you'll be working on developing the skills to form a cohesive team around you. A lot of this is going to be talking to people, not memorizing some algorithm. (But, many jobs are going to require both, so don't forget all the algorithms while you're in those meetings. At least brush up on them before your interview. A day of prep here can equal hundreds of thousands of dollars over the course of your career.)

You're right to point out the difference between conversational and writing skills. However, generally engineers tend to overvalue technical skills and undervalue soft skills.

IMO engineering orgs tend to set the bar really high for tech skills and really low for communication skills. Tech skills are easier to test and they feel more "objective" so they get more focus.

It might be reflecting the fact that it's easier to talk about something if you know it well.

And the other side is that people who don't know what they are doing are very bad at talking once you try to solve problems. They might still be great at free form chit chat about technical things, like you'd get in an unstructured interview, but they lack the skills to actually apply the words they use and work through problems. So they will take a lot of space in meetings and chats and make everyone else less productive since they use so many words to say so little.

These are basically "brilliant jerks" on the soft skill side. They take so much of the space that the people who knows anything don't get much airtime. But if the soft brilliant jerk would just stop talking for a bit the other people would start talking and actually improve communication in the team.

The correct metrics are 1. Strong skillset, and 2. Able to follow instruction (obedient). Every other hot metrics now are pretty much misalign with company goal of earning profit. Purely on your criteria alone "strong communicator" are way down the list while "strong engineer" will be easily top 3 criteria. In a company you only need 1 or 2 strong communicator, usually they will be the head of departments or more likely C leaders. Too many chief and less foot soldiers will be like what happen to Enron where everybody just hop from departments to departments unable to deliver useful productivity. Talk is cheap. Actions speaks louder. Those strong communicators are also the most likely to jump ship and change job for the better within a short time. It will be very detrimental to company having this group of employees. Speaking from over 3 decades of experience in HR.

I'm fairly sure the reason I've gotten many of the jobs I've had is that I smile a lot.

Getting the interviewer to like you is most of what you need to land the position.

Engineering skills are easier to teach, particularly if you have an established culture and some senior personal who can spare a couple cycles to onboard new hires.

If you don't, that's a sign the engineering culture needs some TLC. And now that I think of it, in that case good communication may still be a priority factor.

Conversely, the interviews that have gone most well for me were those that were largely just technical conversations. That’s not to say that they were nothing but fluff — the bits of conversation were usually accompanied with plenty of skill testing.

The worst were the ones where the interviewer clearly didn’t want to be there and mostly acted as a cold stone statue firing questions of from a sheet of paper. Incidentally those interviews were usually also the ones with the highest number of hackerrank sorts of questions.