Reddit reviews Programming Interviews Exposed: Secrets to Landing Your Next Job, 2nd Edition (Programmer to Programmer)

Employers like degrees, but employers also like people who know how to get things done. At the very least, teaching yourself is a good start for whatever else you're thinking of doing.

I've thought about it a lot: if I were trying to learn to program, today, from scratch, what tools would I want? Well, here are a few of my favorite things...

Free VS 2010 Professional for @edu accounts:

https://www.dreamspark.com/

Free Eclipse IDE for Java EE Developers:

http://www.eclipse.org/downloads/

Free team tools worth understanding:

http://www.perforce.com/ (version control)

http://subversion.apache.org/ (version control - pretty much the same thing as perforce, but not as good)

http://git-scm.com/ (version control - a VERY different way of doing things, but powerful and gaining popularity)

http://www.rallydev.com/ (task management - kind of a pain, but good to play with)

Tutorials:

http://www.khanacademy.org/science/computer-science?k (probably a very good place to start)

http://www.khanacademy.org/exercisedashboard (math - the value of this cannot be overstated)

Online course-ware:

http://mitpress.mit.edu/sicp/

http://ocw.mit.edu/courses/#electrical-engineering-and-computer-science

http://www.stanford.edu/online/

http://edudemic.com/2012/04/the-25-best-places-to-take-free-online-computer-science-classes/

Problem solving challenges:

http://projecteuler.net/ (we should go through these together)

Community:

http://stackoverflow.com/ (Q&A forum)

http://www.reddit.com/r/programming (some good links, okay place to ask questions)

Books:

