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

101–110 of 239 posts

Re: How to Ace the Google Interview: Ultimate Guide

#101

Post by shaftway »

CodeMage wrote: post #22
shaftway wrote: post #20

Earlier quoted context omitted.

I'm in the interviewer pool @ Google. > practice writing syntactically correct code on a whiteboard This probably differs from interviewer to interviewer as to how strictly it's adhered to, but it's not really a hard and fast rule. I'm sure there are some interviewers that will ding you on a forgotten semicolon, but I suspect that most would not. Personally I look for code that isn't so far from syntactically correct…

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

This one candidate had been allowed to skip the phone screen, and phone screens would likely have filtered them out. Candidate used Java and claimed to be deeply familiar with it. Obviously this isn't exact, but the result looked something like this:

    public isTheFooBarred(class Node { int[][] positions, int size } node, int x, int y, Set visited = new HashSet(node.size)) {
      // ...
    }
The first parameter to the method had an inlined class definition, and the last parameter was optional. We discussed this and the candidate claimed that this was legal vanilla Java. In the case of the last parameter, the candidate claimed that the compiler generated every possible combination of methods including and excluding each of the optional parameters (so, 2^n methods).

I really tried to give the candidate the benefit of the doubt, and asked if there was some sort of annotation processor or code pre-processor that they were using, but they were adamant that it was plain old vanilla Java. I'm pretty sure that they were using some in-house built thing, but their solution had significant problems, so it wasn't the only reason I was against the hire.

Re: How to Ace the Google Interview: Ultimate Guide

#102

Post by tyingq »

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

Sounds like a great opportunity to whiteboard an exploit instead.

Re: How to Ace the Google Interview: Ultimate Guide

#105

Post by shaftway »

ummonk wrote: post #97
shaftway wrote: post #20

Earlier quoted context omitted.

I'm in the interviewer pool @ Google. > practice writing syntactically correct code on a whiteboard This probably differs from interviewer to interviewer as to how strictly it's adhered to, but it's not really a hard and fast rule. I'm sure there are some interviewers that will ding you on a forgotten semicolon, but I suspect that most would not. Personally I look for code that isn't so far from syntactically correct…

>Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions and candidate wasn't able to realize that even with hints. I guess this depends on how you run the interview but one of the things that frustrates me about whiteboard interviews that focus on the coding rather than the design is that I have to step through test cases (especially edge cases…

My question is about walking around a data structure. Most candidates choose to represent it with arrays.

I agree with stepping through code being lame. If a candidate has tried to do some sort of boundary condition check and mentions a test that'd catch it, then I'll give them a pass. If a candidate just blows past the code without any attempt whatsoever to check that they're in bounds on an array, then I'll ding them for that. You have no idea how often I see code like...

    Node neighbor = data[x+1][y];
... without any check at all to see if x+1 is in bounds for data.

The infinite loop in my question is fairly obvious (because it involves walking around a data structure iteratively). Candidates either see it right away and handle it as they solve, notice it halfway through and crowbar it awkwardly in, or don't notice it until asked to walk through a specific test case, or don't even notice it while walking through the test case.

Ultimately, if the code looks correct to me, or even close (I mess up occasionally) then I'll just ask what cases they would test.

Re: How to Ace the Google Interview: Ultimate Guide

#106

Post by jogjayr »

quarkral wrote: post #86

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.

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.

Re: How to Ace the Google Interview: Ultimate Guide

#108

Post by shaftway »

Apocryphon wrote: post #66

Question for hiring managers and employers: In Silicon Valley, tech interviewing has become an arms race between applicants cramming to pass tech screens and interviews, and employers coming up with new routines. Sites like Glassdoor and CareerCup are loaded with interview questions that have appeared in those routines, giving savvy interviewees the opportunity to see the questions on the exam and prepare accordingly…

As an interviewer I don't really care. A good candidate doesn't need them, and a poor candidate isn't helped by them. The only thing that's irritating to me is that they actually burn interview questions. Once a question is seen on an external job board it gets banned as an interview question.

Re: How to Ace the Google Interview: Ultimate Guide

#109

Post by lallysingh »

emmelaich wrote: post #32
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…

On the contrary; the fact that Google recommends them indicates the process is not flawed. That is too say, their interviewing process explores things at sufficient depth and breadth to make knowing "the" solution not a deciding factor.

Well, the (in house) recruiters recommend them. The engineering staff that does the interviewing generally don't get involved in this recommendations.

Re: How to Ace the Google Interview: Ultimate Guide

#110

Post by vips7L »

shaftway wrote: post #20
CobrastanJorji wrote: post #14

Earlier quoted context omitted.

A perfect job interview could be defined as an interview for which the best study technique is to become a better choice for the role. Studying skills that would not directly contribute to job performance would not change the result of a perfect job interview in any way. In that sense, it's probably a good indicator for Google that the interview advice includes "practice writing code", "make it a habit to validate in…

I'm in the interviewer pool @ Google. > practice writing syntactically correct code on a whiteboard This probably differs from interviewer to interviewer as to how strictly it's adhered to, but it's not really a hard and fast rule. I'm sure there are some interviewers that will ding you on a forgotten semicolon, but I suspect that most would not. Personally I look for code that isn't so far from syntactically correct…

> Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions

Why does this even matter? They're writing the code on a whiteboard, without being able to compile or debug, in 20 minutes. Does Google really expect code to be correct and production ready in 20 minutes?

Post reply on HN