Hacking a Google Interview (2009)

For the most part these interviews are not meant to evaluate the quality of a candidate, rather they are meant to evaluate candidate interest.

If it makes you feel any better, changing a few lines of code and glueing together APIs to send data from A to B is what 80% of Google engineers do each day too.

FWIW, I worked there and used this stuff. I think my interview was a good but incomplete window into what I would need to know to do the job.

That's exactly what I did for a FB interview 2 yrs ago, I essentially had a +4 hour session every day after work to practice programming questions. I thought it was fun, a nice break from the everyday "fix code and do 1:1s".

while i am not fan of algorithmic interviews every six months or so i come across text book algorithmic problems in my routine work which is nothing fancy just maintaining legacy code.Recently there was a library given by one of the big four's which had to be integrated into our system. It was working fine on pc but the moment it was brought into embedded system it started corrupting the stack, turned out that it was constructing the tree via recursive call which was blowing up the stack. We had to convert it from DFS to BFS to get it working. So i would certainly not discount value of having good knowledge of algorithms.

I understand what you're saying and I generally agree that algorithmic/coding interviews are broken. But you know what? Sometimes you need the fancy stuff.

I once stumbled upon a problem at work that, after some thinking, I realized could be modeled as a graph problem and solved by performing a topological sort. It was a good and elegant solution to the problem. But what if it hadn't landed on my plate, and instead on someone who didn't know a thing about graphs? The problem might not have been solved (which would mean great pain for our customers, since it was on a feature that customers directly interfaced with), or worse, someone else might have turned up with a horribly messy, spaghetti-like solution.

So I think companies should actually hire people who know their CS fundamentals, even if 80% of the time they'll be doing trivial work that someone less qualified could do. What matters though is having people that are ready for the hairy stuff when it comes up.

Thanks for sharing. You just got me interested in product management as well.

What are your thoughts on doing PM right out of school? I interned at Msft as a PM and SWE. Now I’m trying to decide between the two rolls.

Can you kindly reply to some of questions posted over there? For instance, I too would like to know the path (referral or direct or through interview platforms, etc) TIA

Short answer, yes. They don't expect a perfect answer but do expect something better than brute force (with presumably higher expectations depending on the level role). The better the answer is optimized the more impressive. Another part of it is the interviewers want to see at least some thought process. So if you stall giving the answer away you show alleged thought process and an excellent solution allegedly come up with on the spot.

>Most interview questions are taken from sites like Leetcode

For phone screens: sure. Frankly, a lot of people will bomb a fizzbuzz-level question at the phone screen so why bother spending time thinking of a good question that they might leak onto the internet, forcing you to take the time to make up another?

Interviewers tend to take the on-site a bit more seriously and will at least add an unusual wrinkle to a leetcode question to stump anyone who just has a great memory but very little actual ability.

> If you already know the answer, don't just blurt it out! They will suspect that you already knew the answer and didn't tell them you've seen the question before. At least pretend to be thinking though the problem before you give the answer!

Ah yes, deceit and trickery, the basis of any solid future working relationship.

>"> If you already know the answer, don't just blurt it out! They will suspect that you already knew the answer and didn't tell them you've seen the question before. At least pretend to be thinking though the problem before you give the answer!"

This to me epitomizes the absurdity of this whole "leet code, cracking the algorithm" mania that has blighted the tech interview process. The only way to pass these types of tests is to spend time studying them. But then if you have studied and therefore know the tricks(use two pointers etc.) its seen as unacceptable enough that you should either lie or tell your interviewer "I know the trick" to solving this so ask me something else." The whole thing has become a scripted charade.

I get it that these types of tests and interviews work for Google but it's absurd when small startups still building a product adopt these tests simply because Google and FB do it.

There's a sad corporate uniformity to it that feels very much at odds with the hacker ethos.

A better response would be honesty: "I've seen this question before on a (puzzle/interview prep/whatever) site. The optimal answer was better than what I initially came up with... I didn't consider that we knew one of the coins was explicitly heavier than the others, I was only thinking that one was a different weight. That's a good reminder to read your specs very closely."

Or something like that.

I dealt with this recently. Was asked to implement a LRU cache. I knew the trick, use two data structures to keep things sorted and accessible in constant time. Could do it in my sleep. Had to pretend I had never seen it before, started with a non optimize d solution and added the correct pieces to make it optimal. Interviewer seemed miffed, kept adding tests to see if my algorithm would get the wrong answer and seemed upset that I got it right. It was bizarre. Didn't get the job, didn't remember the answers to a few of the other questions, though I found them post interview.

Have you read it? If yes, how does it compare to other books specifically meant for interview prep like CTCI, PIE etc.

Not an interviewer in Google, but have been in Google.

I've read CtCI, used the mentioned and/or other websites for problem solving and have had 10+ interviews on pramp.com and interviewing.io, both as an interviewer and interviewee.

Due to my experiences and experiences of other people that I know, my conclusion is that the interviewing process has not changed. Google has a pool of thousands of questions, so you likely did not hear the questions that they'll ask you before coming there, unless it's the question to establish whether you're a programmer at all or not (phone screen). Like learning to drive -- you don't go out and memorize every road by heart, but learn how to act on the road and interpret situations, signals and signs. Those resources shouldn't teach you the questions, but teach you how to really be you in an interview and perform at your nominal level.

After going through the above resources, my impression is that they have helped me type faster, make less mistakes in boilerplate and think more about the problem when it's given, before diving into it. Certainly, I do remember a few "tricks" more than I used before going through them, but overall, I think they've helped me very little with the problems in interviews and more with my behavior in interviews. The pattern that I've always seen is that intelligent people who code well pass the interview more often than not and that less intelligent people and/or those who don't code well don't pass ever.

My employer (albeit not so large on the engineering side) seems to have doubled down and are mandating teams use HackerRank to give remote tests, whereas before teams had more flexibility to do better/worse with the process or do the standard thing. I find it absurd, and am glad intern interviews are still flexible for now...

Can you post links to any updated materials?

I get really nervous with timed interviews, ticking clock freezes my mind.

Wondering if you have any tips for that.

I code in java at my day job but its not really well suited for whiteboard interviews where I have write all this code on the board. Google interviewer was noting down what I was writing on whitboard and said that he will compile the code after the interview. Wondering if you have any thoughts about it, maybe choose something more consise like ruby?

> Or point folks to some notes from an updated version of the class.

I would love to get updated version of notes.

Could you provide a link to some notes and updated version of the class?

I'm rarely this late ...

Pardon me when I ask what do you mean by turn-over? My guess is the average amount of time an engineer stays with the company.

Why do you think that is?

How does the turn-over matter?(genuinely asking)

That's because whatever statistic you pulled doesn't account and adjust for Google's growth which is massive in the past couple of years. If a majority of employees are new hires, then they haven't been there for 2 years and that drags down the average....

We need to stop repeating these statistics with no context. It's incredibly misleading.

1. The stat is misleading 2. For the experience, money and prestige (looks good on a CV).

Source?

>"Given the turn-over at Google is barely 2 years,..."

What is the source of this statistic? Do you have a citation?

You should've mentioned that email address is required and solutions are $25 a month. But other than that good idea if the actual puzzles and solutions are valuable.