http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Programmer/dp/047012167X (once you're ready for a job, this is good to work your way through)

Possibly a good discussion about finding a software job, later in life:

http://news.ycombinator.com/item?id=4350827

And then...

Depending on the kind of development you're interested in, there are a TON of other valuable resources, tutorials, tools, etc:

Free Cloud Services - depending on what you're doing, these might be SUPER valuable... Might not want to make an account until you're ready, because the clock starts ticking:

http://aws.amazon.com/free/

https://www.windowsazure.com/en-us/pricing/free-trial/

Free cloud development tools:

https://c9.io/

I highly recommend Programming Interviews Exposed.

http://www.amazon.com/dp/047012167X/ref=asc_df_047012167X1773383?smid=ATVPDKIKX0DER&tag=hyprod-20&linkCode=asn&creative=395093&creativeASIN=047012167X

I'd recommend buying one (or both) of these books and reading through them:

• Cracking the Coding Interview
  
• Programming Interviews Exposed
  
  Each of those books has a wide range of programming problems that are commonly asked during an interview. I highly recommend going one question at a time and actually trying to solve them yourself before looking at the solution. This way you won't simply have a dictionary of interview questions--you'll also be able to develop the skills to figure your way through similar problems.

Programming Interviews Exposed is an extremely good resource, Steve Yegge also has a good post on areas a programmer should be proficient in.

Nothing is really a substitute for being knowledgeable and enthusiastic.

I'll address your #1 below, but I want to focus on #2 for a second.

The feedback you've gotten regarding your degree choice is correct -- all of it, even though it may seem contradictory. You'll have a tough time finding a job in Art - and artists probably won't appreciate a degree in CS very much. The reverse couldn't be further from the truth.

It is a very rare individual that has the logical and mathematical nature to code efficiently and with broad scope but then uses their artistic creativity to inspire cleverness. Code, or more generally put a system, is a piece of art just like any other. A wide array of pieces which need to cleverly and harmoniously co-exist. The creativity of an artist is essential in recognizing the potential of an application.

I want you to look at this role. Read the job description, and picture it applying to a product where you design the User Interface and the User Experience. Understand that you will work with graphics artists, but it's your vision that determines what the user experiences.

If that feels right, chase it.

----

As for your #1 question, another very good one.

When I'm interviewing SDEs, I want to see mastery of concepts and, to an extent, cleverness of a solution. There are a few things, though, which make me almost immediately discount a candidate:

Starting before you have all the information. Make sure that you have a very clear vision of what the problems is before you begin. Understand that any assumptions you make must be checked first. For example, if I say take a pointer to the head of a linked list and then do X on it, and you assume that the pointer will never be null, you will fail my test. Either code for the case where the ptr is null, or ask the interview "Is it a fair assumption that the pointer will never be null?"

Being satisfied with a naive solution. When solving a problem, it's perfectly fine to give the naive solution -- but don't stop there. Once done, talk with the interviewer. Say things like "Now this is the naive solution, because it finishes in O(n^2) time. We can make this more efficient by doing 'X'" and then press forward.

Internalizing your thoughts. This is weird to do for candidates, but it's critical for a team environment. When you're solving problems, think out loud. I'm not asking you to solve these problems because I'm bored and need a show, I want to know how you think.

There's so many of these I could write a book (and others have). I highly recommend reading Programming Interviews Exposed. It's an awesome resource with spot on practice problems.

Review your basic algorithms and data structures. Sorting, graph traversal, linked lists, structs, arrays, and multi-dimensional arrays.

Know about memory management, know about orders of magnitude in runtime, know about pointers, know about debugging and what to test.

You almost certainly won't be asked one of those wacky brainteasers you hear so much about -- we've found over time they do little else but tell us how good you are at brainteasers.

If you can do every problem in this book then you'll be more than prepared.

Also, give a quick read of our general interview tips.

General advice:

Pay close attention to providing thoughtful, reasoned approaches. Don't get so tied up in providing a clever solution that you forget the simple answer. Points are definitely awarded for really clever or innovative solutions, but that isn't the only way to get through.

Additionally, RELAX! This is definitely easier said than done, I realize, but understand that most interviewers really do want you to succeed. They aren't there to scare or intimidate you, and interviewing isn't even their day job! They're engineers who once sat exactly where you were, answering the same things they're now asking you.

Try and think of your conversation with your interviewer as being a chat with a really good friend of yours that you haven't seen in a really long time. You used to be best buddies, but moved away and you haven't seen them since. You know you've both changed in all that time, so you're being a little restrained, but there's still a foundation of mutual trust and respect -- one that puts you at ease.

Lastly, verbalize your answers. We aren't asking you to write an algorithm to sort a linked list because we're curious how it's done -- we're asking you because we want to know how you think. Verbalize your thought process. Verify all your assumptions. And, if you get stuck, don't be afraid of stating your thought process to your interviewer and asking for some feedback on where to take the solution (this is a heavily team-oriented company, after all).

Hope this helps! Best of luck!

Source: I do interviews at Microsoft, both general technical interviews as well as PM interviews.

Search algorithms and data structures will be pretty important for the interview, but if you're a bit rusty, there's probably still time to brush up on stuff before the interview. Books like Cracking the Coding Interview or Programming Interviews Exposed really help.

One thing to be careful about on the interview though is to not get too hung up on finding the best possible answer to a question. Yes, coming up with an efficient solution is good (and if you give a less than optimal solution, your interviewer will probably ask you to improve it or add more constraints), but if you cannot come up with any solution, even a naive one, and aren't able to code it (or run out of time because you spent too long trying to find an efficient solution), you probably won't make it to the next round.

In general though, you shouldn't be asked too many questions that require memorization as long as you know the basics (and you should be able to discuss space and time complexity for any solutions you provide). If you have any more questions though, feel free to send me a PM (I work at Amazon).

I highly recommend Programming Interviews Exposed: Secrets to Landing Your Next Job. This has greatly helped me with the technical portion of the interview. Especially companies with difficult interviews (Microsoft, Google, Amazon, etc)

I think you need a bit of all of these.


If someone's asking you weird questions about esoteric details of Hibernate, they're probably not the kind of person you'd want to work for. OTOH.. if you get a question, like, "do you prefer Hibernate XML mappings or annotations? why?" and you can provide a reasonable defense for either position, I think this should be enough to vouch for your credibility as a competent developer. IMHO, it's not often about what you know, but how you make intelligent, thoughtful decisions. If you're not interviewing people who are proven to be intelligent, at least on paper, then there's probably something wrong with the screening/selection process.


Puzzlers in interviews can go either way, and I'd never discredit a candidate for not being able to solve eccentric riddles on the spot. If you can, however, figure out a new problem in a clever way then it can't hurt you. Reading this book or this book are good places to start to get your mind thinking in these directions.


In my opinion, you should probably also have a good prep for the garden-variety HR interview questions as well... if you can't 'describe a weakness' without using a stock answer, that's probably something to work on before the interview. These types of questions are usually pretty lame, but anyone who's done a few interviews should have answers for the most common ones.

I've heard good things about these books; Cracking the Coding Interview: 150 Programming Questions and Solutions and Programming Interviews Exposed: Secrets to Landing Your Next Job

I found Glassdoor's collection of user-submitted interview questions helpful in my last job search: http://www.glassdoor.com/Interview/index.htm

This book is also helpful, although much of the advice in it can be found elsewhere on the net: "Programming Interviews Exposed":
http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Programmer/dp/047012167X/ref=sr_1_1?ie=UTF8&s=books&qid=1292102203&sr=8-1

Good news! Very few people code well in interviews, from what I've heard. Boneheaded mistakes are practically expected. Ask lots of questions about the problem--it'll give you more time to think and it'll make it clear that you're trying to figure out exactly what they're asking.

Amazon interviews are just like most technical interviews, in my experience. A FANTASTIC book to prep for interviews with is Programming Interviews Exposed. It goes over a lot of the data structures and common types of problems you'll get in interviews. It's great for day-of refreshers, or for going through more in-depth. HIGHLY recommend it!

A) There's no reason to wait. Start looking now.

