No tags yet.
The Most Important Part of Your Interview - Checking In
White-board coding is a staple of software engineering interviews. Typically the engineering candidate is given a coding challenge and asked to share their solution on a white-board. I’ve observed dozens of these and two stand out.
The first: A senior software engineer was interviewing a candidate with about 5 years of experience. Before the coding challenge I witnessed a slightly awkward verbal exchange; the candidate was trying too hard. He answered quickly, but wasn’t providing much depth.
We moved to the white-board challenge and the interviewer explained the problem to solve. With a quick head nod the candidate grabbed a marker, turned his back and started writing away.
Save for the sound of the marker writing on the white-board, the room was quiet and continued that way for over ten minutes. Lines of code were stacking, as the candidate worked fast and hard on the code. Finally he stopped, turned around and made eye contact with the Senior Engineer.
The Interviewer’s feedback was simple - “It’s Wrong.”
The interview was essentially done - I picked up the pieces with the disheartened candidate and wrapped up.
Fast-forward a few weeks, we decided to meet with a promising recent graduate. The same senior engineer asked the same question as I again sat in. The recent grad looked nervous when he got the challenge and asked several questions to get more context. The interviewer answered the questions but not in detail. It was up to the candidate to figure it out.
The recent grad candidate walked slowly to the white board, turned his back to us and stood there for a few seconds - no writing. He turned around and said “I’m going to start out this way”. He paused to wait for feedback. The only answer was a non-committal “OK” from the interviewer.
He turned and continued slowly writing his line of code, staring at each word intently. This was going to take awhile.
At the end of his first line, he turned around and said, “I’m going to go in this direction” and received another monotoned “OK”. This process of think, write and talk went on for the better part of 15 minutes. And there weren’t many lines of code.
I started to watch the interviewer’s body language, he was not annoyed. He was engaged, though quiet, even as the recent grad was actually sweating. I made eye contact with the interviewer and gestured at my watch. He told the candidate to stop - even though the exercise wasn’t done.
The Engineering Interviewer validated the approach was sound, though several steps were missing. But the information was shared collaboratively and with a positive tone.
The candidate and interviewer talked through the rest of the challenge. I wrapped up with a tired but upbeat candidate and later convened the interview team. The decision was a unanimous hire, even though the team was seeking a more senior engineer.
Though the recent grad knew less than the more experienced engineer - he was hired because he checked in. The interviewer understood his thought process; it aligned well with the rest of the team.
That was three years ago and that recent grad mopped on to a large tech company and is thriving.
The objective of an interview, (or any other conversation): the parties align. Alignment is the candidate and interviewer are exchanging relevant information that you both understand. Too often, as we saw in the first example, that candidate assumed he had the right answer and plowed forward. It’s only when done do you see the errors he made; They were completely avoidable.
The junior candidate frequently checked in, along with showing his thought process as he worked on the problem.
The ability to check in was the difference in getting hired. A junior candidate showed his ability. That's the beauty of checking in, you communicate better and you know where you stand.
Checking in is powerful because it helps make sure the information being shared is understood. So often we focus on information delivery and neglect to check if it's understood.
One of the places I learned to check in was in the early days of my career when I was teaching a complex computer system to health care professionals. I'm one of those people that loves to share, it's part of my DNA. I’d speed through the delivery only to observe a sea of glazed eyes. I realized I had to validate that every student had processed the basics of the information I was sharing. For me that was the birth of checking in.
Today I check in in almost every conversation I have. It is now part of my DNA. I find that I equally focus on both what I share and what I hear back when I check in.
In coaching sessions I check in two ways:
First, if I share any significant content, I'll ask does that help or does that make sense. I'll make sure to incorporate their questions or concerns and re-share the information to make sure it's understood.
Second, I'll often restate what I've heard to make sure I'm clear. That's also checking in.
The result is smoother, meaningful dialogues where lots of information is shared and understood.
I do this with coaching clients prepping for interviews or big presentations. Each time they finish providing an important point, they check in.
Example checks ins:
Was that what you’re looking for?
Does that help?
Was that clear?
Anything else I can add?
Additionally, we work on doing a generic check in several times during the interview. Using similar samples from above, periodic interview check-ins helps keep the interview on track and aligned.
If you’d like to discuss the ideas in this post or other areas where Coaching might help - I’d love to help.
My email is mike@mikecoach.com.
You can also book a free hour session on my calendar from this link:
