6 ms·

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, bu

by ziggus 5y ago

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 - something that requires significant communications abilities. 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.

Apocryphon 5y ago
Maybe the existing process can be tweaked? Just give candidates some time to themselves when they're not under observation before they present.
saulpw 5y ago
These are two different modes of operation. I can code when in abstract problem-solving mode, and then later communicate that complex idea using my verbal skills. I can't do both at the same time. 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.
- Closi 5y ago
  > These are two different modes of operation. 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).
  - KronisLV 5y ago
    > I don't think this is universally true, and to some extent I think it's a practiced skill. 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 Thus, narrating the problem solving process live when you don't even have any idea how to solve the problem, haven't done research about that particular problem, have no idea what others in the industry have tried and how that worked out, is almost completely useless in my eyes. During this process, when you haven't done this discovery, about 80% of what you'd think of would be useless and would be tossed aside when you'd figure out what you actually need. 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.
- kova12 5y ago
  If you can code, then explain, but not in reverse - that indicates you don't have a path to solution in your mind without some trial and error. Some levels of engineering require you to have one, at least for certain tasks.
  - saulpw 5y ago
    Right, so the first step in this process is to think through the problem until you have a path to a solution in your mind, before you start coding and explaining. But the job interview process we're talking about explicitly asks you to start talking aloud about your thought process (and be judged on it!) with essentially zero time to think it through first. 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!
watwut 5y ago
I worked in teams whole my life. Having to explain while I am solving something non-trivial is rare to non existent situation. If just don't happen. 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.
cloverich 5y ago
If you want a comparable experience, assign a difficult task to one of your developers, then tell them: "I am going to watch you solve this problem. Talk me through it as you do so. I'll judge the result, if its not good enough I will have to fire you on the spot. Also this is timed. Proceed."
xtracto 5y ago
For me it has been the other way around: When I give a programming problem for a candidate to solve, I ask them to focus for the 30 minutes in the problem and solve it. 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.
kamaal 5y ago
>>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. How does all this work for your team?
- ziggus 5y ago
  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.
  - kamaal 5y ago
    >>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.

by ziggus 5y ago

Apocryphon 5y ago

Maybe the existing process can be tweaked? Just give candidates some time to themselves when they're not under observation before they present.

saulpw 5y ago

These are two different modes of operation. I can code when in abstract problem-solving mode, and then later communicate that complex idea using my verbal skills. I can't do both at the same time. 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.

Closi 5y ago
> These are two different modes of operation. 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).
- KronisLV 5y ago
  > I don't think this is universally true, and to some extent I think it's a practiced skill. 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 Thus, narrating the problem solving process live when you don't even have any idea how to solve the problem, haven't done research about that particular problem, have no idea what others in the industry have tried and how that worked out, is almost completely useless in my eyes. During this process, when you haven't done this discovery, about 80% of what you'd think of would be useless and would be tossed aside when you'd figure out what you actually need. 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.
kova12 5y ago
If you can code, then explain, but not in reverse - that indicates you don't have a path to solution in your mind without some trial and error. Some levels of engineering require you to have one, at least for certain tasks.
- saulpw 5y ago
  Right, so the first step in this process is to think through the problem until you have a path to a solution in your mind, before you start coding and explaining. But the job interview process we're talking about explicitly asks you to start talking aloud about your thought process (and be judged on it!) with essentially zero time to think it through first. 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!

watwut 5y ago

I worked in teams whole my life. Having to explain while I am solving something non-trivial is rare to non existent situation. If just don't happen. 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.

cloverich 5y ago

If you want a comparable experience, assign a difficult task to one of your developers, then tell them: "I am going to watch you solve this problem. Talk me through it as you do so. I'll judge the result, if its not good enough I will have to fire you on the spot. Also this is timed. Proceed."

xtracto 5y ago

For me it has been the other way around: When I give a programming problem for a candidate to solve, I ask them to focus for the 30 minutes in the problem and solve it. 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.

kamaal 5y ago

>>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. How does all this work for your team?

ziggus 5y ago
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.
- kamaal 5y ago
  >>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.