These days software engineering interviews have seemed to morph into an all out technical question barrage. My typical phone interview usually consists of an awkward phone greeting where we both ask “how are you?” at the same time only to then answer “good” at the same time. After chatting about my past internships for a few brief minutes, we begin the coding challenge. My heart races a bit, but then I usually realize that this is not a hard problem and one that is purely used to see if I can write code at all (obviously if I fail to complete this task then I must not be able to write any code and have squandered my four years in college). Then the conversation comes to an end; I ask a few questions and try and mix it up to see if I can get an interesting answer. My favorite was when I asked my interviewer if he liked working there and he replied “Eh, it’s a job.” Fair enough, fair enough.

Then, if I succeed in wooing my interviewer, I’ll get invited to an onsite interview, usually for a grueling 4-5 hours in San Francisco. Plus the Caltrain trip, which costs something like $14 round trip now, and that’s two chipotle burritos with chips! Once I’m there, I’ll get drilled again and again on all sorts of trick problems. Sometimes a product guy will come in and we’ll talk about where the company is headed and all that stuff. At the end of the day, I’ll go home and either get a job offer or never hear back. And that’s that. I’ve only been in one or two interviews where it varied significantly from this format.

I can’t help but think that this is a really backwards approach to recruiting ideal employees and is only useful at recruiting pure coding talent. I’m onboard with the phone interview process. Sure, you have to check to make sure this person can write code (maybe just look at his or her github/previous work?). However, these onsite interviews baffle me. Coding on a whiteboard while someone is breathing down your neck? This is the far from real coding. Maybe you’ll find a candidate who is good under pressure and can breeze through the implementation of a new kind of hash map that no one has heard of. Different people code in different ways. Most people use Google, references and other resources to figure out coding problems. Most people also test their code by actually running it on the computer. So what does coding on a whiteboard do? One could argue it “shows” the interviewer how the interviewee thinks. Honestly, I never feel the same when coding on a whiteboard and I’ve only gotten better at it because I’ve done so many interviews.

All that being said, interviewing and finding the right candidate is extraordinarily hard to do in four hours. The current process is definitely an imperfect solution, but it does have its merits. If a candidate zips through the whiteboard challenges, then yeah, he might be a good coder.

Ultimately though, I wholeheartedly believe companies are focusing on the wrong  aspects. Things to be sought after are character and communication skills. I’d argue they’re far more important than some coding chops or a pretty looking degree. Coding, data structures and algorithms can, for the most part, be taught. Character on the other hand, well, I don’t believe Coursera offers a 10 week course on that.

So why character? This has always seemed like a no-brainer question to me. Throughout my career as a gymnast, I’ve watched the most talented gymnasts fall from grace because they no longer put in the effort at the gym. Without hesitation, I would take a hardworking gymnast on my team over the slacker but extremely talented gymnast; I would hope most people would. Perhaps gymnastics is a bit different from software engineering, but I don’t think it’s too much of a stretch. Talented coders are a dime a dozen; it’s the intangibles like work ethic, even-temperedness and perseverance that transform a talented (or not so talented) coder into an ideal software engineer. Yet, companies that offer me jobs or reject me know very little about my character — who I am and what I value. At  my previous internship at Ooyala, the CEO would talk about keeping the ego to smartness ratio in check, and he’s damn right. A few big egos can literally ruin a team, no matter if they can code Kruskal’s algorithm iteratively blindfolded on the whiteboard. But no one checks for big egos in an interview.

Lastly, communication — the jelly in the peanut butter sandwich that makes it possible to swallow. As much as us software engineers have tried to hide ourselves from the world of communication by waddling around knee deep in python code, there is no escaping it. Working at a company means working with a team. Even if Google snags the mutant who can devote all 100% of his brain to coding, if he cannot explain what he has done, how to use it or how it works, then I’d argue he’s of no value. Imagine having that brilliant engineer write some brilliant piece of code. Then he leaves to start a start-up. If no one knows what he has done and there happens to be a bug, well, I guess you’re up a creek without a paddle! Communication is indirectly tested for in interviews by having the interviewee explain his or her solution, but often times the code speaks for itself and interviewers are just making sure that his or her communication skills aren’t really  bad.

Finding character and communication skills are not easy tasks and nothing can be assured of in a four hour interview, but I propose talking to the candidate, you know, like an actual conversation — figure out who he or she is, what lights his or her fire. Talk about things besides what he or she has coded in the past or will code in the future. I’m not saying drop all technical questions (I enjoy the challenge), but spending maybe one of those hours just getting to know the person you’re interviewing might be beneficial.