//Communication

“Now I want to you write me some code to solve this problem …”

This line is either the most exciting or most terrifying moment of an interview for a programming job. The dreaded “coding question” is the focus of so many books, articles, and presentations about interviews in software engineering. Personally, I have come to enjoy the programming problems because they are not unlike the CodePSU and ICPC style questions that I do for fun, but the pressure of having to write code by hand in front of an interviewer is sometimes great. The truth of the matter, though, is that the interviewer isn’t only looking for a correct solution; they are also looking for how you get there.

Understanding code is not necessarily a hard thing to do. Almost anyone with a coding background can follow simple commands without any needed explanation. So then why is it necessary to explain the code we are writing on the board or on the page when in front of an interviewer? The answer is simple: communication.

Almost invariably, introductory programming teachers talk about how code needs to be commented properly. And almost as invariably, programmers ignore their warnings. “It takes too much time” some say, while others claim “This code is obvious… why do I need to comment it?”. But what is obvious to you at one moment may not be obvious to others in the future. I had the opportunity to go back through some of my old high school code, and I focused especially on my old personal projects, as that was where I put the most ingenuity and effort. While I generally understood what most of the code was trying to do, there were some sections that were cringe-worthy at best. I only understood those sections because I am now a far better coder than I was back then and I was still the original author of it. Few others would’ve taken the time or effort to decrypt the enigmatic commands and even fewer still would’ve had the patience to build upon it. While this means very little to my high school projects: small, fun, one-time endeavors that will probably never be improved upon, cryptic code could be really impede to a larger project.

In this way coding has a few things in common with leading a group. Both require some general command, be it “let’s all pitch in to fulfill some job” or “double = lambda x: x * 2 “, and both would require no extra commentary to fulfill those commands if everything works the way it’s supposed to. But just like how code without commentary has the original intent of the code lost very quickly, commands from a leader without good communication can also be taken out of context and their intent be lost as well.