A common requirement in most white-board coding interviews is a candidate voice out her thoughts as she works thru the problem. The same applies to...
For further actions, you may consider blocking this person and/or reporting abuse
We do pair programming assessments and white board conversations. Not white board problem solving.
So with a pair programming assessment, you want the developer candidate to engage to get support. Communicating offers opportunities for the interview to not only gauge the candidates ability to communicate and how they problem solve, it allows the interviewer to assist, guide, and help. It allows them a mechanism to start a conversation to see how the developer will fit into the larger culture.
With white board conversations, we ask a few simple questions. What would your colleagues says you good at. What would they say your bad at. Then we try and help them with something they are bad at, if possible using something they are good at.
For example someone might say they are great at React. But they don’t really do architecture.
We would help them in a session talk though how to setup the architecture for a react app that is a stats dashboard. It’s less about right or wrong solutions and more about how they learn, how open they are to feedback, and can they talk about things critically.
I have had candidate thank me for this approach, and tell me they learned something. My goal is to make sure they enjoy what they do, but that they can function within the organization in a way that makes them and everyone else they work with better.
While this is hard for introverts, it’s not impossible. Most introverts understand it’s part of the job to work with others.
I agree it is about communication. But, I believe "thinking out loud (verbalizing thoughts)" is not necessary for communication. Instead, a conversation with pauses to select, edit, and arrange thoughts before verbalizing them might work well; in fact, this would lead to better communication.
Don’t disagree. I think it’s the easier way to get people to talk. There is value in it, but it’s better do some other structure that sparks dialog with the same or greater benefit.
Out of curiosity, assuming you mean "other structure/mode than conversation", what would be such structure/mode that provide same or greater benefit?
I believe my first comment is a fine example.
Talk out load your thought pattern is different than a conversation. In the two cases I gave, we promote conversation, not someone just describing what we are watching.
Ah, I suppose pair programming would work; I haven't tried it cos' I don't test for coding during in-person interviews. As for whiteboard coding/problem solving, I suppose it would work as long as it is a conversation/dialogue as opposed to a monologue with interruptions by the interviewer :)
Yep, that is exactly the idea. For me that is a practical assessment. Someone talking unnaturally over doing a algorithm does not does not represent how the person will be as a developer or what it will be like to work with them.
The interview is not just about you solving the problem. A good whiteboard problem and a good interviewer will solve the problem with you. What is being gauged is how well WE work together to solve the problem. Can you communicate something to another engineer? How well do you cope with interruptions? If a requirement suddenly changes, did you think forward enough to be able to handle it, or did you just solve the problem as it was presented to you?
Is "thinking out loud" necessary to assess these aspects/skills? If not, they why use it while putting the interviewees at disadvantage; that's my point.
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.
I agree thinking out loud is a way to get this information but it can put candidates at disadvantage. Also, it is not the only way.
As for prompts/clues, the interviewer has control over what they ask and how they ask. Further, if clues are a concern, then they could keep a tally of the prompts and score the candidate up/down based on the number of prompts.
To me, the interview is about understanding why the candidate is doing/proposing what she is doing/proposing. So, while they may not arrive at your expected solution, I am interested in knowing if they employ good tactics/approaches/methods to understand the problem/solution space and arrive at/improve a solution.
You mention valid aspects to asses. But, why do you think "thinking out loud" is better than "having a conversation with pauses to select, edit, and arrange thoughts before verbalizing them" to assess these aspects?
Yes, interruptions are annoying. A simple solution is to have a conversation with pauses to select, edit, and arrange thoughts before verbalizing them as opposed to verbalizing every thoughts.