I remember in high school when many test questions would ask for the answer and an explanation of that answer. The idea is that if you only have an answer that wasn't the teacher's answer, it's either right or wrong, but there is no measure of insight. When you do explain, rather than just see if the answer matches the one on the scoresheet, they could actually grade how well you demonstrated your understanding of the subject.
(As an interesting anecdote, I once had a test where they had forgotten to add the "and explanation" bit on many questions. The result was that the only way the teacher was able to grade the test led to pretty low grades. My grade, though, wasn't affected, because I didn't need the instruction to write down an explanation to realize that I should write down an explanation...)
I think this is similar: the point isn't to test how well you communicate, it's about being able to judge your skill a lot better than when there is only your code.
In your analogy, does the solver think thru the solution and then write the solution+explanation? Or does the solver think thru the solution while writing the solution+explanation? I think it is the former, and that is the crux of my post (not " let's do away with explanation").
I did not mean to imply the two processes are the same - they couldn't be since one is a written piece and the other is an in-person meeting. I wasn't even defending the use of the use of thinking out loud.
All I meant to say was that I think you're missing an important part of why people want you to "think out loud".
"Thinking out loud" means "to verbalize one's thoughts", and I am open to explanations about how such verbalization can be useful in a technical interview.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I remember in high school when many test questions would ask for the answer and an explanation of that answer. The idea is that if you only have an answer that wasn't the teacher's answer, it's either right or wrong, but there is no measure of insight. When you do explain, rather than just see if the answer matches the one on the scoresheet, they could actually grade how well you demonstrated your understanding of the subject.
(As an interesting anecdote, I once had a test where they had forgotten to add the "and explanation" bit on many questions. The result was that the only way the teacher was able to grade the test led to pretty low grades. My grade, though, wasn't affected, because I didn't need the instruction to write down an explanation to realize that I should write down an explanation...)
I think this is similar: the point isn't to test how well you communicate, it's about being able to judge your skill a lot better than when there is only your code.
In your analogy, does the solver think thru the solution and then write the solution+explanation? Or does the solver think thru the solution while writing the solution+explanation? I think it is the former, and that is the crux of my post (not " let's do away with explanation").
I did not mean to imply the two processes are the same - they couldn't be since one is a written piece and the other is an in-person meeting. I wasn't even defending the use of the use of thinking out loud.
All I meant to say was that I think you're missing an important part of why people want you to "think out loud".
"Thinking out loud" means "to verbalize one's thoughts", and I am open to explanations about how such verbalization can be useful in a technical interview.