Slashdot Mirror
Programming Interviews Exposed
Introduction
Many people consider an interview a Kafkaesque experience, where all your skills (technical and social) come under the microscope. My toughest interview was one where I sat in a conference room faced with five hungry interviewers and "How many lines of code have you written in your career?" was considered small talk.
The promise
This book will not teach you how to handle small talk, but still may do wonders for you in your next interview. The author's promise, that reads: "If you work on learning to solve not just the specific problem we present, but the types of problems, you'll be able to handle anything they throw at you," is certainly ambitious, but they've succeeded admirably in my opinion.
General overview of book
Chapters 1 and 11 are short and sweet, but impart important lessons on how to negotiate offers, preparing for open-ended questions like "What are your career goals?" and generally convincing the employer that you can fit into their culture. Appendix A's coverage of writing technical resumes is brief but sufficient. Their bottom-line message is: craft a resume to sell your skills; don't write an autobiography.
The rest of the book comprises a review of common programming questions you may face, as well as a selection of puzzles that appear regularly in technical interviews.
The secrets summarized
The authors' secrets to technical interview success can be summarized as follows:
- Make sure you master the programming language that the job asks for.
- Practice solving problems and study heuristic methods.
- Master common data structures like linked lists, strings, trees & graphs.
- Be conversant in programming paradigms like recursion and Big O notation. And depending on the area of expertise that the interviewer is looking for, brush up on topics like concurrency, networking and database concepts.
Let's dissect these bullet points one by one
(1) The authors expect the interviewee to master every feature of the language that the job calls for, including the quirky and obscure ones. Personally, I think that knowing the core elements plus the specific features that the employer is looking for is more than enough. For example, in the Java paradigm; multithreading would be considered core, while knowing JNDI would be a speciality. But take note that an interview is not something you study for. It's not like a certification exam. You certainly need a couple of projects using that language under your belt to be absolutely prepared.
In interviews where you can choose the programming language, the authors caution against using lesser languages like Javascript or Visual Basic. But my opinion is that -- if it's used appropriately, and within the bounds of the job description -- any of these should be fine.
(2) G. Polya once said "Experience in solving problems and experience in watching other people solving problems must be the basis on which heuristic is built." The authors have kept to this spirit and included a generous number of challenging puzzles to exercise your brain. This is no coincidence, as both authors graduated from Stanford, where Polya once taught. Solutions are provided, but more importantly they've also included descriptions of the thought processes that underlies them. And by the way, the types of puzzles listed here probably wouldn't be out of place in a MENSA exam or the U.S. Computing Olympiad.
The authors also offer practical suggestions on how to solve problems, such as "Think out loud by explaining what you're doing," and "If you're stuck, consider looking at a specific/general example of the problem."
(3) The book offers one full chapter on linked lists. The author is justified in this, as linked lists can be operated upon by a multitude of operations. And each operation can usually be coded with a minimal number of lines of code. Ignore this advice at your peril.
(4) From experience, the authors have found that if you don't put down a particular skill in your resume; questions on those topics will not generally arise. So by setting the right expectations; you'll be able to get through the interview with fewer tangled nerves. But general programming knowledge questions like "What does it mean to be a 32 bit OS?" or "What is the difference between C++ and Java?" should be expected. Chapter 10 offers a healthy sample of them.
Weakness
One of the strengths of this book is that it focuses fully on the topic at hand which is "programming interviews" and never gets sidetracked. However it does have its weaknesses, in that there's very little mention of the high possibility of questions on component programming models (EJB,COM/COM+,CORBA). I think component-based software development (using off-the-shelf components) is the future of our industry (whether open or closed source) and companies are not interested in creating software from scratch. Also missing from the book is any mention of localization or internationalization of software.
Is it worth buying?
At 272 pages, this book can easily be skimmed in one sitting. But its value will not be apparent until you start solving the included problems/puzzles yourself and understanding the pattern of interview questions. This book is not a magic bullet that will guarantee you success in every technical interview, but having a rough estimate of what you will face is certainly better than being surprised.
Who is the target audience?
This book is especially relevant to recent computer science graduates who are just entering the industry. It may also be useful to technical recruiters and software managers (who assume the role of interviewers) who want to get some insights into the interview processes used by other companies. It might not be appropriate for people from other technical disciplines like system administrators or DBAs. Seasoned programmers may still get some benefit from the book although you've probably had first-hand experience with most of the questions/problems posed in the book.
Table of contents
- Chapter 1: The Job Application Process
- Chapter 2: Approaches to Programming Problems
- Chapter 3: Linked Lists
- Chapter 4: Trees and Graphs
- Chapter 5: Arrays and Strings
- Chapter 6: Recursion
- Chapter 7: Other Programming Topics
- Chapter 8: Counting, Measuring and Ordering Puzzles
- Chapter 9: Graphical and Spatial Puzzles
- Chapter 10: Knowledge Based Questions
- Chapter 11: Non-Technical Questions
- Appendix A: Resumes
"I work cheap"
DrLunch.com The site that tells you what's for lunch!
No biting
When asked about prior work experience, you don't need to mention the summer at the badger insemination factory.
No hairpulling
Never Look the interviewer directly in the eye, this can appear confrontational
Leave before the interview is over, so you don't seem overly desperate
air and light and time and space
No, the author is NOT justified in putting ANY specific programming information in. If the company asks me "can you implement a linked list in Java in 10 lines or less", then that's not a place I want to work.
The place I want to work (in fact, the place I AM working) is where they know you are a good problem-solver and that you can pick up any tools you need. Specifics like linked-lists tell nothing about the quality of the employee.
And this isn't just me talking as an employee. I hired a guy once who had a civil engineering degree. He didn't know things like linked lists, depth-first vs breadth first, turing machines, yada yada yada. And his programming wasn't even all that top-notch (good, but not what I'd call outstanding). But could that boy solve a problem and FAST. Give him a task, however complex, and you'd know it was SOLVED--ASAP.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
w0rk3d 4 m3
->mafiaboy
->mafiaboy
don't confuse political expression with vandalism
The company I recently took a job at was more impressed with the fact that I can pick up new languages and learn new technologies quickly, rather than my extreme expertise in one area. I am not looking to get hired because I know the birthdate of the mother of Linus' dog. Get it?
Its a shame when I see so many schools teaching "hands on/technical programming" in their Computer Science courses... IMHO and experience, teaching CS with an "algorithmic" approach is much more effective.
Technology comes and goes, we're in a time of innovation, do you really want to spend so much time and energy into knowing every bit of detail, when you could be building other, more useful skills?
Having a lot of "linux geek" friends, I used to get yelled at a lot to "RTFM" (read the effin manual). Well, I'd say keep this in mind when applying for a job. You can always RTFM. You don't need to know every specific of everything. You need to be able to, and be comfortable with learning new things.
Cheesy quote, but true: "Its not the quickest, or smartest animals that succeed.. but the ones who adapt the quickest." - I think it was Darwin.
Over and out.
I'm not weird, you're just all boring.
A couple points I've learned in my interviewing experience (and I've never been turned down for a position I've interviewed for. Ever.)
If you're interviewing at a place that is going to quiz you on the spot, you're not going to be happy. I can see maybe showing you some code and asking you to explain what it does - but your educational qualifications and prior experience should be enough to demonstrate you are capable. I don't remember 1001 buzzwords well. This is usually a mistake that first-time or inexperienced interviewers will make.
What you do to land a cool job is you get a chord struck with the interviewer on a personal level. You take the opportunity to talk about the cool mp3 system you programmed for your car. You talk about the challenges you had going through school. Talk about the moment when object oriented programming became clear to you. You want to avoid the horrible standard questions like what do you want to do with your career - if you're reading a cookie cutter answer, you're going to be like everyone else.
When I get asked questions like that, I talk about experiences I've had in the field, positive and negative, and how I'd make sure that they happen/don't happen again. Demonstrate to the interviewer you're personable and they can work with you - you don't need to prove yourself at this stage, a mistake many people make. If you're being interviewed, you're good on paper. They want to see if they can trust and deal with you on a daily basis. Let your personality come through.
This is something you'll never see taught in a resume course. BE YOURSELF. If you're not, you won't be happy in the job - because they didn't hire you, they hired that person in the book.
..don't panic
List everything on your resume. Even if you've only experimented with it. If the job requires it, bone up on it before the interview if you need to. Recruiters are nothing more than buzzword parsers. If your resume says you're strong with korn shell programming, we can assume you know grep and regular expressions. But recruiters won't know this. If your resume doesn't say the actual word "grep" they'll pass you by. The first page of my resume is nothing more than a list of words (organized neatly).
I get a hard technical interview maybe 10% of the time. Don't worry about all the minor details of the tool they're using.
No one cares what you claim to know. They only care about what you have actual experience with. Most people count years, even though it's the worst way to measure skill. Therefore...
Intentionally take contracts that have tools you don't know or are weak in. Ideally, if they're asking for six different things, know five of them really well and be weak in the sixth. This is the only way to grow. Six months later, you'll have something else to add to your resume.
Don't fill out skills inventories. Just get up and leave.
Don't go on an interview with a consulting firm until they already have a specific contract lined up for you... unless you're just in it for the free lunch. :-)
Don't take salaried positions with consulting firms. If you want to be salaried, work direct. But then again, why take a 50% pay cut? Just be a consultant.
Don't get starry-eyed about the consulting firm being the biggest, best, or fastest something in some area. They all are. My favorite one is, "Let me tell you what makes us different from all the other consulting firms." :-P Talk about irony.
Don't work for (insert your Borg-like monster consulting firm here, i.e. Andersen, E&Y). And don't take contracts relating to them either... unless you want to achieve synergy with your incompetence intollerance matrix.
Sorry for the rant.
brian
As one of the authors of Programming Interviews Exposed, there are a few things I thought I might respond to in the review and some of the early posts.
Dissection of point 1
I agree with Gavin's assessment of what knowledge is important. What we really meant is you need to know every quirky feature (even obscure ones) of the core language. For instance, you should be familiar with bitwise operators, even if you rarely use them in your programs. If you say you know C, you should know what a union is. It's certainly not necessary to be familiar with every library and technology that's ever been tacked onto the language.
Weaknesses
Component programming and I18N are both important topics. I do feel that in most cases, they fall into the "they won't ask you unless it's on your resume" category, but perhaps we'll be able to include some material on them in the next edition ;-)
Posts expressing discontent with the whole idea of being quizzed
I have to admit, I was more than a little put off the first time I was quizzed in an interview. However, I've come to understand that some amount of this is a necessary evil. Unfortunately, there are a large number of applicants who claim they can program, but, to be blunt, can't. I'm talking about people who claim to be "Senior Java Developers" and don't know how to declare a variable. Some of these folks can actually talk a reasonably good game, so it's very hard to screen them out without asking applicants some sort of programming questions.
A couple of people have mentioned that factual recall Trivial Pursuits-type questions doesn't really prove anything. I definitely agree with this, and I think most companies do, too: most of the questions I've faced have required intelligent application of a little knowledge everyone should have, rather than encyclopedic recall. I wouldn't want to work for a company that emphasized the latter kind of question.
All that said, I do think that there is too much emphasis on time-pressured puzzle-solving in most interviews. As I mentioned, some of this is useful to screen out fakers, but the real measure of a programmer is what he/she can do in a few weeks or months, not in 25 minutes. I think interviewers ought to spend more time asking about the applicant's experience and past projects. Nevertheless, right now most interviewers do focus on puzzle questions; we thought it would be most helpful to write a book to prepare people for interviews as they are rather than interviews as we wish they were.
Finally, a big thanks to Gavin Bong for taking the time to read and review our book.
John Mongan
I used to work for a consulting firm; I was the only consultant with my particular skill set (embedded and realtime programming) so when it came time to hire more programmers for that client it fell to me to interview them. I discovered that the best approach was to go down their resume item by item and just ask them either something about "how they did that" (if it was a project) or situations in which they "had used that" (if it was a skill). The best applicants were the ones who took it as a conversation, and we basically had a nice chat about that item, possibly going off into tangents where I got to find out more about their interests etc. I tended to emphasize things that I had some knowledge about, as that made it very easy to tell when someone didn't really know what they were talking about. I really hated having to pull out "the dreaded list of ten C questions", and if the interview degenerated to that level it was almost always the kiss of death.
IMO this is the ideal way to do an interview, and it's certainly the kind of interview I would want to be given. The only problem is, a lot of times the person giving the interview is not themselves a programmer, so the ability to establish a rapport with the interviewee is limited and they're forced to resort to standardized measures like quizzes or puzzles.
As an aside, my current new job - where I start next month - was landed the best way of all. I went to a training course given at the company's headquarters and immediately liked what I saw. It gave me three days to talk to everyone, go out to lunch with them, see how they worked and talked to each other, see their projects, etc. and of course they got to know me reasonably well also. I went away from the course feeling happy but not really expecting anything more to come from it; I was very pleased when a while later they expressed an interest in hiring me on. Needless to say, there was no real need for a technical interview at that point.
If only all "interviews" could be like that...