Interview Process. 2 Google's Telephonic interviews which focus on basic problem solving and data structures; 2-4 Google's Coding Onsite interviews which involve whiteboarding solutions to slightly harder data structures / algorithmic problems. The lesser experienced you are, the more number of coding onsite interview rounds for you. I have finished my first round of interview with google for Software Engineer in Test position. If this forum is still active, then can any one say me what kind of questions or areas could I expect for this position in Software Engineer for Test for a second round of interview which is a tech interview. When it comes to the software engineering interview, recruiters and hiring managers look for a blend of technical acumen, collaboration skills and effective communication abilities. And, they also want a cultural fit, a technical match and a good feeling that you're going to stay with them for a while. Here's some of the questions you can expect during an interview. Glassdoor has 14 interview reports and interview questions from people who interviewed for Software Test Engineer jobs at Google. Interview reviews are posted anonymously by Google interview candidates and employees. 7 Software Engineer Interview Questions and Answers. Whether you are preparing to interview a candidate or applying for a job, review our list of top Software Engineer interview questions and answers. What programming languages have you used in the past? What are your top two programming languages?
- Google Software Engineer Salary
- Google Machine Learning Software Engineer Interview Questions
- Google Software Engineer Interview Questions And Answers Funny Video
- Google London Software Engineer Interview Questions
This post is about the interviewing / hiring process at Google. Parts of it may apply to other jobs at Google, or possibly engineering jobs at companies similar to Google. I hope this will give you some insight into how companies like Google operate, and might help you get a job there.
I’m posting this with a throwaway because I’m trying to be as honest as possible, and cut the usual corporate bullshit, and I don’t want to lose my job.
That being said, I like working at Google and would highly recommend it to anybody in the software engineering field.
This is pretty long - there are a couple of actionable tips at the end if you’re not interested in the whole process.
I'm a software engineer at Google, and I have been working there for 6 years. I have interviewed over 120 people in this time and interview people pretty much every week now.
So this is how it works.
First off, you must know that the recruitment organization at Google is run by complete and utter morons. Recruiters get hired and fired all the time, and almost all of them are completely useless. Trust me, I have interacted with a great many of them. They may not be bad (or dumb) people, but the environment in which they work makes it impossible for them to do a good job.
It is completely normal that they forget to call you, forget your interview half way through, reassign you to random people, or to positions which you are clearly not qualified for. Almost every single person working at Google has a story regarding recruiter incompetence which affected them or one of their friends. I referred 2 people, and they royally screwed up in both cases.
Now that that’s out of the way: you either apply for a job (usually via our website), or a recruiter contacts you, usually because they found you on linkedin (or similar) or because someone referred you.
Then a recruiter looks at your CV (more on your CV later), to weed out the people who have obviously no business working in IT. If you have a suitable degree (e.g. BS in CS, EE, math or physics), or a few years of experience, or are a contributor to some well-known open source project, then the game can begin.
Round 1: a recruiter calls you. They will ask you a few simple questions. Things such as 'what's faster, quicksort or bubblesort'. If you answer enough of these correctly, you get to the next round. If you fail here: stop moaning, go away and go improve yourself, there is no way you would have passed the later stages anyway.
Round 2: an engineer will call you, and interview you for 45 minutes. Only the 'best' interviewers get to do what we call 'first phone screens' because that's where the most people get kicked out. Sadly, I am one of them.
From the interviewer perspective, this is the absolute worst. About 1/10 candidates pass this step, because most candidates (even with master’s degrees and claimed multi-year experience) are completely incompetent.
So be prepared to talk to an engineer who expects you to fail, and would rather be doing something else.
I can’t tell you what exactly will happen during this interview, because different people have different styles, but from what I have seen it boils down to two main approaches:
The “cover as much ground as possible” approach. The interviewer will ask you 5-10 different questions spread out across your areas of expertise. I use this approach for people who are applying for sysadmin or systems engineering jobs. For example, a question about networking, a question about unix, one small coding problem, something about security and something about the web.
The “one hard problem” approach. I use this for software engineers, which I always ask to write code. You want to be paid to write code, so you better know how. Actually, I usually split this up into two questions: an easy “warmup” followed by a “real” question.
To give you an idea, a warmup question might be something like “reverse a string in place” or “implement atoi” or something like that. A good and capable engineer should be able to solve this in about 5 minutes. Sadly, only a minority of the people I interview ever get past this warmup question in the allotted 45 minutes.
I used to care much more. I used to try to help them. Try to make them feel good. But I can talk and talk, explain and explain, in the end we won’t hire you if you can’t reverse a linked list, or do a case-insensitive string comparison. I have done this so many times, I'm terribly frustrated about this. So now if you fuck up here, I’ll just let you talk for 20 minutes, say “uh huh” once in a while and review code in the meantime. And then I’ll ask you about “your most interesting project so far” or some bullshit like that.
Side note: if any interviewer starts out with a technical question, and then switches to “your most interesting project” or “the most complicated bug you have ever fixed”, this means one of two things:
a) Unlikely: You are so awesome that you ran the interviewer out of questions. This does happen, but very rarely. b) More likely, you are such a muppet that the interviewer would rather stab himself than hear you fail again. So he lets you tell a story while he zones out. In his rating, he will give you the lowest possible score, and this will end the interview process for you.
Now assuming that you made it past the warmup question, that you - congrats! - are part of the elite who know how to write a recursive function, or how to split a string by commas - then we get to the “real” question. I usually choose them so that they can barely finish it in the remaining 35 minutes.
Examples might include:
remove duplicates from a list of strings which is larger than the available memory (i.e. with reloads from disk)
count the number of disjoint objects in a bitmap
implement a program which plays tic-tac-toe
These are all pretty hard to do in 35 minutes. Most people can't, and it's not necessarily a failure if you don't get 100% there. But once in a while, when you are very, very lucky, you find a guy who finishes this, and has time to spare.
After the interview, we write a report about the interview (“interview feedback”), which includes a score. By the way, don't ask how you did, you won't be told. We are not allowed to because people might sue us (e.g. if an interviewer tells you you did great, but we don’t hire you).
That report goes to the recruiter, which will then decide whether they want to go on. If yes (mostly no):
Google Software Engineer Salary
Round 3: exactly the same as round 2, but with a different engineer. From the interviewer's perspective, second phone screens are infinitely better than first phone screens, because the totally incompetent have been weeded out already.
If you pass again: onsite interviews!
We fly you to one of our offices, where you will have 3 interviews of 45 minutes, lunch, and 2 more interviews. These are basically the same as phone screens, but you get to see the interviewers face to face.
If you totally suck, they sometimes walk you out after lunch, and skip the last two interviews.
Otherwise: the collected feedback goes to a committee of senior engineers who look at the feedback which was collected from you in 7 gruelling hours. They look at it for 3-5 minutes and decide whether you are hired or not. In exceptional cases, they decided that they don’t have enough information, and ask you to do more interviews. Hooray.
If they decide to hire you, the recruiter will call you and make you an offer. You will probably say yes, because we pay very, very, very well.
A couple of tips:
Google Machine Learning Software Engineer Interview Questions
Google Software Engineer Interview Questions And Answers Funny Video
This is probably the most important tip, so I’ll put it first: If we ask you to write a program, DO NOT start writing code immediately. Think the problem through first, and SAY OUT LOUD what you are about to do, then do it. If you are going completely in the wrong direction, we will tell you, and you won’t waste 20 minutes going there.
The recruiters are complete idiots and will likely forget you somewhere in the middle of the process. Do not be shy to call your recruiter if you don’t hear from them in (say) a week.
Ask questions if something is not clear during an interview. We want to see you at your best. If you are not sure what a question is about, or what we meant, ask immediately - you are playing against the clock. Yes, some of us time how long you take for an answer.
Make your CV short and sweet. We do look at them, but only if they are short. Unless you are a professor at MIT, two pages. Not three. Two. That includes everything.
Put your skills on your CV. We ask you what you are best at. If you list what you are best at, we will ask you about that. If your CV says “master of algorithms”, expect algorithms questions. If it’s not obvious from your CV what you are good at, we will ask what we feel like.
Do not put your high school, marching band, or girl scout experience on your CV. Nobody gives a fuck and it will not help you. It is more likely to harm you because it will distract from the parts that matter.
When you are asked a coding question, don’t be a pretentious prick and start writing down header includes, blather about “invariants” or “good programming practices” if you don’t know how to solve the problem. It’s perfectly fine to be a pretentious prick if you can solve the problem with ease, but not if you can’t.
Have fun guys.