Live data from Hacker News

How to Ace the Google Interview: Ultimate Guide

byte-by-byte.com

161–170 of 239 posts

Re: How to Ace the Google Interview: Ultimate Guide

#161
post #133

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'd be a lot more comfortable with "We have a machine set up for you, but you can also bring your laptop,"

That's exactly how I do it. My goal is to assess the candidate's skills with realistic expectations, a whiteboard is a tool he or she can use, not the goal of my interview. If he can write code on a whiteboard and he doesn't know how to compile a program, it rings a bell.

Re: How to Ace the Google Interview: Ultimate Guide

#162

Earlier quoted context omitted.

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.

Indeed, seeing a candidate bring a $250 ebay thinkpad running linux would impress me and be great ice breaker

Re: How to Ace the Google Interview: Ultimate Guide

#163

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…

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

Who cares? If they write code that's well engineered and works in your product and they rely on auto-complete or whatever, isn't that what your business needs and why they really pay you? Furthermore, said code will be written from a comfy chair while they listen to their favorite music, with access to Google, SO, etc. And they will have enough time to leisurely think about what they're doing, test, refactor, etc.

In contrast, during such an interview, they are hand-writing code under duress for a problem they've had no time to think about while being judged by one or more people staring at them. If you're company is one of those famous ones where they get so many applicants they need to weed out many potentially good people, and also don't care whether they let in crappy people who game this system, then fine, whatever works.

Re: How to Ace the Google Interview: Ultimate Guide

#164

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.

In the current interview structure, I don't think that's inherently a bad policy. It forces interviewers to develop new unique questions and hopefully, while doing so, consider the cognative time and complexity the solution took them before deciding to hand it to an interviewee.

This also discourages overly complex or overly familiarized questions. If the question is too complex, chances are it will end up posted online soon after, penalizing the interviewer in time cost. If a new question is recycled frequently, it will also likely end up online at some point and penalize interviewers from using questions they're overly familiar/biased in assessment to based on their own rote learning.

Re: How to Ace the Google Interview: Ultimate Guide

#165
post #151
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…

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.

Better designs require fewer lines of code

I think that's extremely dependent on context.

I write mostly SQL and bash and would argue that both languages are not conductive to try to reduce size at the cost of future maintenance.

Re: How to Ace the Google Interview: Ultimate Guide

#166
post #97

Earlier quoted context omitted.

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

There are however cases where

    Node neighbor = data[x+1][y];
does not require an index boundary check when you know that 'x + 1 < length(data)' for any 'x'. This could be due to the iteration of 'data' excluding the last element or any other condition that's always hold.

Re: How to Ace the Google Interview: Ultimate Guide

#167

Earlier quoted context omitted.

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

> (They'll write crap like "()f" or "f()a" when they want to call a function, stuff like that.) Who cares? If they write code that's well engineered and works in your product and they rely on auto-complete or whatever, isn't that what your business needs and why they really pay you? Furthermore, said code will be written from a comfy chair while they listen to their favorite music, with access to Google, SO, etc. And…

I think the function syntax thing is one of those things that's so basic that someone who gets that wrong probably doesn't code very much.

Re: How to Ace the Google Interview: Ultimate Guide

#168
post #157

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…

Agreed, the fault is with the employer, but the people who are willing to indulge this game by obsessively learning to play it don't help.

Re: How to Ace the Google Interview: Ultimate Guide

#169
post #97

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…

I'm like you in that I used to code "against the IDE and test cases" by basically rapidly iterating and kind of refining as I go along. Always fast to compile and see what happens.

Learning to write code on paper for exams and on white boards for interviews actually improved my skills a lot. Maybe not everyone coded like I did, "against constraints", but having to slow down and take into account the constraints mentally led to making better code.

Re: How to Ace the Google Interview: Ultimate Guide

#170

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

Can confirm. I interviewed last September and was given the choice between laptop and whiteboard. Picked laptop. It seemed this element was new to most interviewers at that time.
Post reply on HN