Live data from Hacker News

How to Ace the Google Interview: Ultimate Guide

byte-by-byte.com

201–210 of 239 posts

Re: How to Ace the Google Interview: Ultimate Guide

#201

Earlier quoted context omitted.

None of that rings true to me. Like I said, I really dislike the way we do interviews, but I find this to all be exaggerated to the point that it weakens your argument.

I think the point is that you don't need to understand the gory details of how e.g. your hashtable works - for most coders, it's sufficient to know that it exists in the standard library; it's O(n) on space; it's amortized O(1) on retrievals and updates, but can be O(n) on some inputs; and that there is a class of security issues related to using untrusted data as keys. They don't really need to know why all these th…

Right, and my point is that interview questions don't actually tend to be of the form, "write me a good hashtable implementation from scratch". They do tend to prod whether people can take advantage of the trade-offs between the properties of maps vs. lists.

My point is that there is plenty to complain about - unrealistic time pressure, writing on a whiteboard, only testing coding when that is the least interesting part of a senior developer's job, no opportunity to test and debug, etc. - that it isn't necessary to bring up these exaggerated boogeymen about how everyone is asking for novel algorithms on-the-spot.

Re: How to Ace the Google Interview: Ultimate Guide

#202
post #112

Earlier quoted context omitted.

> He said it will compile it and submit report when he gets back to his desk. :/ So, he's asking you to do something he can't do? Why can't he just read your code and know how it will behave?

Someone above him might have decided that’s part of the process. I am starting to think that most of those decisions are made by burocrats who have no accountability on the actual results, specially at Google where they can afford to lose great candidates left and right.

This process is very well designed to put all the cards in the employers hands.

Imagine if most highly compensating employers made the barrier to entry so absurdly difficult, you would no longer consider looking for new positions every 1-2 years to grab new offers/seek larger raises. Obviously, this isn't sustainable long term but it sure will reduce turnover rates if you can get a small cartel to follow suit.

Re: How to Ace the Google Interview: Ultimate Guide

#203

Earlier quoted context omitted.

Agreed, the fault is with the employer, but the people who are willing to indulge this game by obsessively learning to play it don't help.

I mean, if you want to work at Google and the likes, you need to indulge in the game right? And working at Google isn't just about the pay and the salary - thats quite a shallow thing to say. Engineers there handle data of astronomcial proportions, scale their systems every second to handle the ever-growing traffic, innovate on solutions that are used by millions of people around the world. I'd say, if you truly love…

The people who spend their days obsessively networking and practicing interview questions are generally not the people who would find problems about scaling to handle astronomical proportions of data interesting. The people who find that interesting tend to spend their days reading about scalability and performance. I'm not talking about someone putting aside a few weeks to a month to study up on these questions, I'm talking about people who straight up neglect their CS education because they want to pass a technical interview.

Re: How to Ace the Google Interview: Ultimate Guide

#204
post #135

Earlier quoted context omitted.

hard to write heap sort in functional style with immutable collections. I guess you could write imperative style code.

I used clojure once during an interview and bombed, passed again 2 years later at the same company with Python. Would’ve made a big difference in my equity had I just started then!

Yea functional langs just get in the way during interviews. I can write same imperative code i write in java in scala but it just makes it harder( eg: remember to use var instead of val, mutable collections vs default mutable ect) at which point I am just better off practicing for interviews in java.

Re: How to Ace the Google Interview: Ultimate Guide

#205
post #141

Earlier quoted context omitted.

I had to write code exclusively on white board last month. Only laptop in the room was interviewers which he was using it exclusively to furiously copy the code i was writing in the whiteboard. He said it will compile it and submit report when he gets back to his desk. :/

I've done nearly 100 interviews at Google, at least half of them with me copying code from a whiteboard, and I have never tried to compile a line of code that a candidate wrote. I also go out of my way, to make it clear that I don't care about every hanging parenthesis, indentation, or typo. I care about whether or not the candidate asks for clarification, or bulls ahead with assumptions, whether the overall algorith…

