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 design interviews as well.
I understand this requirement helps gauge how well a candidate can communicate their thoughts. No doubt this is an an important skill; specifically, in a role that involves lot of interaction.
That said, I think this requirement imposes quite a bit of wastage.
- Not all thoughts associated with problem solving are worthy of communication. Do we really want the candidate to voice every thought? (Remember verbalizing thoughts is not the same as communicating thoughts.)
- While the ability to be selective about the thoughts to communicate is important, this selection process requires some thinking as well; hence, it shifts the focus away from problem solving. Why force the candidate to shift focus away from problem solving?
- If the interview is being conducted in English, then many non-native English speaking candidates may likely not think in English. If so, after forming a thought while solving the problem, such candidates will have to expend some mental effort to translate the previous thought into English before saying it. Again, beyond forcing candidates to shift focus away from problem solving, why put non-native English speaking candidates at disadvantage in terms of time?
- The same applies to visual thinkers. Left to their own devices, they could draw up pictures that capture their thoughts and then explain it. Instead, why ask them to explain the pictures as they are drawing?
- All candidates are not equal. Due to whatever reasons, some candidates may be more methodical and thorough. This requirement puts unnecessary additional demands on such candidates. Looking at it another way, the requirement asks such candidates to be a bit sloppy in the interest of time. Why demand sloppiness in knowledge-centric domain?
- Have you ever tried talking pretty much continuously for one hour? Now, imagine doing it for couple of hours in a row. Why expend energy on unnecessary talking?
Beyond the above limitations, I think the requirement is unrealistic as we seldom operate so while working.
Does your co-worker loudly explain the design/code that she is creating? If so, do you understand her explanation?
In my experience, even when team members meet to discuss an idea, most of the members who lead the discussion early on would have either 1) thought about and worked on the the problem and their solution or 2) experienced similar situations. As for those who contribute later on in such meetings, they do so after understanding and thinking about the solutions as the solutions are being described and discussed.
So, if we never think out loud while working, then why require candidates to think out loud?
This requirement seems to focus on the quantity of communication instead of the quality of communication.
Is there an alternative?
To get the most out of the 45–60 minutes of interview time, we can allow candidates to solve the problem as they would do naturally but without the use of information resources. This will paint a more accurate picture of how candidates operate while designing and coding on the job. To ensure candidates do not get stuck or lost, we can use regular prompting. If we are interested in the process of how a candidate arrived at a solution, then we can state this at the beginning of the interview and set aside time to discuss the solution as a whole and in parts along with the choices made while crafting the solution.
Originally posted on Medium
Top comments (17)
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.