Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So, I have recently had on-site interviews with Google and Amazon and received polite rejection letters letting me know I was close, but not quite right for the skills they were looking for.

I've made it to the final round for all the interviews I've done (except for some offers from small uninteresting positions that I interviewed with for practice), but so far having 5-8 interviews in a day gives me enough time to have my mistakes add up just enough to put me out of the running.

I know I did well there at least on the coding questions and other general technical questions, apparently I'm bad at designing OOP things like card games or parking garages though (I dove too deep into one object and used up all my time, instead of being broader) and my coding answers although they work overall didn't quite had a few bugs/edge cases I missed (like a case where an input node could actually could be the answer rather than needing to be distinct). And I have no problem saying "I don't know", but maybe I'm rambling a bit and need to say it for questions I think I can answer, but can't give a crisp answer to...

So, what are the things that push you over the top from being good, but not quite to "Hire"?

Any advise on what you look for or something you know that gave you that little extra boost?

share|improve this question

closed as off-topic by user16764, MichaelT, Robert Harvey, GrandmasterB, gnat Mar 7 '14 at 18:30

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – user16764, Community, Robert Harvey, GrandmasterB, gnat
If this question can be reworded to fit the rules in the help center, please edit the question.

Just to note I am apply for new grad positions (or approximately the same experience level). – Joshua Olson Jun 4 '11 at 8:50
The first thing you should do is work on your English. Presumably it's not your mother tongue, but still all the great programmers I have known cared about speaking and writing precisely. It's not "gotten", but either "got" or "have gotten" or "received". Not "interview's" but "interviews". "Dive deeply", not "dive deep". – kevin cline Jun 4 '11 at 20:28
Ouch, a couple of colloquiums and typos and "presumably it's not your mother tongue". That hurts. :P Okay I've fixed my ghrammer errers. – Joshua Olson Jun 4 '11 at 20:52
A colloquium is a meeting. – kevin cline Jun 6 '11 at 3:04
Colloquialism. Stupid spell check. – Joshua Olson Jun 9 '11 at 20:53
up vote 9 down vote accepted

First of all, I suggest you contact the HR representative at both companies and ask if they can give you any details on the "why". It's quite likely that they'll be able to give you some hints as to where you went wrong or what things you should work on.

Second of all, don't give up! If you really want to work for one of these companies, wait a few months, maybe a year and apply for a different job. It could be that you just didn't "gel" with one particular interviewer and if you have an interview with someone else, they'll say "hire".

Finally, if you think you did OK in terms of technical answers, then one important aspect that they're looking for is whether or not you're a "cultural" fit. That is, whether you are going to fit in with the rest of the team and whether your personality is a good match. Research the culture of the company and decide whether that's something you think you can fit in with and make sure you demonstrate that in the interview as well.

Good luck, and don't give up!

share|improve this answer
Unfortunately my recruiter at Google had a strict no feedback policy (Kept saying it was policy, but I know people have gotten "hints" on what to work on). – Joshua Olson Jun 4 '11 at 7:32
I did notice that everyone at Amazon kept talking about taking ownership, so I guess I should have played up that aspect more. – Joshua Olson Jun 4 '11 at 7:37
This is a good answer... I would add two things: First, try to learn how to read the overall tone of questions. If you get several questions about "ownership", then they might be afraid that you are going to come in and need excessive guidance or always be riffing on the "that's not my job" theme. Second, it really could be the case that you could work in the company, but just weren't the best fit for that team. Here, anything can have an impact. Maybe it was between you and another guy, but the other guy liked punk rock and mountain biking, just like half of the team does. – red-dirt Jun 4 '11 at 10:49
Amazon told me no feedback as well. Which kind of sucks because I'm sure they would have had great feedback... – Cervo Jul 4 '11 at 6:00
Nope. Amazon doesn't give feedback nor does MSFT. I have had similar experiences. Google does give a thorough feedback though when you go in house interview. I also have the same experience of failing in all the big 3 in-houses. The knowledge I have gained from them is quite significant. In addition to your skill set and your performance it attributes to some stroke of luck too. Improve your skill-set and take the battle again and always remember Robert Bruce and the spider :D – Venki Mar 19 '12 at 22:03

As Dean said, you are being assessed on multiple attributes, and these are usually:

  • Technical Skills
  • Whether you would fit into the team
  • Thought process
  • etc.

The technical skills requried for the role will differ depending on which team you are interviewing with, so if it doesn't work out with one team, you could (depending on the company) re-apply and find a better fit with another team. So don't lose hope!

