3 ms·

If you fundamentally have a problem presenting your ideas to others, then maybe you aren't fit to work in a team. The ability to code is less than half the bat

If you fundamentally have a problem presenting your ideas to others, then maybe you aren't fit to work in a team. The ability to code is less than half the battle. The other half is actually making sure the idea you have is even a good idea. Any moron can write garbage in a room alone. The premise of the test is whether or not a person can write code that solves a problem. Which is literally the lowest bar possible for a coding interview. How about the thought process it takes to derive a optimal solution? Maybe interviewers want to test someone who can actually collaborate with them, explain their reasoning, and logically come up with a solution? Maybe that's more akin to real life than being in a cubicle coding all day alone with 0 human contact? Hmmm...

KronisLV 5y ago
> How about the thought process it takes to derive a optimal solution? Maybe interviewers want to test someone who can actually collaborate with them, explain their reasoning, and logically come up with a solution? Maybe that's more akin to real life than being in a cubicle coding all day alone with 0 human contact? I don't think that that's a sufficiently generous consideration of how differently people think. Not everyone narrates all of the steps that are needed to solve their problems in a linear way of fully coherent arguments and needing to do so might slow them down, similarly to how some people don't have an inner monologue at all. Instead, consider that some might have "checkpoints" in the problem solving process that they can formulate after a bit of discovery and trying some things out: "Okay, so i felt that X might work because of Y, but it didn't because of Z and now i probably should try something else..." Having 5 to 10 minutes of silence between such sentences would be awkward in probably every single real time interview, thus people are forced into a mode of thinking that they won't do in practice, unless pair programming with someone else live. I don't know about you, but most of the communication with my colleagues happens either before or after development, mostly asking questions about specifics in Slack when needed, or rarely escalating to calls for non-trivial situations/questions (even though i fail to recall the last time when i called someone about a particular bit of code, yet have often explained things to others). So, as opposed to calling said people morons or claiming that every single thought needs to be representable to others, maybe it's useful to consider that the way people think might play a part in it, that there are also preferences people have for synchronous vs asynchronous communication (which doesn't imply NO communication) and that there might even be cultural differences?

KronisLV 5y ago

> How about the thought process it takes to derive a optimal solution? Maybe interviewers want to test someone who can actually collaborate with them, explain their reasoning, and logically come up with a solution? Maybe that's more akin to real life than being in a cubicle coding all day alone with 0 human contact? I don't think that that's a sufficiently generous consideration of how differently people think. Not everyone narrates all of the steps that are needed to solve their problems in a linear way of fully coherent arguments and needing to do so might slow them down, similarly to how some people don't have an inner monologue at all. Instead, consider that some might have "checkpoints" in the problem solving process that they can formulate after a bit of discovery and trying some things out: "Okay, so i felt that X might work because of Y, but it didn't because of Z and now i probably should try something else..." Having 5 to 10 minutes of silence between such sentences would be awkward in probably every single real time interview, thus people are forced into a mode of thinking that they won't do in practice, unless pair programming with someone else live. I don't know about you, but most of the communication with my colleagues happens either before or after development, mostly asking questions about specifics in Slack when needed, or rarely escalating to calls for non-trivial situations/questions (even though i fail to recall the last time when i called someone about a particular bit of code, yet have often explained things to others). So, as opposed to calling said people morons or claiming that every single thought needs to be representable to others, maybe it's useful to consider that the way people think might play a part in it, that there are also preferences people have for synchronous vs asynchronous communication (which doesn't imply NO communication) and that there might even be cultural differences?