>>Having candidates talk through the solution to a non-trivial programming problem is a critical tool for me. I need to find developers that can not only code, but work as a part of a team
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.
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.
Funny you should describe it like that, but ... what you've just described is almost indistinguishable from pair or mob programming.
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.
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?