B) I don't have any experience with game programming interviews in particular, but I would highly recommend the book Programming Interviews Exposed for any sort of programming interview. It's a wonderful resource to refresh yourself on the basics.

I hate tech tests.

I worked at a company were we needed a C++ developer to work on some legacy C++ code we had. We had no C++ developers but my manager still had to scramble around for a tech test for a C++ developer.

I don't understand why there is no certification for developers. Everyone thinks their tech test is unique but they are not. I've been to many tech tests and they all cover the same crap that is not relevant to any job I've ever had. If tech test were unique books like this would not exist http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Programmer/dp/047012167X/

And if I need an accountant I don't put them through a tech tests to see if they are qualified.

A friend of mine who is a senior developer recommended this to me once:
http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Programmer/dp/047012167X/ref=sr_1_1?s=books&ie=UTF8&qid=1319572196&sr=1-1

It covers programming questions that you may be asked.

One of the best things to do is read what other programmers have to say. It opens yourself up to things that you might not normally come across. Schedule a time of the day where you will go on Stackoverflow to answer questions or read answers. Also in that time, read some blogs and any new articles. A few of the websites that I really like:

• Stackoverflow
  
  
• Coding Horror
  
  
• Joel on Software
  
  
• Wolfire Games (especially since you are into game development)
  
  
  Have you caught up reading the classics when it comes to software development? A great list of them can be found here. A few that I have found totally eye opening:
  
  
• The Pragmatic Programmer
  
  
• Programming Interviews Exposed
  
  
• The C Programming Language
  
  Also, have you used any new technology lately to make something cool? Schedule a time everyday (similar to when you read new things) to work on a project no matter what. Close Reddit, close your email, and get programming! Here a few things I had on the top of my head:
  
  
• Try making a web chat using SocketIO for the messaging and Node.js for the backend
  
  
• Ever used a MVC style framework for web development? Try out something simple like Flask then move onto something more complicated with Django.
  
  
• Learn Haskell
  
  
• Learn a dialect of Lisp
  
  Hopefully all of these can give you an idea of how to improve.

