As an interviewer, when I rate the candidate that I just interviewed, I will take into account how good the candidate is at communication, but it wouldn't be a decisive factor. The decisive factor would be whether they solved the problem and wrote good-quality code.
If you have extra N hours to prepare for an engineering interview, I think spending them on practicing problem-solving and coding would be more efficient than practicing storytelling.
If you are already pretty good at interview problems, it might be valuable to invest a bit of time into communication. Doing a mock interview or two would be good way to do it.
One the biggest challenges I am facing with a colleague I hired (I was not the hiring manager but technically it was my say finally) is their communication skills. They find it really hard to explain a problem to others. They also do not listen properly or adequately and it is not malicious at all. I did not consider communication as a deciding factor at least to some extent. Lessons learnt.
Also, I have been focussing a lot more on “coding” problems (as in that whiteboard thingie) because that is what I guessed asked whenever I interview. I am going to work on that as well. That, while shows candidate can solve that coding challenge, is more of a GRE - GRE shows the person is good at taking GRE and may not necessarily be good at english, maths or reasoning at all.
When I wrote that it's not a decisive factor, I didn't mean that it doesn't affect the decision at all. It happened to me once or twice that I had such a hard time communicating with the candidate, that I highlighted it in the report and gave them lower rating.
The other side to this is that if you're interviewing and communication is not a decisive factor, you should walk away. You don't want to work in places where this is common practice, as your job will be unnecessarily difficult, communication being the most important part of software development.
That hints to me that you are likely a "Jira ticket shop" and the engineers are handed code tasks on at a time. They aren't expected to be part of team figuring out the product problems and improvements.
Very few interviews I’ve done had a real technical component. Most have been talk about what you’ve done, how it brought value, how I approach problems, etc.
This is for data science, data engineering and cloud architecture positions.
I sometimes think problem set focused technical interviews are an American thing. Even when applying at google in Europe I didn’t have a technical test.
What position in Google were you interviewing for? I thought any engineering position requires around 4 technical interviews. There is no difference between Europe and the US in this regard.
Something like a customer success engineer. What I was told was my technical interview consisted entirely of thinking of reasons why an imaginary customers AdWords weren’t showing. I didn’t move on from that so maybe there were leet code waiting for a more suitable candidate.
I do hardware design in the midwest US and my experience tracks yours. I've done maybe 10 technical interviews over the last 10 years. They typically want to talk about problems I've had and how I've handled them, some basic level of technical understanding (i.e. explain this circuit, or show how you would change X parameter of this design), and in the better interviews they ask questions to see how I communicate with people.
Better communication skills have easily tripled my negotiated salary. I was always this good at tech stuff, but not at speaking. While what you say may be true, I question this being normal or the average. Most of the time folks want you to talk well and that's what rewards you.
I'd like to add that while you are right for engineering, for certain analytics roles communication would be the decisive factor I'd consider (granted of course the candidate knows how to use SQL and got decent scripting skills). The reason is most of our job as analytics engineers is communication and translating stakeholders business problems.
To clarify a bit, cause it matters. This is more of a listening skill, and then an analytical skill. Mind you listening is half (or more?) of good comms. But evaluating listening is 10x more difficult than speaking or writing. The latter two are not a proxy for the former.
If you have extra N hours to prepare for an engineering interview, I think spending them on practicing problem-solving and coding would be more efficient than practicing storytelling.
If you are already pretty good at interview problems, it might be valuable to invest a bit of time into communication. Doing a mock interview or two would be good way to do it.