How to Ace the Google Interview: Ultimate Guide • Hacker News Board

Re: How to Ace the Google Interview: Ultimate Guide

#81

Post by sanderjd » Wed, Apr 24, 2019, 2:04 AM UTC

ahelwer wrote: post #36

strikelaserclaw wrote: post #30

Earlier quoted context omitted.

learn with the intent to become a better engineer, even if you don't hit the google mark (which is arbitrary anyway), you will become a better engineer. That is the philosophy most people should use when trying to aim for these companies. Don't cram, learn.

I disagree. Doing competitive-style programming and learning all sorts of weird algorithms has not made me a better engineer. I can count on one hand the number of times in my career that I have had to design or use an "interesting" algorithm - and no, not in the "not knowing what you don't know" sense where I could have used one if only I'd known about it.

I'm very critical of this approach to interviewing in general, but it also isn't the same as competitive programming and it isn't focused on "interesting" algorithms. It is far more focused on understanding how to use data structures and the trade offs between them. Chapter 3 of "The Algorithm Design Manual" (which is fittingly titled "Data Structures") is really the most useful reference for the majority of these interviews. I don't think this is the most useful thing for software developers to be good at, but it's definitely useful and worth learning. I was annoyed that I had to study for one of these interviews, but ended up being pleased that it forced me to review this material.

Re: How to Ace the Google Interview: Ultimate Guide

#82

Post by [deleted] » Wed, Apr 24, 2019, 2:07 AM UTC

asaph wrote: post #26

simmanian wrote: post #18

Earlier quoted context omitted.

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…

> I've heard stories of mid to high level managers crying in bathrooms because of poor reviews from their reports. Is this your idea of an engineering nirvana? Does engineering happiness have to come at the expense of manager happiness?

[deleted]

Re: How to Ace the Google Interview: Ultimate Guide

#83

Post by cmurphycode » Wed, Apr 24, 2019, 2:08 AM UTC

hermitdev wrote: post #65

They lost me when they got into showing how to make the 'dups' function faster. The author definitely either doesn't understand big-O notation or doesn't understand the complexity. Their O(1) implementation is anything but. Likely O(n×log(n)) at best. Also, their brute force implementation is unnecessarily verbose. Want dups? from collections import defaultdict def dups(seq): d = defaultdict(int) for x in seq: d[x] +…

Hmm. I don't think they claimed to have an O(1) time solution, just O(1) added space. Which, it is, but only because they're counting on the original array's underlying type having enough bits for their sign flipping. It would be as if you used a more compact type for the array elements, and then allocated another bitmap for the range of numbers.

Of course, once we start optimizing how the original array is stored, we may have exceeded the limits of this problem as a teaching exercise :)

As for time, it does seem to be O(n) to me; can you clarify why you think it's nlogn? It may not be particularly fast in practice when compared to other O(n) approaches like the bitmap, but I don't think the complexity is wrong.

Your solution is nice - it actually gives you more information (how many appearances, not just T/F >1 appearance), but it does require more additional space and isn't necessarily faster. I think the bitmap approach would be nicer if you're ok with using more space; the bitmap is essentially a very easy to find perfect hash function due to the unique input constraints.

Re: How to Ace the Google Interview: Ultimate Guide

#84

Post by chollida1 » Wed, Apr 24, 2019, 2:09 AM UTC

peter_l_downs wrote: post #53

bitL wrote: post #44

Earlier quoted context omitted.

Elite schools do that in undergrad; e.g. as an initial scored lab exercise, write this recursive fractal shape using Logo, parallel Delaunay triangulation with prefix sums , dynamic programming solving oligopoly problem or single-value Paxos pseudocode on a piece of paper in 10 minutes (I am being serious). If you can cope with it, it immediately shows up in the interview and you are considered a member of the club,…

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

Re: How to Ace the Google Interview: Ultimate Guide

#85

Post by sanderjd » Wed, Apr 24, 2019, 2:09 AM UTC

fjp wrote: post #24

CodeMage wrote: post #22

Earlier quoted context omitted.

> But I've had candidates that try to make up language features, and that doesn't fly with me. This piqued my curiosity. Can you give an example?

I once passed a whiteboard interview just calling random made-up operations on generic java arrays, like Array.flatten(). I was relatively new to programming and had been practicing in Java but didn't know how to execute a lot of map/filter/reduce operations off the top of my head like that. I did, however, know that my interviewer was a Python programmer that probably didn't know much about Java language features.

If you can explain what it is supposed to do, I don't care a whit if you make up a method that probably exists in a standard library somewhere (Guava / Apache Commons, or wherever). If it's slightly more obscure, you might have to write pseudocode to show you know how it might be implemented.

Re: How to Ace the Google Interview: Ultimate Guide

#86

Post by quarkral » Wed, Apr 24, 2019, 2:10 AM UTC

Strange, I have yet to meet a single Google interviewer who was looking for perfect syntax during the interview. Last year I forgot the syntax for a data structure, told my interviewer "something like this," and he just said "that's fine." Got the internship later on. I even had one interviewer who was ok with me writing out matrix algebra mathematically instead of using np.matmul and all that.

Re: How to Ace the Google Interview: Ultimate Guide

#87

Post by Zelizz » Wed, Apr 24, 2019, 2:19 AM UTC

seanmcdirmid wrote: post #46

fjp wrote: post #24

Earlier quoted context omitted.

I once passed a whiteboard interview just calling random made-up operations on generic java arrays, like Array.flatten(). I was relatively new to programming and had been practicing in Java but didn't know how to execute a lot of map/filter/reduce operations off the top of my head like that. I did, however, know that my interviewer was a Python programmer that probably didn't know much about Java language features.

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 ¯\_(ツ)_/¯

Re: How to Ace the Google Interview: Ultimate Guide

#88

Post by LVB » Wed, Apr 24, 2019, 2:21 AM UTC

pdonis wrote: post #52

It would be nice if an article on how to ace a coding interview did not have incorrect code in it. AFAICT the set-based algorithm for finding duplicates is wrong; the resulting set will contain items in the list that are not duplicated.

It doesn't work. Not just a coding issue either, as the code matches their explanation for this "improved" method.

Re: How to Ace the Google Interview: Ultimate Guide

#89

Post by sanderjd » Wed, Apr 24, 2019, 2:22 AM UTC

emmelaich wrote: post #33

CodeMage wrote: post #22

Earlier quoted context omitted.

> But I've had candidates that try to make up language features, and that doesn't fly with me. This piqued my curiosity. Can you give an example?

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 distinctly remember one of my in-person interviewers saying "well, in Java it's boolean, not bool, but sure...". More semantically, I may very well have messed up mutability of collections and primitive conversions and boxing and such.

Enough of my interviewers saw through all of this that I got the job. Now people on my team come to me and say, "hey you're a java guy right?" and ask me questions about this stuff. I wasn't a java expert when I interviewed, but now I am, because that's what my job required, so I learned it. That's what my interviewers were looking for, to the company's benefit.

Re: How to Ace the Google Interview: Ultimate Guide

#90

Post by ummonk » Wed, Apr 24, 2019, 2:24 AM UTC

matmann2001 wrote: post #21

This is getting ridiculous. These guides to interviewing at specific companies are starting to sound like the video game cheat code books of old. If the process is so nuanced that there's an entire industry around these types of guides (and Google even highly recommends you buy them!), then the process is fundamentally flawed. But we already knew that, and as long as others are still playing the game, we are forced t…

Or it means the process is well defined enough that you can create a level field by telling everyone how it works through guides like this instead of giving connected people a leg up due to inside knowledge of a poorly defined process.