I've been pretty fortunate that I've been able to get interviews and job offers pretty easily within the game industry as a programmer.

I wouldn't consider myself a master programmer by any stretch and definitely don't spend as much time practicing on Code-Kata, etc as the poster. (The majority of my spare time is spent on unpaid overtime - if I can get that under control, then maybe I can apply some time to personal projects).

The 3 keys that I have found to make it easier to land the interview and the job is:

1. Networking - this is a MUST. If you know someone at the company that can vouch for you, sometimes the technical phone screen can be bypassed completely and it's a lot easier to position yourself above others when you have a good reputation before the interview. Call friends/colleagues that are still in the industry and ask if they are hiring or know anyone who's working somewhere where they are hiring. If there are conferences related to your specific industry (specialized types of programming), try to get to one of those and do what you can to get on a guest list for some of the company sponsored parties. Talking to people in a social setting goes a long way and is typically more effective that meeting a dedicated recruiting sessions.
   
   
2. Be energetic and friendly. Skills are only half the requirement, cultural fit and an easy going attitude go a long way to whether or not you'll get a job. How your potential colleagues feel about you is almost as important, if not more important, than if they think you are qualified (networking can help a lot to achieve this feeling amongst your potential colleagues).
   
   
3. Pick up this book and read it cover-to-cover: Programming Interviews Exposed. Most technical interviews ask questions from this book or variations of questions found in this book. Rarely do they really distinguish a good programmer from average/bad, but you're really competing with people that are good at interview questions and have seen them before vs people that are not or get a question they haven't seen. Every time I'm starting a new job search, I re-read this book, go over old programming tests that I saved and run through some of the problems from college programming tests on the ACM online judge website to get ready for obscure brain teasers.
   
   I can't really say whether the hiring process is broken or not, much of what they do does weed out people that really don't belong. But if you don't know the game or don't play the game, you may get swept to the side along with them.
   
   I hope this helps - good luck!

I'm finishing up my BS in Computer Science at The University of Texas at Austin. I've completed 3 internships at Microsoft (Office, Windows, and Visual Studio) in the summers of '10, '11, and '12, and I will be returning to the Visual Studio group in January as a full time employee.

I nonchalantly gave my resume to someone at the Microsoft booth at a job fair for science majors at my school. Got a call and had a short interview at the UT campus. The questions weren't very technical or difficult: "how do you test software?" and "write a function to shuffle a deck of cards." Long story short, I was invited to Redmond to continue the interview process (they do this for all interns). I had 4 different 50-minute interviews in Redmond. The questions were more difficult, but nothing too terrible. After all, these questions were intended for interns.

I wanted to get some experience with a different team for the summer of '11, so I re-applied and re-interviewed. I had 4 more interviews with folks on the Windows team. I got similar questions. I think it's important to say that you don't have to blow all of your interviews out of the park; I certainly didn't. I was very nervous during the first one and didn't connect with the interviewer. I screwed up writing a factorial function, if you can believe that.

I prepared for the second round of interviews by reading this book, and I found it to be fairly helpful. Although it can't possibly have every interview question, it prepares you for the types of questions you can be asked.

After my internship with Windows, I wanted to return to Microsoft, but on the East Coast, where Microsoft has some Visual Studio development. I did a phone interview and was offered the position based on positive feedback from former interviewers.

The link you gave is for research interns, which as far as I know are for Ph.D students. If you're interested in a non-research internship, you should visit http://careers.microsoft.com/careers/en/us/internships.aspx.

Hope that helps! Cheers.

I've found that I gained most of my best experience on the job, and that staying at a job where I wasn't learning anything was a huge mistake and detriment to my career.

