In Defense of Whiteboard Coding | Jacob Kessler | LinkedIn



In Defense of Whiteboard Coding | Jacob Kessler | LinkedIn

Recently, I've been involved with some discussions around replacing LinkedIn's 'traditional' whiteboard coding modules (two sessions of one hour each) with computer-based coding, and one of the comments that was made in support of computer-based coding bothered me enough that I thought that I should write a post about why it bothered me, and maybe start a discussion about it. That comment? "Whiteboard coding is unnatural".

The particular phrasing there struck me, but it's part of a larger argument against whiteboard coding that I've seen cropping up from time to time, which says that what the coding that we (as software engineers) do in our day-to-day jobs doesn't at all resemble what happens on a whiteboard, and we should change the coding portions of the interview to better reflect the style of coding that we do. It's a seductive argument since, in the end, isn't the purpose of an interview to determine if you can perform your job at the required level, and isn't the best way to test that to simulate the work that you would be doing and see if you meet (and hopefully exceed) some bar?

I'll let that bounce around for a bit and go on a tangent about what's being discussed here, since I've also seen a lot of different ideas about what a computer-based coding interview 'should' look like. This is specifically around replacing two hours of writing code on a whiteboard with (approximately) two hours of writing code on a computer. This isn't about take-home coding exercises (those tend not to go over well with people pursuing multiple opportunities and more-experienced people, both types of people that LinkedIn is looking for), or 'hackday' interviews (A full-day interview which is basically 'build a cool feature, then explain it to us'. It goes over well with product-oriented people and not-so-well with people who aren't). I'll also note that LinkedIn has tried computer-based coding interviews[1], and we abandoned them partially because we were having trouble with too few people passing them and partially because of the effort to maintain the coding environment, especially around multiple languages. So, I've had at least passing experience with it in actual interview situations and I'm not just arguing from ignorance.

Alright, back to the discussion: Is whiteboard coding unnatural, and should we change it? To the first part, I say "Yes, it is.". Whiteboard coding doesn't resemble my day-to-day coding in any real sense. I don't think that there is any way to defend a position that it does: You're writing without any of the tools or techniques that we have developed to improve our abilities, and as much as we might try not to, our coding styles are shaped by and around the tools that we use. People are used to using autocomplete, library references, syntax checking, unit tests[2], and a host of other tools when they code. None of those can be used in a whiteboard coding interview, and I've heard from many people that a major part of interview preparation these days (in addition to picking up an algorithms book at your local college bookstore) is learning to write code on a whiteboard.

But, I would claim, the entire interview process is unnatural. I will never in the course of my daily work (I hope) be writing code, under time pressure, while being watched by someone who not only knows better ways to approach the problem than I do, but is also going to shortly decide if I will continue being employed. If I were asked, in the course of my daily work, to write a function that computes integer powers I would need a very good explanation of why I wasn't using a built-in power function rather than trying to write my own. If someone asked me to design the architecture for a website to play Hangman, my first response (after clarifying what they actually meant) would probably be to spend a few days bouncing ideas off other people rather than trying to write a good architecture up from scratch. Even among the biggest fans of pair programming, speaking your every thought out loud as you are programming isn't something that you would do - it would interrupt your own thoughts too much.

Read full article from In Defense of Whiteboard Coding | Jacob Kessler | LinkedIn


No comments:

Post a Comment

Labels

Algorithm (219) Lucene (130) LeetCode (97) Database (36) Data Structure (33) text mining (28) Solr (27) java (27) Mathematical Algorithm (26) Difficult Algorithm (25) Logic Thinking (23) Puzzles (23) Bit Algorithms (22) Math (21) List (20) Dynamic Programming (19) Linux (19) Tree (18) Machine Learning (15) EPI (11) Queue (11) Smart Algorithm (11) Operating System (9) Java Basic (8) Recursive Algorithm (8) Stack (8) Eclipse (7) Scala (7) Tika (7) J2EE (6) Monitoring (6) Trie (6) Concurrency (5) Geometry Algorithm (5) Greedy Algorithm (5) Mahout (5) MySQL (5) xpost (5) C (4) Interview (4) Vi (4) regular expression (4) to-do (4) C++ (3) Chrome (3) Divide and Conquer (3) Graph Algorithm (3) Permutation (3) Powershell (3) Random (3) Segment Tree (3) UIMA (3) Union-Find (3) Video (3) Virtualization (3) Windows (3) XML (3) Advanced Data Structure (2) Android (2) Bash (2) Classic Algorithm (2) Debugging (2) Design Pattern (2) Google (2) Hadoop (2) Java Collections (2) Markov Chains (2) Probabilities (2) Shell (2) Site (2) Web Development (2) Workplace (2) angularjs (2) .Net (1) Amazon Interview (1) Android Studio (1) Array (1) Boilerpipe (1) Book Notes (1) ChromeOS (1) Chromebook (1) Codility (1) Desgin (1) Design (1) Divide and Conqure (1) GAE (1) Google Interview (1) Great Stuff (1) Hash (1) High Tech Companies (1) Improving (1) LifeTips (1) Maven (1) Network (1) Performance (1) Programming (1) Resources (1) Sampling (1) Sed (1) Smart Thinking (1) Sort (1) Spark (1) Stanford NLP (1) System Design (1) Trove (1) VIP (1) tools (1)

Popular Posts