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.
Is someone’s ambition an asymptote to their goals? Here’s what I mean: Is someone’s ambition trajectory bigger when they’re far away from their goals but diminishing the closer they get to them? This occurred to me talking to someone else that shared this experience. We agreed that we both are close to what we had longed for ten years ago. Now that we’re nearly there, what to aim for next?
The general consensus seems to be that people get less ambitious as they get older. Let’s assume that’s true. Is that because people settle after they realize their goals are not attainable? Or is it because they are closer to their goals from, say, ten years ago and – due to the law of diminishing returns – are not willing or able to completely achieve their goals without a disproportionate effort.
If ambition is asymptotic to goals, do people that start out with loftier goals have an inherent achievement advantage over people with modest goals, just because their ambition asymptote is accelerating for a longer time before slowing down? People with modest goals usually come close to achieving them fairly quickly. Does ambition just fizzle out at that point because you’re done?
Can people reset their goals and avoid falling into a slump? Obviously it’s possible. There are many stories of people who did something for decades only to quit their old lives and do something completely different. Still, just getting your ambition trajectory back from deceleration to acceleration seems like a tremendous undertaking. Can we plan ahead to avoid that? Can ambition be turned from an asymptote into something that doesn’t decrease the closer you get to your goals.
Do you know that feeling when there’s just nothing to do at work? That exact moment when you drift off into your thoughts and browse your favorite website? I vaguely remember it. It was a familiar feeling at previous jobs. I don’t experience it a lot anymore. I don’t think that changed only because my current job is busier than those I had before. I think I actively learned to avoid it.
What happened is that I became better at tracking things. It’s not so much that I have more work to do. In the past I just forgot the things that needed to be done. That’s an unfortunate situation to be in. I was bored at work because I thought there was nothing to do. But there were things to do. I just forgot. First I was bored and then I was angry about forgetting. Great times.
I am still not a good tracker of things. At least I have a to-do list now. It’s my customized inbox. I am in the sweet spot to get through most of it on an average workday. Inbox Zero doesn’t happen a lot. Maybe once or twice a quarter. Inbox Three happens nearly every day. The bug tracker still piles up requests but those don’t count.
Inbox Near-Zero is a mental boost. The small size removes the sense of overwhelming that huge inboxes have. It empowers because it makes the goal visible and seemingly in reach. Even better, when I am done with one task, I know what to work on next. I have completely eliminated the need to mentally recall things that needed doing. Those were the moments when I drifted off to my favorite websites. I opened them and suddenly half an hour had passed. Mental downtime accumulates without you noticing.
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.