WHY PROGRAMMING INTERVIEWS?
Why do software firms use programming interviews? They want to hire great programmers who can work well with others to successfully produce great products. Unfortunately, bitter experience has taught employers that a substantial portion of applicants for programming jobs simply cannot code. You might expect that these applicants could be screened out by careful review of résumés, experience, course work, and degrees, but in practice this often fails. A surprisingly large number of applicants with sparkling résumés and years of apparently relevant industry experience cannot accomplish even the simplest of programming tasks. Many of them have picked up enough terminology that they can appear competent in conversations about programming and technology. Hiring one of these “developers” who can’t code can easily sink a department (or even a small company).
Recognizing that traditional interviews are ineffective in identifying applicants who can’t code, employers took a logical step: ask applicants to do some coding during the interview. Thus the programming interview was born. Programming interviews are extremely effective at separating those who can code from those who can’t, which is why they are a nearly universal part of the technical interview process.
The difficulty with programming interviews is that employers don’t just want to screen out people who can’t code. Employers want to distinguish the best programmers from those who are merely competent. This is a more difficult distinction to make. Typically, interviewers try to measure an applicant’s ability by posing difficult programming challenges and noting how quickly and accurately the applicant solves them.
The problem with this approach is that due to the time restriction inherent to an interview, the skills that can be tested in a programming interview only partially overlap the skills that are relevant to real-world development. By necessity, programming interviews evaluate your ability to solve problems on the spot, with someone watching you, without the benefit of any of the references you would typically have available. There isn’t time to write a lot of code, so problems must have short solutions. Most problems with short solutions would be trivial, so to avoid this many interview problems involve unusual algorithmic tricks, absurd restrictions, or obscure language features. Because these types of problems don’t typically arise in real-world development, an excellent programmer who is unprepared for the peculiarities of the interview experience may appear to be unqualified.
Conversely, many skills essential to development in a professional environment aren’t assessed well (or at all) in programming interviews. These include communicating and working as part of a team; architecture and management of large codebases; time management and discipline to consistently produce reliable code on schedule; and the ability to tackle a large project, identify all the component parts, and carry the project through to completion.
Clearly, programming interviews do not provide a perfect measure of an applicant’s worth as a future employee. But to paraphrase Churchill’s assessment of democracy, it’s the worst form of technical interview except for all the other forms that have been tried. More to the point, programming interviews are the way employers choose who they will hire, so you need to perform well in them regardless of whether they are an ideal form of assessment. This book is devoted to teaching you how to adapt your programming skills to the peculiarities of interview problems and gives you the preparation and practice you need to shine in interviews so that you get the job you want.
