What makes the difference between “Hire” and an honest “almost” for final on-site interviews?

Question

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?

Answer 1

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!

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.