The majority of technical skills are usually tested with coding problems. You mentioned that occaisionally you missed a border case and that a few bugs crept in (as they inevitably do when asked to code on a whiteboard). A good approach to answering these coding questions is to do the following:

  • Understand what is being asked (ask to repeat certain parts if necessary)
  • Ask clarifying questions (iteratively/recursively, Do specific constraints exist?, which language?, etc)
  • Identify appropriate data structures, algorithms, design patterns that may be used (Programming interviews exposed and Programming Pearls are helpful for this)
  • Write the code, whilst explaining out loud to the interview what your thought process is. If the interviewer knows what you are thinking, they may be able to identify problems in your approach early, and guide you towards a better solution.
  • Before telling the interviewer that you are complete, think and explain to the interviewer how you would test the software you just wrote. Think about simple cases, border cases, concurrency, whether the approach makes sense for other cultures, security implications, stress testing, etc.

Finally admitting that you don't know something is (IMHO) preferable to stumbling along trying to fake it. Granted, the interview is asking you to solve a problem, but if you don't know where to start, I'd recommend talking about the valid approaches and trying to narrow dow a correct one that addresses the contraints given. If you have no idea where to start, it may be time to explain that (This also ties into how you fit into the team. I'd say that it is better to ask for direction early). So I don't think that saying you don't know is a bad thing (assuming that it isn't all that is said =])

There isn't specifically much that you can do about fit, as often to comes down to a personal opinion of the interviewer, but conversing with the interviewer about what you're thinking/doing is preferable to coding in silence for 15min and then declaring "I'm finished".

Keep in mind that these things are usually a two way interview. They are not only interviewing you, you are also interviewing them. Feel free to ask questions about the job/team/company.

Finally, Microsoft recruiters post quite a fair amount of info on what they are looking for during a phone screen/interview so I'd recommed having a read. Additionally GlassDoor has a lot of info on interview processes for companies (but the user submitted answers aren't always correct). A google search for MS/Google/Amazon/Apple/etc interview questions will also yield results.

Good Luck.

share|improve this answer

This may sound elitist, but the brutal truth is that there may be nothing you could have done to get hired. They are looking for a certain amount of talent and not everyone has it. We accept this hard fact in the performing arts -- no matter how much some people practice, they will not be able to get hired at the New York Philharmonic. A Ph.D. in English won't enable you to write a great novel. This is also true for elite software teams. They don't interview to find people who know some specific technology. They interview to find people who will fit in: people with a deep view of programming, who can keep up with the team, follow fast-moving technical discussions, pick up new languages, bring in new ideas, create new technology.

==== 3/7/2014 ====

This interview with Laszlo Bock seems to agree. Google doesn't care about degrees or grades or test scores:

One of the things we’ve seen from all our data crunching is that G.P.A.’s are worthless as a criteria for hiring, and test scores are worthless — no correlation at all except for brand-new college grads, where there’s a slight correlation. Google famously used to ask everyone for a transcript and G.P.A.’s and test scores, but we don’t anymore, unless you’re just a few years out of school. We found that they don’t predict anything. ... There are five hiring attributes we have across the company. If it’s a technical role, we assess your coding ability, and half the roles in the company are technical roles. For every job, though, the No. 1 thing we look for is general cognitive ability, and it’s not I.Q. It’s learning ability. It’s the ability to process on the fly. It’s the ability to pull together disparate bits of information. We assess that using structured behavioral interviews that we validate to make sure they’re predictive.

share|improve this answer
Elitist and completely unhelpful. What's the point of answering a question if all you're saying is 'don't try you're too stupid'? – Joshua Olson Jun 4 '11 at 20:49
Plus, hiring for Google and Amazon isn't even in the same class as being a world class cellist, I'm not interviewing for Peter Norvig's job. Their hiring bars aren't anywhere near that high. – Joshua Olson Jun 4 '11 at 21:18
Sorry, but I definitely got the idea that you didn't fully comprehend the interview process. I've interviewed a lot of people, and have been interviewed many times. Studying for an interview from an elite team is about as effective as studying for the SAT. The interview is not a knowledge test. It's a test of problem-solving ability and clarity of thought, where code is the medium of expression. These skills are a product of many hours of programming and thinking about programming. Many hours here means "a lot of independent programming, unrelated to school assignments." – kevin cline Jun 5 '11 at 0:03
Lol. I wish. No, the interview process probably "shouldn't" be a knowledge test, but in SV it usually IS especially at companies like Google, Facebook or Amazon. Interviewing is absolutely a skill and the more you study it and practice it the better you get at it. – Joshua Olson Jun 5 '11 at 0:53
@josh - I've had interviews like that too. If the interview feels like a game of trivial pursuit, it is probably not a good place to work. If the interview is poorly organized, chances are the project is too. Teams that think about their software process will also think about their interview process. – kevin cline Jun 17 '11 at 19:46

