I can't afford to hire developers that can't effectively communicate complex ideas to other developers - something they're often required to do on-the-fly.
It's like asking someone to give an extemporaneous talk on some subject, while translating each sentence into another language as they go. Even native bilingual speakers would have quite some trouble with this. They can generate content, they can speak fluently, and they can translate on the fly, but having to do all three "live" involves too much context switching. Maybe doable for simple or rehearsed topics, but most coding interview questions are non-trivial.
I don't think this is universally true, and to some extent I think it's a practiced skill.
I used to really struggle to problem-solve and communicate at the same time, but then did two years of improv comedy outside of work and suddenly don't have that issue anymore. I think part of it for me was shortening the gap between my thoughts and my communication (to zero) which stops the need to context switch, but introduces a need to think in a way which is clear and structured (because you are going to be verbalising the voice in your brain, rather than thinking and then translating those thoughts to words as a secondary step).
But is it a skill that's even necessary and therefore developed while working as a software engineer?
In almost all cases that i can think of:
- real time communication might be important for discussing things before and after development, things such as architecture, concerns to pay attention to, or even choices made during development
- real time communication almost never plays a part during the actual development, unless doing pair programming live from 0 or even mob programming (absolutely unheard of in my current company)
- most of the time, what happens instead is dropping a detailed question in Slack and the other person responding to it when they have a minute, only escalating to calls if that's not helpful, which almost always only gives rough outlines of things to try next, not changesets to the code
- actually, most of the communication regarding code happens in merge requests asynchronously, which is better than synchronous communication which wouldn't be explicitly recorded and all of the arguments/outcomes of which would disappear
You can only feel confident in your ability to narrate these solutions when you know what they are or where to start, e.g. after a few hundreds of hours of grinding LeetCode, but at that point it's essentially following a flowchart of algorithms and in my eyes is basically "pretending" to be clever, even if there is something to be said about the ability to memorize solutions to problems (or even groups of solutions) and apply the correct one.
Perhaps it's a bit better in my eyes when you'll be applying these algorithms daily in your work, but so far it's about 90% CRUD development, struggling with the specifics of technologies and doing requirements engineering with clients who don't always know what they want or whether that what they want is technically feasible.
Disclaimer: there are probably cultural aspects to it as well, like how here in North/East Europe we don't really do much small talk with strangers. Or maybe it's just corporate culture, or the people working within the company happening to be more introverted and thus the idea of narrating things real time simply being uncomfortable to them.
It's also useful to 'work a problem' with people sometimes which requires this sort of live communication, however the extent to which teams do this will vary by team. In my experience this is more common in teams that are physically located together in the same room.
Also it's not inherently clear to me that "not used in the job" means it's also bad from an assessment perspective - take defensive driving certifications for example, which require drivers to 'verbalise' what they are noticing, doing, and their decisions while they drive. Do you verbalise when you are driving in reality? No - but it is an established technique for assessment and for learning.
But each to their own. Different strokes for different folks, clearly this works for some people and not others.
I code as part of the process of thinking things through. Seeing how bits will fit together. It's like how an author writes to organize their thoughts, instead of the other way around. How ridiculous would it be to interview an author based on their ability to write a short article on a whiteboard in real-time, while talking through their writing process!
I myself found it asinine when I was asked to talk while writing code... I just cannot focus in the problem at hand while coding. Maybe I am stupid or low IQ, but I need to concentrate in the problem and put 100% of my attention on it.
From interviewing several hundred people so far, I've seen that most of them breathe a sigh of relief once I told them that rule (along with the rule of being able to search for whatever they want as part of the challenge).
The image of a developer constantly speaking while coding on their day to day brings me a chcukle.
So at work, every time your programmers are assigned a JIRA ticket they speak in loud voices every line of code they are writing/deleting/editing???
Sounds like a horrible way of managing a team.
>>I can't afford to hire developers that can't effectively communicate complex ideas to other developers - something they're often required to do on-the-fly.
This goes beyond I imagined. Once the JIRA is assigned they literally scream at each other what they are thinking?
I have had situations where people complain about noisy clicky keyboards, let alone people loudly repeating their ideas on other peoples faces.
How does all this work for your team?
If you're on the team assigned to develop the UI for the turbine monitoring of a hydroelectric power generating station, at some point you're going to need to be in a room with a bunch of other developers and engineers, and start working through some technical issues or begin planning how you're going to approach the problem. That will involve working through code while getting input, which will obviously involve speaking to the other humans in the room.
I know there's a tendency on HN to think that all developers are just like you, but a lot of developers aren't working on simple nonsense like the next to-do app or note-taking tool. Many developers are working on complex, real-time systems that require the coordination of dozens of teams of specialists over years. If you can't manage to communicate your approach to solving a particular problem to a room full of engineers and other developers, you're just not going to do well in that kind of environment.
That's not what is being discussed here. As a matter of fact anything as complicated as what you describe here, can't be explained in one cycle. It will require several takes to arrive at something good. And it definitely doesn't involve repeating their deepest thoughts at their colleagues faces.
If anything your interview method feels more like an audition for an acting role than problem solving.
Where one person needs to describe clearly what code needs to be written so the other can type it. Actually pair programming requires more effort in that regard, since describing what you're doing is easier than describing exactly how to write it.
I don't do 100% pair programming gigs, but I know they exist, and I've used pair programming in short bursts as a tool for knowledge transfer.
Having to explain something non-trivial happens. But literally always there are hours between solution and explaining it. In pretty much any real situation, I have quite a lot of time to think about how to explain.