This is an obviously ridiculous take on a relatively clear idea: building complex systems using multiple development teams requires effective coordination, which implies not only development skill, but communication of technical plans.
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.
>>building complex systems using multiple development teams requires effective coordination, which implies not only development skill, but communication of technical plans.
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.
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.