It seems like you've already identified some areas yourself that you can improve in.

Combining those aspects with your previous question, without knowing anything else about you, I would recommend some effort on the engineering side, being able to design practical software and clearly communicate that design. Rather than learning more CS theory, read some books like Programming Pearls, Refactoring, C++ Coding Standards, and Code Complete. If one of the "uninteresting" jobs gives you responsibility over designing real software, take the job and make it interesting. In the real world, you often feel like this guy, but it can still be very satisfying to know you tackled a difficult problem, even though it may be in a mundane application.

share|improve this answer
I'm really not that picky. I just want to work on real software. Not little scripts here and there or just changing some if statements that were written 10 years ago to work with this slightly different business rule or algebra formula. – Joshua Olson Jun 4 '11 at 8:29
Working on the engineering aspect is why I'm looking for jobs at software companies (not b2b companies that have a software product or two). – Joshua Olson Jun 4 '11 at 8:33

Ok, just to throw in some practical experience here.

I work for one of these elite software firms, and I do not find our hiring policies to be geared to "not missing" great talent but to "not hiring" mediocre talent. I have seen that some of these companies really want to hire great people, but they do so by interviewing lots of really good looking (on paper) developers and then culling out the ones that they don't want. Once someone is hired, it is very difficult to get rid of them so it pays to turn down a candidate that you believe may actually be a great fit, but that one of the interviewers saw some red flags on.

At the company I currently work for, I was turned down because one and only one of the interviewers (the most important one) gave me a thumbs down. This interviewer asked me a very domain specific question and did not speak fluent english. They did not hire me, but the team thought that the company would be missing out on a potentially good hire. They sent me to another set of interviews with a different team the next week and I got the job (with "strong hire" marks I might add).

My advice is that if you really believe that you have what it takes, keep interviewing with this company and learn from each experience until you land the job. Most of these companies keep a registry of everyone they interview and they black-list the poor candidates (so they never get another shot). However, the candidates that were good candidates but just didn't perform well that day, or didn't fit well with the team will remain in the hiring pool. You will immediately know if you have been black-listed when the recruiter phone calls just stop one day and every future contact seems to hit deaf ears. If you receive future inquiries from the company, you know that you are fine. There is absolutely no harm in setting up more interviews after your first rejection as long as you weren't black listed. In fact, I would highly recommend interviewing with multiple teams all at once. The interviewers are going to reject you at the first perceived sign of trouble, whether or not it is a real trouble. They are cautious and don't want to make bad hires much more than they want to make good hires.

A few more thoughts:

--None of these companies are going to give you feedback. It is a legal liability. It sucks that this is the way it is, but I can promise you that it isn't going to happen.

--I personally talked to a brilliant engineer when I interviewed with Microsoft who told me it took him 5+ tries before he was finally hired. This guy was a senior level SDE, so MSFT obviously validated that he was a good hire by promoting him.

Some tips:

Know your data structures and algorithms backwards and forwards. You need to know everything all of the way up to graph traversals.

Know architecture, especially distributed systems and problems of scale

Have a list of projects you have led memorized. Have a list with examples of leadership principles you have exhibited in your job memorized. These are the most challenging questions to answer in the interview (behavioral interviews). You can be perfect in the tech side and if you don't survive the behavioral interview you will not be hired.

Don't worry about which programming languages they are looking for. Know one object-oriented language backwards and forwards and code in that. The interviewer doesn't usually care which language you code in and doesn't judge you based on it.

Finally, please email me your resume. ;=)

share|improve this answer

Not necessarily missed it by being wrong

Maybe you didn't do anything wrong, but someone else did better. Maybe in terms of personality, communication skills, inter-relation, similar past project experience etc.

You may have been just fine to be hired but it wasn't just you on the list. I wouldn't worry too much. Everything happens for a purpose.

share|improve this answer
True, but I've found the harder I work at something the luckier I get, so I'm just trying to find ways to make myself "luckier". :) – Joshua Olson Jun 4 '11 at 21:23
Nope, they very rarely have a limit on how many hires. If you make the cut, they hire you. They will find a place in the company for anyone that meets their standards. I have personally found this to be true for Google, Amazon, and MSFT. – Jonathan Henson Mar 7 '14 at 18:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.