In this post I would like to share some ideas, book titles and links on technical interviews. The post is intended to be useful for interviewers as well as for interviewees. I talk here about interviews for a `software engineer’ position. I suggest that you either want to get a new valuable member for your great team or want to join such a team.
What to expect?
First, let’s discuss what are the staffing needs in smart companies? They want people that can tackle complex problems in new problem areas. They want people that are responsible and passionate about their work. And, of course, they want people that can explain their solutions to colleagues.
How a candidate can be tested against those requirements? It is supposed that to solve complex problems in unexplored areas an engineer must know well the basics and must have an instinct on combining them in appropriate and often unusual ways. Responsibility, passion and communication skills can be estimated by interviewing about previous projects and by existence of commitments to exterior projects.
Of those requirements, the knowledge and problem solving skills are the ones that can hardly be faked and therefore are checked very thoroughly during interviews. So, let’s concentrate on them.
What are the flesh and bones of programming? Of course, algorithms and data structures—they are `ideas’, that an engineer must be able to implement by means of programming language. But surprisingly many people consider these as an `academic stuff’ and doesn’t bother to study them well or, as interviewers, avoid to ask them. Big mistake!
More accepted is the statement that programmers should write a code during an interview. And remember—conditions at an interview are tremendously different from working ones—it means no IDEs, no magic libraries, no examples to copy from. Just pen and paper (or a whiteboard). As an interviewee you should invest seriously in such a training. Read books (see below), do exercises, implement solutions with bare minimum of language, in a basic editor without sophisticated code completion features. As an interviewer you must help a candidate to overcome his or her nervousness that can turn otherwise simple coding problem to almost impossible.
To avoid hiring a person that can reverse a linked list but doesn’t have a clue on how to blueprint and build sane and reliable applications, “design questions” are used. Think of real-world problems: text manipulation, image editing, email processing, web search. What goals and constraints are there? How would you (or a candidate) decouple a problem into independent tasks that can be solved, implemented and tested separately? This stuff is hard to learn from a textbook. The more real experience you have, the better. But of course, some good books do exist. Read further.
Ok, I hope, you’ve got the idea what a serious technical interview is. Now let’s see what to read before you have been involved into.
The book I recommend you to start with is “Programming Interviews Exposed”. After finishing it you’ll have a very good backbone of technical interviewing topics and questions in your head. Another good (free!) resource is recently published “How to Pass a Silicon Valley Software Engineering Interview” PDF presentation. Although not so systematic as “PIE”, it covers a good variety of topics.
Also, many outstanding blog authors have cycles of articles on interviewing—from résumés to on-site interviewing. Good old Joel wrote these: “Sorting Resumes”, “The Phone Screen” and “The Guerilla Guide to Interviewing”. He published these articles together with some others in a book “Smart and Get Things Done”. Michael “Rands” Lopp wrote incredibly good articles: “A Glimpse and a Hook”, “The Sanity Check” and “The Button”. He also wrote a book called “Managing Humans” which includes these articles. Steve Yegge hasn’t published a book yet, but his articles are worth reading too: “Ten Tips for a (Slightly) Less Awful Resume”, “Five Essential Phone Screen Questions” and “The Truth about Interviewing”.
Algorithms and Data Structures
Invaluable books are: Knuth’s “The Art of Computer Programming” (calm down, you don’t really need all volumes, just consider Chapters 2, 5 and 6), Cormen’s et al “Introduction to Algorithms” (also not all chapters—just about half of a book) and Jon Bentley’s “Programming Pearls”. Although the last one is considerably thinner that the first two, it contains no less important information and exercises.
To get maximum benefit from these books, do exercises. I repeat, do exercises. You can’t imagine how pleasant it is—to get on an interview a problem that you have solved beforehand. Even as an interviewer, try to solve exercises yourself, so you’ll be able to compare your progress in solving it with interviewee’s and make tips if he or she is stuck due to nervousness.
In this area the basis books are Gamma’s et al “Design Patterns” and Martin Fowlers “Refactoring. Improving the Design of Existing Code”. They establish terminology and present the best design practices. Unfortunately, they contain no exercises, so it’s up to you to invent them. Good ones are to implement some patterns in your favorite programming language and to explain ideas of patterns in 3–5 sentences.
To get more real-world examples of complex systems design, consider “Microsoft Windows Internals” by Mark Russinovich & Dave Solomon and “The Art of Unix Programming” by Eric Raymond. Even if you don’t plan to develop operating systems or to become a Unix hacker, you’ll get many bright ideas and discover real-life trade-offs in design from them.
Opinions on whether to ask brainteasers on a technical interview are different. Some people say that asking them reveals creativity and explores candidate’s thinking process. Other argue that candidate’s ability/inability to solve a particular puzzle doesn’t mean anything. To shape your own opinion and to be prepared for such questions, consider William Poundstone’s “How Would You Move Mount Fuji?” book. Yes, with it you’ll finally discover how to estimate the quantity of gas stations in United States or any other country.
Getting through all these books doesn’t mean that you’re ready. Another important step is to look at real interview questions. For these, good resources are discussions at techInterview.org and Placements Corner.
A good article about non-technical questions on technical interviews is “25 Questions to Think About Before Your Next Job Interview”.
And that’s not all…
To feel yourself confident at any side of the interviewing table, consider studying books (or, at least, Wikipedia articles) on compiler construction, concurrent programming, garbage collection, computational geometry, information retrieval, functional programming, today’s most used programming languages and frameworks, computer networks, databases and user interface design.
After all, becoming a valuable specialist is a hard work. As well as finding and hiring one for your team. Good luck!