I will admit that being watched is not my favourite way to code — I’m not, by habit, a pair programmer.
However, I disagree that this is not a true-to-life scenario. Software engineers working on live, production code are often called upon to understand and solve tricky problems in a short amount of time, because it’s affecting live customers. Being able to craft a working solution on the fly is as much a part of our job as crafting more thoughtful, long-term solutions that will hopefully minimise the number of times we have to do it the other way!
Put another way: sure, if we were all perfect, we’d have thought our way through all the contingencies over a period of several days as we gradually built a test-driven, bullet-proof solution. But we’re not all perfect, and contingencies get past the best of us. And then, we have to think fast and produce something that works.
And in every live-coding-exercise scenario I’ve ever participated in for interview purposes, that’s all they wanted. Not “clean”, not “perfect”, not even “correct” in a Computer Science sense. But working to the specification provided.
More to the point, every one that I’ve participated in hasn’t even cared all that much about working. They wanted to see how I approached the problem, how I searched out solutions to things I didn’t know off the top of my head (including not having API calls memorised), in short, how I worked, and how I thought.
Example: This most recent round of interviews for me, I flunked one job I really wanted because I let myself get stuck on something that I legitimately should not have. I flunked not because I was under pressure, and not because the problem I was being asked to solve was in any way unrealistic, but because I legitimately missed something I really should have seen. All on me.
Now, I suppose I could say that it was “unfair”, because on a different day I might have been more “on my game”. In fact, the job I wound up getting was in large part because that was the case — I was totally on my game the day I took their coding exercise. But the truth is that I look at how I got stuck on the problem and I simply shouldn’t have, and that was a learning experience and now I move on.
And, getting back to your original point, doing it on a whiteboard instead of as real live code wouldn’t have made it remotely better. I still would have gotten stuck on the same problem, because it was a problem in how I was thinking about the situation and not a problem of what medium or language I was using to solve it.
Whiteboard coding is terrible. Nobody in the real world (at least, the real world I live in) whiteboard-codes in their real daily lives. Give me a coding exercise in front of a computer any day of the week over a whiteboard.
