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

211–220 of 239 posts

Re: How to Ace the Google Interview: Ultimate Guide

#211

Post by jefftk »

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…

Again, I don't think this is the only signal, or the most important signal, but there's still signal there. Imagine I get two data science candidates who seem basically the same and say they work in SQL daily. One of them can comfortably write out a JOIN with a GROUP BY and an ORDER BY when the problem calls for it, the other struggles and makes a lot of errors. I'm going to guess that the former is better at SQL, acknowledging that this is an imperfect proxy.

I'm also not nearly as picky as a compiler/interpreter. I can tell what you're trying to write, and lots of people make silly mistakes. But a high volume of mistakes, or especially difficulty getting anything substantial out at all, those start to make me worry.

Re: How to Ace the Google Interview: Ultimate Guide

#212

Post by segmondy »

retiredcoder wrote: post #178

I interviewed with Google NYC for Senior Dev position once, prepared well and thought it went well. Received the green light and moved to the next phase, where I spoke with potential teams over the phone, then settled with Google Maps. Met with one of their Tech Leads, cool. I was really happy and though that all my effort to prepare for the “Google interview” had payed off. Then no word back from the recruiter with…

Sounds like the typical FANG experience.

Re: How to Ace the Google Interview: Ultimate Guide

#213

Post by ThrowawayR2 »

estomagordo wrote: post #171
awiesenhofer wrote: post #7

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

Very smart co-workers and the potential to be part of building software that solves a specific problem on a scale that nobody else on Earth has attempted.

Bingo. If you actually like CS, instead of just seeing programming as a way to get a fat paycheck like so many seem to, why would you not want to be part of FAANG or some other company building cutting-edge products and work on building some of the most advanced systems in the world?

Re: How to Ace the Google Interview: Ultimate Guide

#214

Post by hypertext7 »

koala_man wrote: post #208
hypertext7 wrote: post #182

Earlier quoted context omitted.

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.

Hypothetical interview question: Write a function that finds the distance between two words.

Candidate A: Can recite algos and remembers that Levenshtein distance is the answer.

Candidate B: Has no idea what Levenshtein distance is, writes a brute-force solution with the understanding that it's not an optimal solution. After the interview she spends more time learning what she doesn't know, learns about Levenshtein distance, and sends you an optimal solution via email.

The above is a real-life scenario, so my question to you is - how do you decide who to hire?

Re: How to Ace the Google Interview: Ultimate Guide

#215

Post by dilyevsky »

retiredcoder wrote: post #192
dilyevsky wrote: post #51

Earlier quoted context omitted.

Google used to run “how to interview with Google” multiple day bootcamps where they’d train you to pass its interviews. I’ve gotten couple of those candidates and thought it was just ridiculous.

I think it is sad, it comes from your own employer (I understand you work for Google, correctly if I am wrong).

Not for a couple years now. Don’t know if they kept this program, I personally noticed only superficial improvement.

Re: How to Ace the Google Interview: Ultimate Guide

#216

Post by koala_man »

hypertext7 wrote: post #214
koala_man wrote: post #208

Earlier quoted context omitted.

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.

Hypothetical interview question: Write a function that finds the distance between two words. Candidate A: Can recite algos and remembers that Levenshtein distance is the answer. Candidate B: Has no idea what Levenshtein distance is, writes a brute-force solution with the understanding that it's not an optimal solution. After the interview she spends more time learning what she doesn't know, learns about Levenshtein d…

This is not a good interview question and neither candidate seems to have answered it well, but I would reject B first because I obviously don't know whether she did any research or whether she just asked Candidate A via StackOverflow

Re: How to Ace the Google Interview: Ultimate Guide

#217

Post by justrudd »

perturbation wrote: post #139
justrudd wrote: post #64

Earlier quoted context omitted.

I'm still floored by how many candidates I've talked to that assert with great confidence that the local variables they declare will still be there with the same values when they call the function recursively. And most recently, when iterating over a string's characters the underlying string methods KNOW that the string is being iterated and will pick up at the current iteration point. For example, you've got the str…

https://github.com/yuki24/did_you_mean#installation : Ruby 2.3 and later ships with this gem and it will automatically be required when a Ruby process starts up. No special setup is required. It doesn't call the method for you, but it does do the did-you-mean automatically if you misspell and it's close enough.

Maybe this what they meant? I dunno. I can see this being helpful in irb/pry.

In the end, we did end up making an offer to this candidate. They did well on everything we asked them. This was the only "brain fart" they had.

Re: How to Ace the Google Interview: Ultimate Guide

#218

Post by vkou »

dominotw wrote: post #205
vkou wrote: post #141

Earlier quoted context omitted.

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?

I have personally never heard of 'must compile'.

I have also never received any negative feedback from hiring committees or managers about how I conduct my interviews, what I focus on, or how I analyse candidate performance.

Re: How to Ace the Google Interview: Ultimate Guide

#219

Post by ChrisCinelli »

geofft wrote: post #133
ChrisCinelli wrote: post #37

Earlier quoted context omitted.

I completely agree. Even Google suggest to "practice writing syntactically correct code on a whiteboard". This is clearly a useless skill as a software engineers except in getting a job at companies that do whiteboard interviews. Did you try to refactor code on a whiteboard? How are they able to find people that are able to efficiently debug problems? When I interview people I tell them, "Bring your own laptop set up…

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…

I did not write it for brevity.

Some people live on their company's computer and when they leave they do not have one.

Yes, I always add "there is a machine set up for you if you do not have one". That said the machine has a generic setup with most common editors but no plugins. But good engineers will probably have a script on a Github Gist or something like that will setup the machine as they want it.

In general, a candidate with their own setup will do better. I think this is one of the reason that big companies do not let people use their computer.

Re: How to Ace the Google Interview: Ultimate Guide

#220

Post by int_19h »

sanderjd wrote: post #201
int_19h wrote: post #156

Earlier quoted context omitted.

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 p…

I've seen plenty of interview questions that do boil down to "implement this algorithm" or "implement this data structure". There are similar examples in comments on this very discussion.
Post reply on HN