Developer-tools firm JetBrain (which is also responsible for the Kotlin programming language) recently surveyed 5,000 developers about their work habits. Some 44 percent of those surveyed said they used source-code collaboration tools (such as GitHub, GitLab, and Bitbucket) constantly throughout their workday. If you’re a developer, that data-point is perhaps unsurprising. But it also reveals one of the core issues with the whiteboard interview, a tool that many firms still rely upon to hire developers. If you’ve ever undergone a whiteboard interview, you know it’s liable to send your blood pressure skyrocketing. You’re presented with a complex coding question, an erasable marker, and a time limit for solving the first with the second. You can’t use your phone or a PC to look anything up. And for many developers, it’s easily the worst part of the whole hiring process. Like many standardized exams, whiteboards tend to test candidates’ skills at rote memorization and process. But any developer knows that a big part of the job is creativity and improvisation, especially when building new, complex platforms. Who cares about memorizing code snippets when you can just look it up in under a minute on GitHub or another Website, and use that information to create something that’s actually useful (or at least entertaining)? A number of firms seem to have recognized the issues with whiteboarding. Earlier this year, a list started on GitHub of those tech firms that no longer force job candidates to face a whiteboard, relying instead on examinations that mimic day-to-day work. A take-home exercise is a good way to judge a candidate’s aptitude for problem-solving, as is a real-world problem in which the examiners give full access to the Web. (The list of companies has actually grown quite lengthy over the past several months.) It seems unlikely that whiteboard tests will fade away anytime soon, meaning this dichotomy between how developers work and how they’re tested will likely perpetuate for some time. For some tips on navigating the not-infrequent requests to whiteboard a problem, check out Dice’s short guide. The Biggest Drawback of Whiteboard Interviews
Developer-tools firm JetBrain (which is also responsible for the Kotlin programming language) recently surveyed 5,000 developers about their work habits. Some 44 percent of those surveyed said they used source-code collaboration tools (such as GitHub, GitLab, and Bitbucket) constantly throughout their workday. If you’re a developer, that data-point is perhaps unsurprising. But it also reveals one of the core issues with the whiteboard interview, a tool that many firms still rely upon to hire developers. If you’ve ever undergone a whiteboard interview, you know it’s liable to send your blood pressure skyrocketing. You’re presented with a complex coding question, an erasable marker, and a time limit for solving the first with the second. You can’t use your phone or a PC to look anything up. And for many developers, it’s easily the worst part of the whole hiring process. Like many standardized exams, whiteboards tend to test candidates’ skills at rote memorization and process. But any developer knows that a big part of the job is creativity and improvisation, especially when building new, complex platforms. Who cares about memorizing code snippets when you can just look it up in under a minute on GitHub or another Website, and use that information to create something that’s actually useful (or at least entertaining)? A number of firms seem to have recognized the issues with whiteboarding. Earlier this year, a list started on GitHub of those tech firms that no longer force job candidates to face a whiteboard, relying instead on examinations that mimic day-to-day work. A take-home exercise is a good way to judge a candidate’s aptitude for problem-solving, as is a real-world problem in which the examiners give full access to the Web. (The list of companies has actually grown quite lengthy over the past several months.) It seems unlikely that whiteboard tests will fade away anytime soon, meaning this dichotomy between how developers work and how they’re tested will likely perpetuate for some time. For some tips on navigating the not-infrequent requests to whiteboard a problem, check out Dice’s short guide. 
