Taro Logo

Software Engineer Interview Experience - Mountain View, California

July 1, 2016
Positive ExperienceGot Offer

Process

Emailed recruiter (June 19) whom I had applied to last year, asking to apply again. On June 30th, I was contacted to schedule a phone screen for July 7th. Then, we scheduled a phone interview for July 12th.

The phone interview began with solving a fairly straightforward technical problem. After coding it in Google Docs, we discussed how to solve the problem in a scalable way. This went very well, so I was called the next day and invited to come on-site.

On-site (July 27th) consisted of five interviews:

Interview 1:

  • Straightforward tree problem, solved without much of a hitch.
  • Extended the same problem to work for a forest of DAGs. I had to rewrite the entire code, but this was actually easier.
  • Discussed a third, more difficult problem. It was very similar to a problem I had already seen before, which I mentioned, but we continued, and I provided the solution after a bit of recalling.

Interview 2:

  • Straightforward array-of-objects question, went smoothly. I performed some optimization that made it use constant memory in some instances.
  • Float array problem, which I mentioned I had seen before. He suggested moving on, but I stated I had an answer I thought was better than the more obvious solution. I shared it, and he said he'd never seen that solution before and agreed it was better for many instances.
  • Complex integer array question. I was stumped for a while and needed some help. Eventually, I arrived at an O(n^2) solution. The next day, while thinking about it, I figured out an O(n log n) solution, so mine was suboptimal.

Interview 3:

  • Integer array question. I told him I'd seen it before, but he said that was okay. Solved without issue.
  • Tree question. Solved with a little help. It was a bit messy and suboptimal; I came up with a much cleaner solution after the interview.
  • System design-related question. I had about three minutes left. I shared my thoughts, and he said it was "in the right direction," but I'm unsure.

Interview 4:

  • Integer array question. I immediately blurted out a solution (which I kind of regretted), but he said, "Okay, then code it," which I did without a problem. After coding it, he asked how to make it faster. I thought about it and arrived at the optimal solution without help, but he didn't want me to code it.
  • String array question. Again, I gave a brute-force solution and then coded it. However, I had a lot of trouble getting better than brute-force, perhaps for five to ten minutes of not getting anywhere.

Interview 5:

  • Talked very briefly about a project I did last summer. She seemed keen to move past it quickly.
  • She asked two questions, both of which I had seen before, which I told her. I quickly provided the solutions for both, and she did not ask me to code them. The first question was a string/palindrome question. The second was about a series of lightbulbs.
  • The third question was an extension of the first, which I solved but needed a little guidance at the end. She seemed pleased with my use of StringBuilder.

Three business days after the interview (Wednesday), my recruiter informed me that she had received feedback from three of the five interviewers, and it was "very positive." That Friday, I was told the hiring committee had recommended me for hire. The following Friday (what a nerve-wracking week) I received an official offer (August 12th).

Advice: BUY "CRACKING THE CODING INTERVIEW." I went through the entire book, cover to cover (skipping language-specific and database chapters, as well as the "hard" chapter), and wrote solutions on paper. About a month before my interview, I started writing solutions on a whiteboard and began talking through the problems aloud. I highly recommend this.

About two weeks before the interview, I studied problems on careercup.com, which I believe was very influential to my success. If you do this, it is essential that you tell the interviewer when you encounter a problem you've seen before. If you don't, they may observe how quickly you solve it, which could hurt your interview rather than help it. Additionally, disclosing this earns you "honesty points," which can be beneficial. Four of the questions I was asked were ones I had seen before exactly.

Finally, don't give up! Two years ago, I tried to get an internship. The phone interviews went terribly. The next year, I got on-site, but the interviews only went okay, and I was rejected. This year, I prepared for months, and it really does pay off, even if your previous interviews were not so good.

Questions

The NDA makes me paranoid. I don't think the questions are technically confidential, though.

Was this helpful?

Interview Statistics

The following metrics were computed from 748 interview experiences for the Google Software Engineer role in Mountain View, California.

Success Rate

20%
Pass Rate

Google's interview process for their Software Engineer roles in Mountain View, California is very selective, failing most engineers who go through it.

Experience Rating

Positive64%
Neutral23%
Negative14%

Candidates reported having very good feelings for Google's Software Engineer interview process in Mountain View, California.

Google Work Experiences