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

151–160 of 239 posts

Re: How to Ace the Google Interview: Ultimate Guide

#151

Post by DenisM »

jefftk wrote: post #117
jogjayr wrote: post #106

Earlier quoted context omitted.

As an interviewer, I can confirm that I don't care about syntax or whether the program compiles if I'm convinced their solution and approach would work. I'm also OK with candidates using placeholder helper functions or shorthand for trivial things (e.g. null/undefined check in JS) if they explain to me verbally what that part is supposed to do.

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…

Better designs require fewer lines of code [#]. Maybe the person spends more time thinking than writing. Also think about a typical enterprise Java program - writing lots of boilerplate code is bound to create fantastic muscle/syntax memory and no useful skill beyond that.

[#] If this doesn't seem obvious consider the inverse - worse designs will inevitably require more lines of code to get the same result.

Re: How to Ace the Google Interview: Ultimate Guide

#152

Post by int_19h »

otabdeveloper2 wrote: post #146
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…

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

Re: How to Ace the Google Interview: Ultimate Guide

#153

Post by drivebycomment »

skookumchuck wrote: post #142

I've never seen an interview process that HN (and Reddit and Slashdot and ...) didn't trash as "deeply flawed", "biased", "unfair", "unreasonable", etc. At some point, though, a company has to have some sort of process, and by and large what they use works for them.

It's always so much easier to criticize (as nothing is perfect) than actually come up with a better solution in real life. So anything where there's no perfect solution, people will endlessly criticize online, even though they themselves have no better solution, and what they criticize is not terrible by any means.

Re: How to Ace the Google Interview: Ultimate Guide

#154

Post by int_19h »

keanebean86 wrote: post #116
tyingq wrote: post #102

Earlier quoted context omitted.

Sounds like a great opportunity to whiteboard an exploit instead.

I'm a moron and did something stupid not too long ago that would be perfect for this. I'm too lazy to find my actual code but here's the gist: C# but might working in Java/etc too * Create an Image of some size loop hight of image loop width of image Bitmap b = cast Image to bitmap since Image doesn't have the pixel method get pixel value or whatever looks legit end end This creates a new bitmap for EVERY pixel in th…

I'm curious why this worked like that, since GC should consider all those bitmaps orphaned at the end of every loop iteration (possibly as soon as you get the pixel even, since that reference is no longer used). The GC might not run for a while, but it should certainly run long before the entire system starts swapping...

The only thing I can think of is that the actual bitmap data is not tracked as a managed array by a Bitmap instance, but rather is a pointer or handle from some underlying native library. GC might not kick in then, because it doesn't realize how much memory all those bitmap objects are actually hogging. Now, on .NET, when libraries do that kind of thing, they're supposed to use GC.Add/RemoveMemoryPressure to let it know. But perhaps the library that you were using didn't?

Re: How to Ace the Google Interview: Ultimate Guide

#155

Post by Frost1x »

HALtheWise wrote: post #47
ssambros wrote: post #3

> For the phone interview, it will be on a Google document, and for the onsite interview, it will be writing code on a whiteboard. That part is not completely correct. At onsite can choose to write code in a Chromebook which will have a lightweight editor with syntax highlighting.

I interviewed at Google in January, and they offered to let me use a computer if I had accessibility concerns with a whiteboard or really really wanted to, but discouraged it because they found it often made candidates too focused on the syntax of their code and less likely to have a meaningful high-level discussion with the interviewer.

That's hilariously ironic. If they wanted meaningful high level discussions without syntax focus, their interview structure would be different.

The most obvious change was to accept psuedo-code (like in the olden times) to reduce cognitive load dealing with: syntax, dynamic problem solving, and dealing with someone asking you random questions shifting your train of thought or changing the problem description on the spot.

This now common poorly structured interview process does a lot to discourage high level conversation and low focus on syntax. It tends to get hung up on language specific syntax, data structure recall, and less on designing and analyzing solutions.

BS atop BS... its BS all the way down

Re: How to Ace the Google Interview: Ultimate Guide

#156

Post by int_19h »

sanderjd wrote: post #149
blackflame7000 wrote: post #137

Earlier quoted context omitted.

Most algorithms focus on: 1) binary trees for which theres usually a STL 2) some sort of odd string / array manipulation that never comes up in real life 3) some sort of linked list manipulation where again there is an STL for that and/or wouldn’t come up in real life 4) some optimized algorithm that literally took the first person years to discover prims vs kruskals MST for example, but now is expected to “figure ou…

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 things are true, or know how to implement it from scratch.

Re: How to Ace the Google Interview: Ultimate Guide

#157

Post by akdas »

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…

> 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 like the fault is on the employer that makes you play the game, not on "people want to be employed without becoming employable".

Re: How to Ace the Google Interview: Ultimate Guide

#158

Post by ikeyany »

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…

When the system's metric is proficiency at timed whiteboard programming questions, then people in that system will optimize for that metric (i.e. don't hate the player, hate the game).

Re: How to Ace the Google Interview: Ultimate Guide

#159

Post by mk89 »

otabdeveloper2 wrote: post #146
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…

> 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 frankly still don't understand what's the expectation of such whiteboard exercises. It's just one method, and companies have to understand that one day maybe it will be superseded, hopefully soon. This "we have always done it that way" is ridiculous. If you want to know how good a candidate is, you can easily do it with pertinent questions and maybe a couple of pair programming exercises to see how the person codes, how he/she structures the code in a comfortable situation, not under stress and in an unrealistic scenario -> coding on a whiteboard, as if we had no electricity. Whiteboards should be a tool, not the goal of an interview.

Re: How to Ace the Google Interview: Ultimate Guide

#160

Post by oarabbus_ »

jefftk wrote: post #117
jogjayr wrote: post #106

Earlier quoted context omitted.

As an interviewer, I can confirm that I don't care about syntax or whether the program compiles if I'm convinced their solution and approach would work. I'm also OK with candidates using placeholder helper functions or shorthand for trivial things (e.g. null/undefined check in JS) if they explain to me verbally what that part is supposed to do.

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 that comma before the from statement]

select from join table1.column = table2.column [This is embarrassing, I forgot the `on` keyword]

select from union from [Jesus... I forgot to type `select` after the union]

select , sum(column2) over (partition by column3 between unbounded preceding and current row) as cumulative_sum from [dang, SQL doesn't know which rows if I don't actually mention `ROWS BETWEEN`]

select , count(case when then 1 else null end) as count from order by count desc having count > 1 [ahh that's silly, you can't put your HAVING clause after the ORDER BY]

with cte_1 as (select ), cte_2 as (select ) cte_3 as (select ) select from cte_1 join cte_2 on left join cte_3 on where group by [Oh my goodness, I forgot a comma after closing cte_2]

Now, perhaps this says more about myself more than anything, but I really do write code comfortably all day, I'm glad my current employer, or any number of the clients I've worked for, haven't had this philosophy (even when watching over my shoulder waiting for results they need at the moment). I'd be mortified if anyone ever dug up some of the atrocious things I've requested of the database in the server logs.

Post reply on HN