4 ms·

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 skil

by 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.
  - Closi 5y ago
    I think it's probably not a skill required for most software engineering, but it's probably useful if you have a more senior engineering position where part of your role is helping and coaching less experienced people. 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.
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!

by saulpw 5y ago

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.
- Closi 5y ago
  I think it's probably not a skill required for most software engineering, but it's probably useful if you have a more senior engineering position where part of your role is helping and coaching less experienced people. 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.

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!