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

141–150 of 239 posts

Re: How to Ace the Google Interview: Ultimate Guide

#141

Post by vkou »

dominotw wrote: post #73
seanmcdirmid wrote: post #41

Earlier quoted context omitted.

I’ve heard that Google allows you to type code into a computer now during an interview. A welcome improvement in the state of the art. Still no access to a compiler or debugger, but baby steps.

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 algorithm works, whether the candidate can identify limitations of, and bugs in their solution (Everyone has bugs. Everyone. There's nothing wrong with that.) and what their testing strategy is.

Re: How to Ace the Google Interview: Ultimate Guide

#142

Post by skookumchuck »

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.

Re: How to Ace the Google Interview: Ultimate Guide

#143

Post by jogjayr »

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 agree with that. I've had candidates explain certain points of syntax as they worked, or demonstrate their knowledge in other ways, or write their code particularly well or cleanly, and I make sure to mention that positively in my notes. But less-than-flawless syntax by itself isn't a negative for me.

I agree with the main things you look for - I too try to focus on those more than syntax.

Re: How to Ace the Google Interview: Ultimate Guide

#144

Post by skookumchuck »

ilikehurdles wrote: post #140
skookumchuck wrote: post #138

Earlier quoted context omitted.

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

When I was looking for work, my laptops setup was embarrassing. MacBook Pro with both a broken keyboard and misbehaving trackpad. I had to bring with me an external mechanical keyboard and trackpad. It worked out in the end but that could leave a bad impression with interviewers.

It wouldn't bother me any. I'd just think you were thrifty, and were capable of working around problems to get things done.

Re: How to Ace the Google Interview: Ultimate Guide

#145

Post by jogjayr »

bitL wrote: post #60

You can bypass the whole charade by knowing 2-3 people within Google that can provide "assurance" you are good enough. Whiteboard testing is for grunts/unknowns without network. Another way is to be a significant contributor to some popular open source project.

AFAIK internal referrals at best skip the phone screen interview.

As for popular open-source projects, I don't know about Guido van Rossum or Rob Pike, but Max Howell definitely whiteboarded in his interview: https://twitter.com/mxcl/status/608682016205344768

Re: How to Ace the Google Interview: Ultimate Guide

#146

Post by otabdeveloper2 »

ChrisCinelli wrote: post #37
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…

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 go away, but put them at a whiteboard and they don't know where the parentheses go in a function call.

(They'll write crap like "()f" or "f()a" when they want to call a function, stuff like that.)

Re: How to Ace the Google Interview: Ultimate Guide

#147

Post by piyush_soni »

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?

Same happens at Amazon. They want syntactically correct program that will actually compile and run on a compiler, but to verify that they click a photo of what you've written on the whiteboard to actually try that on the computer themselves. :|

Re: How to Ace the Google Interview: Ultimate Guide

#148

Post by Frost1x »

topicseed wrote: post #11

It's also a good marketing milking cow to create paid courses and trainings for Google interviews — the dream of so many novice devs and other "Intensive Coding Bootcamp" participants. Keyword research and trends... https://trends.google.com/trends/explore?date=all&geo=US&q=G...

I'm semi-convinced this is yet another reason for perpetuating this type of poor interview practice (not just at Google).

When you search modern interview topic and comments/opinions on the current process, you'll find a few SEs (typically working at places like Google at some point) on that on the side sell training bootcamps, etc. These people will swear every direction that it's a reasonable process in comments around the web referring to their side business. Creating problems they provide solutions to: gatekeeping 101.

Re: How to Ace the Google Interview: Ultimate Guide

#149

Post by sanderjd »

blackflame7000 wrote: post #137
sanderjd wrote: post #81

Earlier quoted context omitted.

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

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.
Post reply on HN