Job seekers often wonder whether something they did matters to hiring managers. Does it matter that I attended an elite college? Does it matter that I didn’t? Does it matter that I volunteered for the UN? Does it matter that I chose advanced algebra over advanced calculus?
The answer to all of these questions is always “yes”. Everything you did in the past matters to hiring managers. For them, you are the sum of your past decisions. Everything they know about you shapes their opinion of you consciously or unconsciously. It also matters whether you disclose this information. Putting your Eagle Scout achievement on your resume is a signal but so is omitting it.
Now do any of your past decisions impact hiring managers positively or negatively? That’s difficult to say. It’s like asking what people like in their partners. Different people value different traits just like different hiring managers value different accomplishments.
There are certainly trends. It is usually better to attend an elite university than to an unknown state college, but some hiring managers prefer the School of Hard Knocks. It is usually better to have some internships under your belt before applying for a full time job, but some hiring manager never did internships either and don’t care. Some hiring managers prefer hackathon participation. Others prefer you spend your Sunday mornings at the local soup kitchen. Some hiring managers are freemasons. Play your mason membership right and you may get the secret handshake and an instant offer to join the company.
Every decision you have ever made matters to hiring managers but for any particular hiring manager it’s a crap shoot. If you don’t know about the hiring manager’s values, put accomplishments on your resume that you are proud of and hope they resonate.
There are three kinds of candidates who fail software engineering interviews for technical reasons.
There are those that don’t know how to write code. Sorry but that’s a requirement for software engineering jobs.
There are those that can write code but are unable to come up with good ideas to solve the given problems. Difficult to judge why this goes wrong. Maybe just a bad interview.
There is a third kind of candidate that is particularly maddening to watch. Those are the candidates that propose great solutions and write confident and skilled code. However, the code they write doesn’t match their proposed solution at all. They might propose a perfect solution using a tree and breadth-first search but then write code that uses a binary search over a linked list.
Candidates of the third category are a rare breed but I see them often enough to wonder. How is it possible for evidently experienced and talented candidates not to see the complete disconnect between their proposed solutions and their implemented solutions? Is it just the nerves?
The common wisdom is that syntax errors don’t matter when you’re up on the whiteboard for a programming interview. Who cares about unbalanced parentheses or a missing semicolon? Who cares if you forget a cast before passing a value to a standard function? The common wisdom is wrong.
I used to tell candidates not to worry about syntax mistakes. I did that until I had interviewed so many candidates that I realized that maybe 5% of them write whiteboard code without making syntax errors. The astuteness and precision of these candidates is inspiring. All things equal, if you make syntax errors on the whiteboard, you’re already behind.
I noticed a second issue when writing up interview feedback. When I transcribe whiteboard code, tiny errors like a missing semicolon turn into comparatively large problem descriptions like “// missing semicolon”. That’s 20 characters of problem description for a one-character error. I have to jot that down so feedback reviewers don’t think I made that mistake during my transcription. On the other hand, if the candidate only finds the naive solution instead of the dynamic programming solution I need just one sentence for that. That’s maybe 500 characters of candidate weakness summarized in 100 characters of feedback; a problem to description multiplier of 0.2 instead of 20 for the missing semicolon.
Of course, only finding the naive solution to a problem is a much bigger issue than a missing semicolon but how do feedback reviewers subconsciously process that? Do they think of the missing semicolon as a much bigger issue because the problem description takes up comparatively much space?
I now tell candidates that syntax is not the most important thing but they should still try to get it right.
If you write Java or C++ code during a whiteboard interview you are probably doing it wrong. There are good reasons to choose Java or C++ for whiteboard interviews. Maybe your interviewer asks you to use one of these languages. Or maybe you know that one weird Boost trick that C++ standard authors hate. If you don’t have a very good reason, stay away.
Time is very precious in interviews. How much time do you usually have? Forty-five minutes? Sixty minutes? How much of that is left after small talk with the interviewer and discussing the problem? Thirty minutes? Maybe thirty-five minutes? Unfortunately, you are really slow handwriting code on a whiteboard. Don’t waste time on a programming language with a lot of syntactical overhead. Tokens per minute matter. Pick a language like Python to write denser code faster.
Donnie Berkholz crunched the data and tried to come up with a metric for the expressiveness of programming languages. Without discussing the validity of this particular metric, I like the idea. For a whiteboard interview please choose a language that’s far to the left side on Donnie’s results diagram.
Now you might say that other things matter more in an interview. Maybe think more before you write code. Yeah, maybe. Maybe whiteboard interviews are a terrible idea to begin. Yeah, maybe. Maybe you have other complaints about the common software engineering interview process. Yeah, maybe. None of these matter when you’re standing in front of a whiteboard, black marker in your hand. These things are also outside the scope of this post. Maybe I’ll cover them in the future. Yeah, maybe.
I see too many candidates who choose to put themselves at a disadvantage by voluntarily using a syntactically heavy language at the whiteboard. Don’t be one of them.