OK so of the 5 interviewers, 2 did this. Others seem to not care. Do you know if "must compile" is a google wide rule that some interviewers just ignore?

Re: How to Ace the Google Interview: Ultimate Guide

#206

Genuine Question: Apart from maybe the money or a nice resume entry, why would you/do you want to?

I don't work at Google (and I don't agree with some of the things the company's decided to do) but have many friends who enjoy working there. From what I hear, Google has an organizational structure that is very favorable for regular engineers. Once you're hired and you put in around a year of work in a team, it's almost trivial to find another team. Engineers also directly evaluate managers and I've heard stories of…

Compared to many companies where managers make a lot of decisions in a room with no feedback given to or received from engineers, it's heck of a lot better.

I'm not so sure this is better. I was an individual contributor for over ten years until I became a manager a couple of years ago, so I've seen both sides of this coin. My experience has been that typically engineers aren't interested in understanding all the non-technical things that are necessarily part of the decision making process, or worse think of these things as beneath them, asinine, or "easy". Much of the feedback from engineers is negative, not useful due to an overly narrow focus on specific tech stacks or solutions, or lacking context. Sometimes the context isn't there because of poor management decisions to not be transparent but often it's not there because the engineers' bias results in them not seeking it out. Very few things are black-and-white, and certainly it's better to include engineers' in the decision making process at some level, but that's a two way street--maybe engineers could work a little harder to overcome their own erroneous biases.

Re: How to Ace the Google Interview: Ultimate Guide

#207
post #133

Earlier quoted context omitted.

I agree with your comment in general, but, I worry about the bias of "Bring your own laptop set up to be able to code and debug" - some perfectly qualified candidates don't have laptops. Some perfectly qualified candidates do have a laptop but don't code much at home, and the setup they're used to is their work machine or a school lab computer. We already have too much bias in favor of code-all-day-code-all-night can…

> some perfectly qualified candidates don't have laptops So get one. You can get a good one from the pawn shop for $200. You can afford that if you're interviewing for a 6 figure job. Edit: I'm not kidding. I've bought $200 laptops from the thrift store, usually for travel purposes so I don't worry about losing/breaking it.

How do you afford $200 if you're interviewing for a six-figure job but don't yet have a six-figure job? Personal loan?

(Also, that doesn't address the question of getting a working decent setup, if you're not otherwise using it.)

Re: How to Ace the Google Interview: Ultimate Guide

#208

Earlier quoted context omitted.

Have you worked with any great, experienced engineers who would have had no idea how to traverse a tree?

Yes, and those same great engineers went ahead and figured it out. You see, some are hiring parrots, and others are hiring problem solvers.

I'm all for hiring problem solvers, but how do you differentiate them if you don't ask them to solve problems?

Years of experience is definitely not a guarantee of competence.

Re: How to Ace the Google Interview: Ultimate Guide

#209

A friend said recently, "people want to be employed without becoming employable". These guides really exemplify this obsession. Sure, Google has a nice salary and good perks and whatever. But after you get the job, you have to do the job. I wonder if the people who read these guides and try to study just the right topics to get a job, whether they actually like programming. These guides act as optimizations, shorteni…

Learning to be good in interview doesn't make you bad at programming.

Theses are 2 skills totally different and not exclusive at all.

A skill need to be learned and practiced. In the case of interview, for a pretty good reason, it's not a skill that we practice usually and once you need to do it, you lack experience and fail even though you could have what needed to do the job.

Re: How to Ace the Google Interview: Ultimate Guide

#210

I hate these style of interviews. I give them to prospective engineers every week for one of these FAANGM companies. They don't test for good engineers -- they test for people who practice these style interviews, and for good new graduates. It makes sense to ask these questions to new grads, but afterwards there is so much more experience that I feel like is much more important than acing data structures questions. I…

> I am amazing at whiteboard questions, but that doesn't make me a good engineer. ... A lot of it it is practice 'ooo this looks like a graph problem, let me use a graph', etc.

That actually does make you "a good engineer". The vast majority of developers wouldn't even be able to recognize that much.

Post reply on HN