Eric J Ma's Website

I was recently conversing with a colleague, Srinivasan Varadarajan, about a co-op performance calibration we performed. During that conversation, we discussed the difference between communication and conversational skills.

The context was this: Srini and another colleague of mine, Zeran Li, were interviewing co-ops. There was one candidate that both liked -- they had great conversations with the candidate, who had a pleasant personality, and their 30-minute face-to-face time went smoothly and without hiccups. However, they also acknowledged that, even after the interview, they did not know whether the candidate had good technical skills.

It's hard to blame Srini and Zeran for this: the candidate had great conversational skills! The problem was that the candidate's conversational skills masked their ability to communicate about their work, making it difficult to make a judgment call about the candidate's technical skill. However, as someone who has been burned before -- I took on an under-skilled student based on being able to get along with that student -- I knew that they would be taking a very big risk if either of them were to hire this candidate.

I asked our campus recruiting colleague on the call if we could re-interview that candidate specifically for technical skills. Unfortunately, to ensure fairness in the hiring process, the campus recruiting folks didn't want us to engage in this. As a backup, I looked at the code repositories that the candidate had on their GitHub account. Still, the account was sparsely populated, with mainly generic forked repositories. Of what little original code (i.e. code committed under the GitHub handle), the candidate's code left very few hints that the candidate knew how to do basic organization of code, commenting, documentation of intent, and other signals of someone who is writing code that is intended to be shared with others. Though the final call was in Srini's and Zeran's hands, I advised them to continue looking. But I also told them that if they took on this candidate, I would be there for them if anything went wrong.

The interview was over a year and a half ago at this point. In the intervening time, I read Andy Grove's "High Output Management." In Chapter 11, he talks about a manager's "Two Most Difficult Tasks": hiring and retaining talented individuals. During the interview, we cannot waste our

only asset -- the interview time, in which you have to get as much information and insight as possible... The interview is yours to control, and if you don't, you have only yourself to blame.

A good conversationalist is not necessarily a good communicator; a good communicator will not always be a good conversationalist. But an interview that ends up being merely a conversation will waste both a hiring manager's and a candidate's time! A good conversationalist will make you feel like you were chummy pals by the end of the conversation, but a good communicator will leave you with a good grasp of what they know and how they think. A good conversationalist can leave you with warm and fuzzy feelings within an interview setting, but a good communicator will bring clarity in a concise format.

For this reason, my preferred interview format is to do a code review of what the candidate considers to be their best work. Not only is code review a proper simulation of how we work, but it is also a high bandwidth opportunity for candidates to communicate clearly what they know and think. By placing actual code up front, there's hard evidence of the candidate's technical skill in their work product. It leaves little room for the candidate to use conversational skills to mask technical skill deficiencies. In terms of evidence of technical skill, nothing speaks louder than a work product!