You might think that offering the wrong solution to a problem during a whiteboard interview can ruin your chances of landing the job… but it’s not the worst mistake you can make.

We recently asked three engineering leaders to describe the most common mistakes they see developers and engineers make during technical interviews. They unanimously said that the most frequent mistake candidates make is working through the solution to a coding, systems design or algorithm problem in their heads instead of verbalizing their thoughts.

In fact, evaluators are interested in your thought process, the alternatives you considered and how you arrived at your conclusions. That gives them crucial insight into how you solve problems, and ultimately whether you’ll be a good fit for their team.

With that in mind, how can tech pros go from internalizing their problem-solving process to externalizing or working through a problem out loud? Using a discussion guide as a roadmap can help you flex your approach, impress the evaluator, and present solutions to whiteboard problems in a clear, compelling and confident way.

Step 1: Normalize Your Processing Style

Start by recognizing whether you are an internal or external processor.

Engaging in an impromptu discussion can be particularly challenging for internal processors who need to think things through before providing a response, explained therapist Melissa Shaw. Most hiring managers are external processors, and the two thinking styles conflict, she added.

When the internal processor does not respond the way the hiring manager wants or expects, the latter may misinterpret that as the candidate not caring about the answer or even the interview.

You can normalize your internal processing style by asking for time to think things over before turning toward the whiteboard. “It’s okay to say I need a moment,” Shaw said. What you don’t want to do is leave the evaluator staring at the back of your head for an extended period of time.

“Many candidates are reluctant to talk because they feel intimidated or think that asking questions is a sign of weakness; they need to flip the script,” said Tom Gilmour, a former senior engineering manager and current instructor at Interview Kickstart.

You can get past your mental roadblock by treating the hiring manager as a business partner or a stakeholder who requests a significant change or modification. You may begin to feel more decisive and comfortable leading the discussion and asking questions by changing the way you look at the situation.

Step 2: Understand the Problem

Don’t blurt out a solution or start coding right away. Managers are looking to see how you interact and understand the requirements for the task.

Relax and read the problem first. Where do you see possible edge cases? Does the problem description include a recursive pattern, or does it talk about some relationship? Can you apply modified binary search? What else do you need to know to solve the problem?

Then, turn and face the manager, open up your posture (which will open up your personality) and clarify the problem the evaluator wants you to solve.

Step 3: Clarify the Problem

The next two steps are critical for building trust and rapport with the evaluator.

Always seek clarification about the business requirements and the end goal; validate any constraints or assumptions, even if you think they seem clear.

There’s not always one right answer to a whiteboard question, and it’s important to show the hiring manager that you consider the whole picture and strive to solve problems in the most efficient, resource-effective manner. Plus, validating your assumptions and creating alternative data to clarify the business requirements allows you to write the test and then write only the amount of code needed to pass the test, Gilmour pointed out.

Shaw recommends mirroring the evaluator’s style. Matching the evaluator’s body language and repeating their words or phrases shows that you are paying attention and are engaged in what they are saying.

Step 4: Describe Your Approaches

Next, highlight your problem-solving skills by walking the evaluator through the approaches you think are best for solving the problem, being sure to explain the pros and cons for each option.

What’s most important is to explain “why” for each solution you suggest, Gilmour said. The evaluator wants to know why you make certain coding choices. At the same time, leave yourself open to changing your opinion.

Thinking out loud will encourage the evaluator to switch to “mentor mode” and share feedback. Most interviewers will give you subtle clues as to whether you’re on the right track or not, giving you the chance to re-adjust your game plan. Ideally, the two of you should agree on an acceptable approach.

Step 5: Create a Plan and Code the Solution

Take a few minutes to jot down a brief plan on the whiteboard, then code the solution using self-documenting code and best practices for the language you’ve selected.

Don’t proceed in silence. Articulate your thought process as you work the problem, explaining your reasoning and any trade-offs you are considering or optimization techniques you are using. If you get stuck, explain what you’re thinking about doing so the evaluator can potentially give you a hint.

Step 6: Review Your Work

After you think you’re done writing a solution, walk through the code in detailed steps to catch errors and correct them. Put in a couple of tests to make sure your code works. Your final code should be detailed and well-written.

Step 7: Explain Your Solution

When you’re finished, offer to walk the hiring manager through the solution at the highest level, explaining what each section of code does.

Talk about time and space complexity based on the code you've written and why you chose to solve the problem this way. Then ask for feedback and be ready to make changes to your solution if needed.

While you have to be flexible in an interview situation, following a discussion guide can help you learn to externalize your thoughts and let your technical knowledge shine through when it matters most.