Which programming book prepared you the most of interview questions? My friend recommended these:
What does this community recommend for someone preparing for an entry level software development/ internship interview questions?
Which programming book prepared you the most of interview questions? My friend recommended these:
What does this community recommend for someone preparing for an entry level software development/ internship interview questions?
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:
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.
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.
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.
I guess there are at least 4 areas of knowledge to developing software:
One or more programming languages, operating systems, APIs, etc.
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.
Some domain knowledge (e.g. banking if it's banking software, telecomms if it's telecomms software, etc.)
'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
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.
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.
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.
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.
Read The Guerrilla Guide to Interviewing (version 3.0) - by Joel Spolsky
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.
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.
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.
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.
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.
Take a look at Steve Yegge's Get that job at Google, and Michael Pryor's techinterview.org.
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.
It seems all interviewers I know have a soft spot for
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.
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.
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]