Programming Interviews Exposed [Paperback]

I just finished rereading this book, and read the earlier Amazon interviews. Though I agree with many of the observations in the other reviews, their judgments are mostly too extreme. This book is definitely of value, but reading it won't unlock the keys to any secret kingdom of guaranteed job-landing success.

I've been interviewing and hiring software developers for almost 15 years, and I know one thing you can be sure about software interview processes: their inconsistency. Interviewing and hiring practices for software development are all over the map. As a matter of fact, all software development practices are all over the map, and how you are judged a success or failure once you land a job are at least as subjective and error-prone as how you are evaluated in interviews.

Landing a particular software development job and being successful at it once you get it require a lot of learning about the particular mix of priorities and practices on each particular team, and fitting into that mix. You could be interviewing with a sixty-year-old toy manufacturing veteran doing tiny embedded systems, and any mention of object-oriented technology could be immediate grounds for a religious no-hire. On the other hand, you could be interviewing with a young hotshot at a new Silicon Valley startup. In this case you'd not only better be fluent with every aspect of object-oriented technology, best practices, and the latest open-source frameworks, but you'd better not make too much of space optimizations or "the overhead of a subroutine call" or you'll be branded as hopelessly old fashioned.

Consequently, the advice in this book is quite valuable about communicating throughout the interview, telling the interviewer the thoughts behind what you are doing and asking clarifying questions as you go. No book by itself can help you with any interview you might encounter. However, with all its flaws, this book does a better job than any other available book in discussing programming questions, how to approach them, and possible answers. The idea that only "recent grads" are ever asked general programming questions like this is hogwash. I hire veteran developers for high-end product development jobs almost exclusively, and I ask programming questions like the ones in this book all the time, and so do most of the good interviewers I know. I've found over the years that programming questions give me among the most direct and accurate assessments of a developer's skills. Asking programming questions is enough of a best practice that you should be suspicious of a technology company that doesn't include them in its interview process. (Hey, I said that development practices were all over the map, but I didn't say that most of them were any good. How else could the software industry achieve its miserable 40% success rate?)

As far as the books weaknesses, probably the biggest is that almost all the questions, answers, and discussion are in straight procedural C. It's hard to reason why this book shows such a lack of emphasis on object-oriented technology considering it had been the state of the art for 10 years when this book was published in 2000. So, though there are a few small examples of OO class designs thrown in, discussion is missing of important topics like inheritance, composition, encapsulation, and structured exception handling. Even when you are programming in an OO language, however, the logic inside the methods you write for these kinds of general exercises is mostly the same as you would write in a procedural language. So most of this book is relevant, but you must translate to OO on your own.

A more subtle and perhaps more important weakness of this book is that topics such as performance, scalability, error handling, and public vs. internal interface design are haphazardly covered and sometimes skipped. Because of the inconsistency of development practices, there is usually no ultimate "right" answer to any of these questions. Some of the recommended "best" answers in this book have some glaring failure cases that are not covered, and covering these cases will obliterate the simplicity and performance characteristics of the "best" answer. So you always need to probe your interviewers for your constraints, such as invalid inputs, what if memory allocation fails, who are your users, etc...

Ultimately, this is a useful book. You will probably do better on a software development job interview if you read this book. Stay away from the superficial treatment most people give books such as this of just trying to memorize the questions and answers. If you read this book thoughtfully, coding and testing your own answers to the exercises as you go, and evaluating the strengths and weaknesses of what's in the book, you'll definitely do better on any interview where you are asked direct coding questions. It is like learning one more person's point of view on relevant development practices, and the more you do that, the more rounded you will be and better you will do overall at both interviews and once on the job. Best of luck and I hope you find a programming job that fits you well.

There are many types and levels of programming jobs. This book is useful advice for people aiming for system level or hardcore type jobs e.g. embedded systems, networks and operating systems etc. For example, this book would be highly useful for you if you go for a developer's job interview in Cisco systems, IBM, Microsoft, Sun or Lucent etc. This is not too useful for application programming stuff, as one of the reviewers mentioned about Sybase etc. I have been giving programming interviews for many years and believe me, I have come across a surprising number of questions right from this book. The other good books for these type of interviews are "Expert C Programming" by Van der Linden, "Programming Pearls" and " C interfaces and Implementations" by Hansen. The interviews in companies I have mentioned do indeed last full working days, or at least five to six hours, involving lunch. The interviewers include three to four people from the engineering team, one from Human Resources and one senior level person e.g. director or head of the group type person to finish it off. The engineering team asks you to write significant code involving commonly used data structures, linked lists and trees etc. and also code that would require certain tricks of the trade that only veteran or seasoned programmers would know. So in my opinion, this is a timely arrival and gives lots of useful information to build the required confidence and thinking pattern to ace such interviews. The techniques described are all familiar and used frequently by most engineers and computer scientists in the field, but being able to answer promptly in an interview is a different ball game and I have suffered because of the lack of confidence in interviews. So, in my opinion, it deserves at least four stars.

I just had an interview appointment at Microsoft campus just this morning. I was applying a tech job as a software tester thru Volt Services. Volt (or any technology hiring services) would give some interview tips and prep for applicants vying for vacant positions.

The Microsoft interviewer asked me brain teasers like how many hamburgers have been consumed this year in the US alone. And he asked me how did I arrive with my conclusions by writing it on the whiteboard. (After the interview, he told me that he was not interested whether my answer was accurate or not, but he was more interested no how I arrived with my conclusion by writing it on a whiteboard).

After the brain teaser, he asked about network troubleshooting and remote file searching accross the network and that was easy. And then the interviewer began to ask about programming algorithms and how these algorithms be tested against predefined testing procedures. One of the questions given to me was similar in this book! The question was to create an algorithm of a string, "This is a string" to display on a screen written in a reversed order. And test the result of the algorithm against the methodical procedures applied to software testing.

Microsoft and other tech companies out there asked questions of many kind. And they may or may not be in any book available. But having and reading this book can increase your chances of a better interview results. I hope this review helps.

› Go to Amazon.com to see all 53 reviews  4.2 out of 5 stars