views:

2700

answers:

18

Which programming book prepared you the most of interview questions? My friend recommended these:

  1. Interview Questions Exposed
  2. Career Cup's Book

What does this community recommend for someone preparing for an entry level software development/ internship interview questions?

+8  A: 

A lot of companies are big on design patterns for OO development.

A good intro book is "Head First Design Patterns"

The official book is "Design Patterns" (this is commonly referred to as the "Gang of Four" (GoF) book).

Here's a good online reference: http://www.dofactory.com/Patterns/Patterns.aspx

Some of the more commonly used patterns are:

  • Abstract Factory
  • Factory Method
  • Singleton (people have differing opinions on Singleton, but it's good interview bait)
  • Command
  • Observer
Andy White
Singleton can be a good pattern to show a deeper understanding of the language(s) you're interview for. For example, in Java, the 'classic' implementation of Singleton has definite implications when you start examining more advanced topics than basic design patterns, such as classloading and multiple classloaders in the same JVM, threading, double-checked locking, etc.
Paul Morie
I like how the Head First Design Patterns book has a picture of a blond girl where the only relevance is that she has a head.
Unknown
-1 Good if you are a large company with tons of money to blow on salaries for overpaid PHDs that don't produce code. Bad if you want a developer who is going to accomplish something. I'd call this the 'architectural astronaut filter' of interviewing.
Evan Plaice
I agree that design patterns can definitely be architecture astronaut territory, but I think the awareness of a few common patterns can be a good measure of a developer's experience. Asking about obscure patterns to see if someone memorized the book is not cool though.
Andy White
On the other hand, given the choice, I'd rather work as an overpaid architecture astronaut than work for a company that uses the "months of coding saved us ours of planing" approach to software design ;-)
nikie
I have yet to give an interview where the topic of design patterns specifically came up. Whether they can come up with a sensible design to a problem is always my principal concern. Astronauts get caught when they are asked to write code. :-)
Owen S.
@Evan Plaice I slightly disagree. An understanding of design patterns is a fundamental step in growing as a developer. They are guidelines for best-practice solutions to common issues. However, I doubt an intern should be too worried about GoF patterns just yet. That's maybe late junior, early intermediate material.
Andy_Vulhop
@codemonkey4hire the point I'm trying to get across is, design patterns are a great tool to complement a programmers skills but they're definitely not part of a programmers foundational skill set. IE, pour the concrete before you build the outer facade.
Evan Plaice
The idea that knowledge of "design patterns" means you are a developer who won't "accomplish something" is laughable
matt b
+6  A: 

I suggest you don't buy a book. Read up a quick overview of some common patterns like MVC but reading a book designed to answer interview questions is going to expose you as a fraud.

Think about about it.

  • Interviewer: What design patterns do you use?
  • You: Oh I know X, Y and Z.
  • Interviewer: What software have you written in Z?
  • You: er...

Just be honest and stick to areas you know. If you can "learn" a design pattern from a paragraph or two in a book then it isn't going to be a major concern for an employer. They are far more interested in the languages you know and your years of experience with each. Pretending to know things you don't is a common way to fail an interview because even a hesitation can expose all of your answers as being unreliable. Only actual experience can give you confidence that doesn't seem fake to an experienced interviewer.

What does this community recommend for someone preparing for an entry level software development/ internship interview questions?

