I just had my first experience with an algorithm-focused white-board coding interview. It was… interesting. I reflect on my responses and reactions, and have some thoughts on the nature of technical interviewing and candidate assessment
So, I had my first white board session as part of an interview yesterday. I don’t have any real read on “how I did” in terms of what the interviewers were expecting, but I wasn’t at all happy with my performance. I think I did a reasonable job of talking/reasoning my way through the approach I took, of assessing the performance and trade-offs of approaches I considered, and of rejecting a few unreasonable trains of thought. But I overlooked some really fundamental, basic, and (in retrospect) obvious approaches that came to me in flashes later in the day — one on the car trip home, another as I was settling down to bed.
Without giving out all the details (it was a basic enough problem, and no one asked me not to share it, but still…) the problem involved a quantity of both existing and of new data, all of the same type. It was data that was comparable, and had hash and equals methods amenable to the operations involved in sorting, matching, etc.
The most basic thing I overlooked entirely was that I did have (in a key part of the problem) data that could be sorted and that, once sorted, could be evaluated with a simple binary search. Why did I neglect this? I think in part because, in my interview-question inexperience, I had worked myself into a state of looking for more complexity than there really was. I ended up articulating a solution that would be both more cumbersome to implement and, while probably faster for a fairly wide size range of inputs, asymptotically inferior. The “should have thought of it” solution could do even better than sort and then search if I had built a binary search tree — something I didn’t get to even after evaluating and rejecting a more complex and unwieldy tree-type approach — although the implementation details of this would be more involved.
And, then, as I was going to bed last night, a hash-table-based approach to the entire program popped into my head that I was really happy with. It would be extremely easy to implement in code and relatively high-performing. Oops. Ultimately, of my belated solutions, the binary search approach could work better if there was any additional reason that it was useful to have the data be easy to display in sorted order. The HashMap approach had the merit of reducing an “inner loop” to a constant-time hash lookup and would therefore be especially beneficial with large sets of new incoming data.
But, apart from my own performance (or lack of it), I came away with some thoughts about this process. One is that the whiteboard feels really artificial for anything apart from picture-drawing. Which is useful. But I should work on getting more comfortable writing code or pseudo-code snippets on the white board, too. Another is that I am pretty sure I would have arrived at better solutions, in the same time, sitting at a keyboard. Alone, or possibly also with the interviewer looking over my shoulder. I’m not sure why: whether this is a familiarity issue as well, or if something else is going on.
Also, while my post-Bootcamp self-directed data-structures self-study has obviously gotten me to some level of familiarity, and I’m continuing to learn and to learn very quickly, it hasn’t gotten me to the level of intimacy where thinking and reasoning in terms of well-known data structures is, yet, second nature to me. Lastly, and this is really something for a follow-up post, but I’m very interested in the whole idea of technical interviews (either coding interviews or the kind with “quiz questions” about technical topics) in candidate assessment. I come out of a profession where academic-style interviews, which are often multi-day extravaganzas with job-talk presentations and lots and lots of separate conference room sessions, nonetheless lack any comparable focus on, and belief in the testable nature of, an ability to “do things.”