That said... I don't think I'm a super genius either. I did well in college and my GPA helped with my first few jobs. But I have lots of hobbies outside of work, and rarely spend my time at home thinking about the office. A lot of times companies aren't looking for the super genius type either... if they were they'd have a hard time filling staffing requirements. I think the keys are learning how to interview well, focusing on letting the interviewer know that you're willing and good at learning and having the basics of OOO down to a T. Come off as confident, even if you don't feel it. It never hurts.

As far as books go, here are some of my favorites:


Programming Interviews Exposed


Programming Pearls


Refactoring



I'm mostly a java programmer, so here are three absolutely necessary java books:


Head First Design Patterns


Core Java 1


Core Java 2 - Advanced

Glassdoor.com is an incredible asset.

Microsoft has a ton of resources available for helping people to do well in interviews(they want you to succeed!), so search their website for info.

This is more for dev but this book http://www.amazon.ca/Programming-Interviews-Exposed-Secrets-Landing/dp/047012167X is really good and they will often pull questions right from it.

You're probably a cs student so I would go over your notes for whatever algorithms/data structures course you've had. Just because you are interviewing for a test position doesn't mean they won't ask you dev or pm questions.

They won't ask you any of those "How do you move mount fiji" questions so don't bother/worry about those.

Most of all though, relax. You'll probably ace it and Microsoft internships are a lot of fun. Good luck!

This is what I came here to write :) Also, see this book as well.

There's also a relatively cheap book on programming interview questions.

It's been a while since I interviewed, and some more specific information about the role would be helpful. But as general advice, you should do the exercises in Programming Pearls, and not as good but still helpful Programming Interviews Exposed. Project Euler also has good programming finger exercises.

If you need to write code on a white board practice that specifically.

There is also http://www.reddit.com/r/EmploymentAssistance/ but the top post is currently "Looks like this reddit fizzled and died." You could also try the programming or coding subreddits for advice particular to CS interviews.

It's good that you're already practicing up on a whiteboard. I think practice and knowing how to prepare are key for interviews (general statement is general). You should consider trying to set up practice interviews if you know anyone in the field with more interview experience. Or you could try explaining CS concepts and solutions to your friends. Perhaps you could get used to being at ease in an interview by practicing with someone you know.

There are various books you could buy, or perhaps find in a library, on interview help and using whiteboards in particular. I think I've seen this book recommended here before but I can't remember the context.

Good luck!

No problem. I looked more into the PDF and it appears that this edition/version explains the bare minimum of the data structures and algorithms so you are forced to use this as a reference. This book explains everything much better, but still you will need to use other resources: http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Programmer/dp/047012167X/ref=pd_sim_b_15?ie=UTF8&refRID=17FWN71ZH0FWQMJJKB2Q

If you have any more questions you can reply here or PM me.

...continued...

> Test plans - When you apply for QA roles, you'll almost certainly be asked "how would you test ____?". The correct answer is to be methodical. Don't just spew out a stream of test cases as you brainstorm them. Understand the different scopes (unit, functional, integration, maybe end-to-end) and what the goals of each is, and how they differ. Understand that there are different areas of testing like boundary, happy path, special cases (null, " ", 0, -1), exceptions, localization, security, deployment/rollback, code coverage, user-acceptance, a/b, black box vs white box, load/performance/stress/scalability, resiliency, etc. Test various attributes at the intersection of a compenent and a capability (borrowed from the book How Google Tests Software), and I believe you can see a video that goes into this called The 10 Minute Test Plan. Understand how tests fit into your branching strategy - when to run bvts vs integration vs regression tests.

> Test methodologies - Understand the tools that make you an efficient tester. These include data driven tests, oracles, all-pairs / equivalency class, mocking & injection, profiling, debugging, logging, model-based, emulators, harnesses (like JUnit), fuzzing, dependency injection, etc.

> Test frameworks - Knowing all the tests you need to write is good, but then you have to write them. Don't do all of them from scratch. Think of it as a system that needs to be architected so that test cases are simple to write, and new functionality is easy to implement tests for. I can't recommend any books for this because it's something I learned from my peers.