If possible research the company offering the job (this isn't always specified). Then you'll know what kind of products and technologies they deal in and it shows initiative.

SpliFF
On the other hand, even "I have *read* _Design Patterns_" or whatever can be a good answer: I find it reassuring to hear that a candidate is/has been willing to study such a topic. And as an interview question, I think I've more than one been asked, "What books have you read?"
ChrisW
All of what you are saying is fine, but dont you think most of these books are a good way to prepare right before the exam. Dont you think these books put at ease a lot of apprehensions? Dont you think these act as a refresher? If I have a week before the exam, I personally would love to get an overview of the common questions asked and the topics involved no matter how good a programmer i am.
kunjaan
+3  A: 

Generally, I think that books on interview questions are kind of silly, but here's a book that describes Microsoft's culture of interview questions.

http://www.amazon.com/Would-Move-Mount-Microsofts-Puzzle/dp/0316919160

It's an interesting book, but personally, I feel that you will be best served not by reading a book about interview questions, but by boning up on the fundamentals.

McWafflestix
+10  A: 

I guess there are at least 4 areas of knowledge to developing software:

  1. One or more programming languages, operating systems, APIs, etc.

  2. The tasks, roles, lifecycle of, and skills associated with a software development project (aka 'development process'), including specification, design, building, testing, scheduling, estimating, reporting, debugging, support, etc.

  3. Some domain knowledge (e.g. banking if it's banking software, telecomms if it's telecomms software, etc.)

  4. 'Soft' skills (getting on with people)

You're asking about "programming" books (and so, ignoring 3. and 4.):

  • Discover what language etc your prospective employer is using: whether it's PHP or C++ or whatever might affect what programming books are relevent!

  • I expect your prior experience of 'process' is weak (though it may not be) ... so, that might be worth studying ... or, given that they know they're hiring at the entry level / internship level, maybe that's one of the things that might expect/intend to teach you instead of your knowing already

ChrisW
+4  A: 

Like any kind of examination, it's always a good idea to brush up on what's going to be on the test. I think the "Programming Interviews Exposed" book is pretty good.

It's not going to make it so you ace the interview on stuff you really have no idea about - you're not going to get a university-level education on algorithms from the book, but it touches on a nice assortment of things that seem to be asked pretty often. Even if you've been in the field for a while the book can be useful - if it's been several years (or more) since you coded up a binary search tree in college, a quick refresher can be very helpful. I don't know about you, but I almost always get asked about binary trees in interviews, but it's a pretty rare day when I actually have to code one up at work (they've already been coded up into library routines already, believe it or not).

Now, some of the tougher questions that seem to get asked at top tier places like MS, Google, Amazon, etc. might not be covered by a book like this. but then again, like I said, the book is not supposed to be a university level algorithms text.

I also suggest that you actually fire up an editor and code some of the stuff you think you might be whiteboarding in the interview - don't just read up about it on the book.

Michael Burr
The book also has some good advice on how to approach puzzles and programming questions in an interview setting. It certainly doesn't cover all possible questions and topics, but it does explain techniques you can use to work through problems that might stump you at first.
Millhouse
A: 

Peter Van Roy and Seif Hardi's Concepts, Techniques and Models of Computer Programming. It did take me a couple of years to truly learn everything in it, though.

Curt Sampson
+4  A: 

Some of the most important questions to answer correctly in a programming interview aren't about specifics of programming at all. When I'm interviewing someone, I try to determine how their overall attitudes are towards programming and work in general, for instance. One of my favorite interview questions is:

Tell me about a time when you were involved with a project that failed or nearly failed. What did you learn?

This type of question is a good chance for you to demonstrate your capacity for reflective thinking and self-analysis, two traits that are arguably common among good software engineers. You're unlikely to find this type of knowledge in a book, since the best answers will be in your own experience. Even if you've never worked professionally as a programmer before, you have some experience at least from learning.

Paul Morie
How would you answer that?
Unknown
I'll say that the most common answers are about requirements or scope creep.
Paul Morie
I'd answer that in almost every case one of my projects failed, it was because I didn't really understand what the customer needed.
nikie
+2  A: 

if you're applying for jobs where you're likely to be asked about datastructures and algorithms, i've found papadimitriou's 'combinatorial optimization: algorithms and complexity' makes a very good refresher. it won't really teach you the stuff (the couple of days before the interview are the wrong time for that anyway!), but it helps a lot in having the right tool come to mind for a given problem.

Martin DeMello
+15  A: 

Read The Guerrilla Guide to Interviewing (version 3.0) - by Joel Spolsky

  1. It gives a great baseline for narrowing down applicants to just the smart/productive ones
  2. It addresses issues with the interviewing process itself (how long or how many people should be involved in the interview process).
  3. It gives some good suggestions about programming related questions and how to interpret the results to pinpoint the best candidates.
  4. It's based off of actual experiences of an experienced developer interviewing other developers.

I can't believe I'm the first to mention it.

And... Whatever you do. Don't make your interview questions based on design patterns primarily or you'll end up with a shop full of architecture astronauts. Hiring people like that is worse than hiring no one at all.

Update:

JC mentioned in the comments this link to another great article on Joel's blog about interviewing applicants over the phone.

Evan Plaice
Nice suggestion, but the link is wrong. Tracked down the [actual article](http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html "title"), though, and it's a good read.
Joel Hoff
@Joel updated the link. Thanks.
Evan Plaice
From this page I followed another interesting link to an article about phone interviews, which are as important because if you don't pass it you're out : http://www.joelonsoftware.com/articles/ThePhoneScreen.html
JC
+1  A: 

For an entry level position, I think it's better for candidates to be able to show competency in learning/researching and being able to think (solve problems without re-inventing the wheel) as well as being honest about their capabilities (and prior experience, especially in a team, a big plus).

Design pattern knowledge is a bonus, for sure, but IMHO really learning (understanding) patterns really only occurs once you've actually applied the principles in the field, and most applicants for these positions are unlikely to have that kind of experience.

What I'd look for is an honest desire to learn, and the initiative to write their own code/projects and to be proactive in honing their skills, or at minimum the desire to learn from others.

To prepare, I'd do as some others have suggested - study up on the technology and/or domain area that a prospective employer uses, and do some background research.

Lastly, have a good idea what you want out of the position, and be realistic about what you bring to the table. Don't limit your preparation to books, there's excellent reading online, decent open source projects to be involved in and participate in community events.

RobS
+4  A: 

The best book I know is The Algorithm Design Manual by Steven S. Skiena. The book covers basic data structures and sorting algorithms, graph problems.

It is the best and most comprehensive practical algorithm guide I know to help identify and solve problems. It covers just about every possible interview-question if you are preparing for an interview with any big company like Google or MS and your future role is Software Engineer.

psihodelia
+1 my personal fav too.
codaddict
+1  A: 

If you're at all worried that they may use one of the riddles or logic problems that Microsoft and Google are now infamous for, check out a book called "How Would You Move Mt. Fuji?" by William Poundstone.

It's a quick read that talks a bit about the origin of the modern (for some places) programming interview where the ability to think abstractly is highly valued. It's interjected with lots of actual riddles and logic puzzles used by companies. More importantly than just telling you how to go about solving them, I think, it puts you in the mind of the interviewer and what they're looking for and explains how the answer you give is not nearly as important as the methods by which you arrive at it.

At the very least, it's an interesting book with lots of fun interview riddles/logic problems.

Sean O'Hollaren
A: 

For .net interviews, I swear by the C# 3.0 Pocket Reference book, and would probably recommend the other "Pocket Reference" series books. They are short and to the point and cover everything about the language / topic you need to know. You can read it cover to cover before an interview in a couple of hours and is a good refresher of the language.

thekaido
+1  A: 

Take a look at Steve Yegge's Get that job at Google, and Michael Pryor's techinterview.org.

Yuval F
A: 

Beyond reading books, you might want to do some practice interviews. Grab a friend and a room with a whiteboard and have them ask you some simple programming questions (maybe from an interview book you haven't read yet). Get used to writing on the board and explaining what you are doing, have your friend ask lots questions. Get as comfortable as possible with that style of coding, and you'll reduce your stress level in the actual interview, which will definitely improve your performance.

Millhouse
A: 

It seems all interviewers I know have a soft spot for

  • design patterns
  • client/server architecture

The design patterns books have been covered already, but I'll give you a nice resource for the second. Sockets are nice and it seems people ask about them every time. I found quite useful this material.

Bogdan Constantinescu
A: 

Having been in your position just three years ago I recommend you do not concentrate on which interview books to read. Rather, pick your strongest language and study up on the core concepts. Particularly the most popular framework's (like .NET for C#) most useful classes and OO concepts.

On the flipside, don't just take any job, especially as a new dev. I run companies through the Joel Test. This will help to ensure that the company you are working with knows what they are doing. The last thing you want to do as a newbie developer is end up programming alone, or worse end up battling management's crazy ideas with no experience and no colleagues to back you up when your asked to single handedly build a system that would take 1000's of man hours in just two months.

P.Brian.Mackey
+4  A: 

I have worked for some of the best software companies around and done a tone of these interviews. We just published a book called "Algorithms for Interviews". Me and my co-author have put in 2 years of effort in it and we think the end result is very nice. I'd highly recommend it to anyone who is preparing for an algorithms/coding interview. Also, I'd love to get your feedback on the book at [email protected]

Amit Prakash