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.

1. 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.)
2. 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?
3. 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?
4. 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?
5. 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?
6. 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