Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Ace the Google Interview: Ultimate Guide

byte-by-byte.com

Post reply on HN
Print view View original

181–190 of 239 posts

Re: How to Ace the Google Interview: Ultimate Guide

#181

Post by Traster »

hardwaregeek wrote: post #94

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…

The flip side of this is that having worked at big companies like this I can comfortably say that our bar for new employees is WAY higher than the quality of our current staff.

No one at Google is going to recommend hiring you if they think you'll be in the bottom 50% of engineers at Google when you join. However, 50% of the people hired by Google end up in the bottom 50% of engineers. And frankly, hell there's plenty of jobs that don't require a rockstar. So in many ways you need to be better to get the job than to do the job.

Re: How to Ace the Google Interview: Ultimate Guide

#182

Post by hypertext7 »

koala_man wrote: post #173
str33t_punk wrote: post #40

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…

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.

Re: How to Ace the Google Interview: Ultimate Guide

#183

Post by optimize »

_hardwaregeek wrote: post #168
akdas wrote: post #157

Earlier quoted context omitted.

> If you don't like programming and if you don't like learning, then are you really gonna like Google? There are also many people who are great at programming, wh love it, who are terrible at interviewing. After all, these are two related, but ultimately different skills. You talked about it yourself in your last paragraph, ending with: > But there's something wrong about having to play a game to get the job. Sounds…

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 programming and computer science, thats a pretty sweet deal.

Re: How to Ace the Google Interview: Ultimate Guide

#184

Post by tempguy9999 »

oarabbus_ wrote: post #160
jefftk wrote: post #117

Earlier quoted context omitted.

I also interview software engineering candidates at Google (n=150) and while I mostly agree, I do think there's some signal in whether a candidate can get the syntax right. It's not a dealbreaker if they don't, but all things considered someone who comfortably writes code all day is more likely to be able to write syntactically correct code than someone who doesn't. The main things I want to see, though, are: can you…

> I do think there's some signal in whether a candidate can get the syntax right. I know you're talking about software engineers, not data analysts, but: select from [oops... you're supposed to put an asterisk there] select , count(field) from [holy shit... I forgot the group by] select , case when then else from [oh man, case statements need to be terminated with an `END`] select , from [oh no... SQL doesn't like th…

> > I do think there's some signal in whether a candidate can get the syntax right.

> I know you're talking about software engineers, not data analysts, but:

(inserts self-pwn car crash here)

I've done SQL for ~20 years and I'd say I'm good at it. I don't make as many mistakes as you've described but I know exactly what you mean, and I'd never hold that against you because I don't give a toss about mistakes that the language will catch.

I've rarely interviewed others, but when I did I asked high-level stuff approaches. I wanted to see if they could grasp the solution, not the physical framework.

Actual example: you're given a large collection of words, which you're allowed to pre-process - you have plenty of time to do this. Later on you are given another word, how would you very quickly find all acronymns of that word?

(inerviewee programmer didn't get it, so I tried it on a non-programmer we had around - she very quickly worked out you ordered the letters and saved them - she didn't explain it clearly (to repeat, she wasn't a programmer) but in programmer terms it was a dictionary with keys as the sorted letters and the values as a set of the words).

In this case, would you employ the supposed programmer who didn't get it, or the non-programmer who did?

Actual example: Show me how you'd represent an arithmetic expression using objects, and how you'd evaluate it in an OO style (was after class hierarchy of (op, leftexpr, rightexpr and .eval method. With plenty of time and pushes in the right direction, he still didn't get it despite claiming good OO on his CV)

(True story: to same guy who didn't get the OO expression question, I started off with an SQL question. His CV said SQL was his strong point, so I gave him an easy one: "explain to me what a left outer join does". He shook his head in confusion "Never heard of it". Actually happened! I'm not even exaggerating!)

Re: How to Ace the Google Interview: Ultimate Guide

#185

Post by yoz-y »

Zelizz wrote: post #87
seanmcdirmid wrote: post #46

Earlier quoted context omitted.

I thought you were allowed to assume functions you needed in the interest of a modular solution. Array.flatten is an obvious “assume I have this, I would write it anyways.” I think most decent interviews will give you a pass on an enhanced standard library.

When doing an interview at Google in C, I asked if I could assume I had a hashtable implementation with so-and-so interface, and the interviewer said no ¯\_(ツ)_/¯

This depends on the question but I assume that in this case the interviewer wanted a different solution than one using a hash table.

Re: How to Ace the Google Interview: Ultimate Guide

#186

Post by MRD85 »

chollida1 wrote: post #84
peter_l_downs wrote: post #53

Earlier quoted context omitted.

Which elite schools? I went to MIT and didn’t have to do any of this.

https://courses.csail.mit.edu/iap/interview/materials.php

That seems really easy for MIT. I'm towards the end of my 2nd year at a regional university in Australia and nothing there seemed that bad.

Re: How to Ace the Google Interview: Ultimate Guide

#187

Post by blackflame7000 »

int_19h wrote: post #156
sanderjd wrote: post #149

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…

Exactly! The field is so large and growing rapidly that it’s unnecessary to memorize the inner workings (especially down to the node pointer level in c++ where you’re begging for trouble and it will be a nightmare to maintain unless you have a performance specific reason not to use the stl)

IMO being able to say “I don’t know the the specifics, but I would use dijkstra’s algorithm on this problem” shouldn’t disqualify you because you couldn't code it.

Re: How to Ace the Google Interview: Ultimate Guide

#188

Post by emmelaich »

sanderjd wrote: post #89
emmelaich wrote: post #33

Earlier quoted context omitted.

I've had people interview for a Java job who didn't realise strings were immutable. The question asked was a very short multiple choice; only two of the answers were possible under immutability.

That doesn't sound like a good question at. It sounds like you're looking for "Java programmers" instead of solid engineers. When I interviewed for my current job using Java, I had been programming in Ruby and JS for the better part of a decade and had to refresh my Java syntax fairly quickly. I know I made some dumb syntax mistakes in my phone interview, like instantiating collections totally incorrectly. I distinct…

You're right that it is not disqualifying even if the Java expertise is essential for the job and the candidate describes themselves as a Java expert. This was a single short question among many though. And it's pretty fundamental to Java methinks.

BTW, they still got hired and proceeded to be a solid productivity reducer and all round waste of time.

Re: How to Ace the Google Interview: Ultimate Guide

#189

Post by retiredcoder »

int_19h wrote: post #152
otabdeveloper2 wrote: post #146

Earlier quoted context omitted.

> This is clearly a useless skill as a software engineers except in getting a job at companies that do whiteboard interviews. Have you ever actually been on the interviewer end of the process? Literally over half of the candidates literally don't know how to program! They can sort of string together a Markov-chain something if you sit them down in front of an IDE and let them copy-paste stuff until syntactic errors g…

I have been on the other end of the process more than once, in different companies and countries, and I have literally never seen anything like that.

Me neither. Quite common deal breaker I seen is mismatch of expectations (e.g.: candidates applying for senior positions with experience to lead bigger projects, etc) but never seen gross incompetence like that (so that I am not even sure if GP is being literal or not).

Re: How to Ace the Google Interview: Ultimate Guide

#190

Post by retiredcoder »

defen wrote: post #112
dominotw wrote: post #73

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. :/

> 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.

Post reply on HN