> Test tools - Selenium / WebDriver for web ui, Fiddler for web services (or sites), JUnit/TestNG, JMeter (I have to admit, I don't know this one), integration tools like Jenkins, Github/Stash, git/svn.

> System design - As you're entry-level, this may not be a huge focus in an interview, but know how to sensibly design a system. Know which classes should be used and how they interact with each other. Keep in mind that the system may evolve in the future.

> Whiteboarding - Practice solving problems on a whiteboard. The process is more than just writing the solution, though. This is the process I follow (based loosely on the book Programming Interviews Exposed):

• Clarify the problem - resolve any ambiguities, determine behaviors for special cases (throw an exception vs return null?). Look for gotchas (like if you're doing some string manipulation with overlaps)
  
• Give a couple test cases to demonstrate your understanding of the problem, to make you think of other special cases, and because they want someone who's test-focused if you go into QA. Give a happy path scenario and a couple negative or special cases
  
• Propose a solution - do this verbally, and give its runtime complexity (and less importantly, its memory usage). If the runtime complexity is bad (polynomial, exponential), then say so and think of a better solution (there will almost certainly be one)
  
• Implement the solution - verbalize your thought process while doing so. If you don't know something, say so. The interviewer will likely help you out without penalty. Listen very carefully for clues, because the interviewer will be giving them. Really understand everything the interviewer says, and understand his motivation for saying it. If you see potential bugs, say so ("I want to be careful that I don't go out-of-bounds in the last iteration of this loop").
  
• Debug the solution - walk through it as if you're a debugger, using the happy path test case that you made earlier. Oftentimes, the interviewer will give you a test case with the problem. Use it - he probably selected it for a reason (the numbers are in an interesting order that will find the most bugs, for example).
  
• Test the solution - Add to the handful of tests you gave earlier. Think about the different types of tests, and if they apply.
  
  Resources:-
  
  > Learning to test:
  
  
• How Google Tests Software
  
• Guice, and another
  
• Google Test Automation Conference
  
• Netflix's Simian Army
  
• Google Testing Blog
  
• Hermetic testing
  
• The Art of Software Testing (I've only skimmed it)
  
  > Learning to interview:
  
  
• Programming Interviews Exposed
  
• Programming Pearls
  
  > Learning to program:
  
  
• Design Patterns (I'm embarrassed that I don't have more recommendations for this...)
  
  > Miscellaneous
  
  
• Meetup
  
• Inventing on Principle
  
  > What sort of skills should I really hone? I realize I gave you a ton of stuff in this post, so here's a shorter list:
  
  

1. Read How Google Tests Software
   
2. Understand dependency injection
   
3. Understand unit, functional (use hermetic environments), and integration testing
   
4. Understand mocking (Mockito's a good one for java)
   
   > Examples of projects that make you look valuable
   
   

• Refactoring product code to be Guice-friendly
  
• Tool to profile method calls simply by adding annotations
  
• Tool to automate bug filing/updating/closing - assign to the right person, re-activate when they repro, give good steps, close when they're fixed and don't repro
  
• Tool to automatically quarantine flaky tests that aren't caused by product bugs
  
• Aggregation of distributed logs into central, indexed location (I didn't write the solution, just did the work to integrate an existing one (Logstash/Kibana))
  
• Automatically display the picture of the team member who checks in code with the highest coverage (I didn't do this, just something cool I read about)
  
• Tool that logs messages with contextual information, so for example you can see all messages associated with user 123
  
• Tool that captures inter-server traffic, associated with the user-request
  
• Tool that provides metadata about test cases in your web proxy
  

While it's a good idea to know a basic idea of what data structures there are, Programming Interviews Exposed was super helpful in reviewing important concepts as well as prepare me for my interviews. Honestly, I didn't learn my data structures properly the first time around for interviews, and that book and Cracking the Coding Interview were immensely useful for both algorithms and data structures.