Reverse Whiteboarding Part 2
Tags: interview
Published: 2020-05-27 07:35:40

---
title: Reverse Whiteboarding Part 2
published: true
description: How do I assess candidates after a technical interview?
tags: interview
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/0hx3qp4qm5b9yq7pvtt8.jpg
---
Photo by [ThisIsEngineering](https://unsplash.com/@thisisengineering)

I was recently asked on Twitter about an [interviewing blog](https://dev.to/grepliz/reverse-whiteboarding-3h6i) I wrote last year:

![Twitter](https://dev-to-uploads.s3.amazonaws.com/i/yqgjjgb7hopgqiraqwyd.png)

Although I commented in the Twitter thread, I'd thought I take the time to elaborate on a couple of things.

Direction vs. Participation
===========================
In traditional whiteboarding interviews, it is common for the interviewer to "lead" the interviewee towards a certain path.  This is usually the path to an answer they already know.  When you don't know the answer, you become a more equal participant.  You are just peers trying to solve a problem together.  

I don't deceive myself into thinking this makes everything stress free for the other person.  It's still an interview after all.  As far as I know that person could be falling apart inside.  They could be stressed about bills, family, or a myriad of other things.  I don't have a magic crystal ball to know their situation.  I can only try to provide an environment that is as relaxed and friendly as possible, giving the other person the best opportunity to shine.

I always let the other person start, but I also throw out my ideas as well. I usually use both pseudo code and real syntax so there is no pressure to get the code compiling on the whiteboard. 

Fun little fact: whiteboards can't compile code!

I try not to dominate the conversation and any "direction" I give is really done in a collaborative manner.  It's ok to disagree.  In fact, there have been times we both ended up with different answers depending on what assumptions we made.  There have been times when multiple answers were concluded.  There was one time, I got the answer completely wrong and the other person got it right (Yes, we ended up hiring her).
  
The purpose is to see how the person approaches problem solving with others.  Along the way, you pick up a sense of their technical skills and gain a glimpse of what it is like to work with this person. 

Assessment
==========
You might be thinking, "Ok, Liz.  That's nice.  But how can you really tell a person's technical skills without asking them to name, describe and whiteboard all the design patterns in the Gang of Four book? Or at least ask some basic data structure and algorithms questions.  Everyone should know how to traverse a linked list in JavaScript!"

This is not school.  

I'm not going to treat a potential coworker like it is.  If the person happens to have Computer Science degree, I will trust the university they went to tested them on such things.

Assessment is an interesting topic. People have different opinions on hiring criteria.  I start with the belief in the bell shape curve, that most people have the ability to do the job.  The observations I make during the interview helps me shape my opinion if the person is more on the junior or senior side.  This feedback is then shared with the rest of the team and we decide if those qualities map to the role we are hiring for.

Of course these types of Reverse Whiteboarding interviews were done in person before the COVID-19 situation.  It's May of 2020 and I'm in the San Francisco Bay Area.  We've been sheltering in place for over 2 months now.  I've conducted 3 interviews online since working from home and those experiences are a little different from what has been described above.  

Perhaps a topic for another day.