Being a better interviewer is important. As stated, some types of questions aren't good judge of skills, like implement mergesort. If you can implement mergeso

Being a better interviewer is important. As stated, some types of questions aren't good judge of skills, like implement mergesort. If you can implement mergesort, you probably studied up for your interview. You're not testing anything, other than did the candidate care enough to study. Interviewing should test the candidates ability to write code that is: 1. Correct (solves the problem) 2. Efficient (solves the problem without unnecessarily wasting resources) 3. Understandable (goes hand in hand with maintainable) 4. Maintainable (can be modified by another developer, or even yourself after a few months) Coding on a computer can lend itself to all of these (no brainer there), but you lose a key aspect of whiteboarding that I think is really important--how a candidate approaches solving a problem. Knowing how to implement merge sort, or memorizing every possible linked-list question isn't all that valuable--but having a concrete approach to tackling problems is, and I want to understand that process from my candidates. I want to know the design tradeoffs you make, how you think about optimization, how do you reason about constraints as you learn about them. It seems that explaining your process while coding on a computer would be difficult to do without practice--and if you're going to practice, why not instead just practice whiteboard coding, which is how most tech companies interview.