Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Tech Dev Guide

techdevguide.withgoogle.com

Post reply on HN
Print view View original

201–210 of 250 posts

Re: Google Tech Dev Guide

#201

Post by seanmcdirmid »

TeMPOraL wrote: post #175
C1sc0cat wrote: post #169

Earlier quoted context omitted.

Yes I would take this as behaving ethically at work eg not sexually harassing co-workers, not stealing from the company by abusing the expenses system, hiring hookers on the company amex which happened at one company I worked for in the UK - and so on. To use an example from the military "officers eat last".

That would be my default interpretation too, but I've seen this phrase used plenty of times to mean "working hard", or "enduring work drudgery" (without any relation to ethical issues you mentioned), so I'm confused about the correct meaning of this term, and every time I see it, I have to infer from context what it is that a commenter is talking about.

The American meanings of work ethic relate to working hard or diligently. They don’t have anything to do with ethics. That would be under “work values” oddly enough.

Re: Google Tech Dev Guide

#202

Post by webmaven »

acroback wrote: post #91

I have been putting off a Google interview for a whole year now. I have real experience building Cluster Filesystems, Distributed Caches, TCP/IP Control plane software and low latency Ad platform for more than a decade. Sounds good on paper, but I can guarantee I cannot solve most of these puzzles without actually solving them beforehand. Why? Because I do not have cycles or time to solve these on my own. I have a sy…

> Family obligations do not help.

You've put your finger on it right there. These type of interview questions are biased toward candidates with plenty of free time and few obligations. This effectively has ageist, sexist, and classist[0] consequences.

[0] Racist as well, to the extent (which is considerable) that class is entagled with race.

Re: Google Tech Dev Guide

#203

Post by SamReidHughes »

seanmcdirmid wrote: post #200
SamReidHughes wrote: post #181

Earlier quoted context omitted.

I've never specifically studied for programming interview questions, or read that book. Of course, when somebody asks a fun problem, online or something, such as here, I'll try to figure it out. And I also find "string problems" to be the worst, I think they're a particularly bad genre of algorithms question. My claim was a very weak one, too. It was that somebody who never heard the problem before can get better tha…

I guess if you are used to solving these problems, they become easy. Anyways, I would have never seen the greedy solution to this problem, and am just lucky that it is basically a compiler one if you look at it hard enough. But if you aren’t in the mindset at all, these problems can be complete WTFs. For example, I just started interviewing recently and on one my first interviews someone gave me the house painting pr…

Is the house panting problem this one? https://www.programcreek.com/2014/05/leetcode-paint-house-ja...

I'd imagine you might want a bit of practice get refreshed. I know what you mean. But I'm guessing it's not a month of practice, and you're not thinking you have to memorize the problems beforehand.

For me, it's a similar background (interpreters, compilers, text editors) and for any algorithms interview, what always got me have been dynamic programming problems and remembering that hash tables exist.

Edit:

Funnily enough, one time on a phone screen, fresh out of college, I got asked directly what data structure I'd use for a text editor. The next words out of my mouth were, "a pair of finger trees," and it turned out that it didn't go well, I didn't get a follow-up interview.

Re: Google Tech Dev Guide

#204

Post by seanmcdirmid »

SamReidHughes wrote: post #203
seanmcdirmid wrote: post #200

Earlier quoted context omitted.

I guess if you are used to solving these problems, they become easy. Anyways, I would have never seen the greedy solution to this problem, and am just lucky that it is basically a compiler one if you look at it hard enough. But if you aren’t in the mindset at all, these problems can be complete WTFs. For example, I just started interviewing recently and on one my first interviews someone gave me the house painting pr…

Is the house panting problem this one? https://www.programcreek.com/2014/05/leetcode-paint-house-ja... I'd imagine you might want a bit of practice get refreshed. I know what you mean. But I'm guessing it's not a month of practice, and you're not thinking you have to memorize the problems beforehand. For me, it's a similar background (interpreters, compilers, text editors) and for any algorithms interview, what alway…

Maybe not a month, but many have done it for a month to get that dream job at google, the possibility is there and that could be the competition you are calibrated against.

Ya, I think we are sometimes actually better off with the generic brain twister questions because the more specialized questions are harder evaluate. Like, my idea of writing a code editor might be completely different from yours because I’ve dealt with different requirements. And if the interviewer is junior enough (or not versed in the specialty), they might not be ready to have a serious discussion about trade offs and design spaces.

Re: Google Tech Dev Guide

#205

Post by jsolson »

cmrdporcupine wrote: post #180
jsolson wrote: post #98

Earlier quoted context omitted.

So don't give that sort of interview; give one you wouldn't walk out of where, if it goes well, you'll be able to write a compelling argument about why the candidate should work at Google, and if it doesn't go well you'll be able to write about where the gaps are. Feel free to ping me on IM (username is in my profile) if you'd like to talk about how to do this in a way that helps hiring committee make informed decisi…

That simply wouldn't be permitted at Google. There's an accepted and normative form of interview and everything has to be documented meticulously.

This conversation would be better continued over corp hangouts or e-mail -- as I said, my username is in my profile.

Re: Google Tech Dev Guide

#206

Post by cwilkes »

bicubic wrote: post #156
___alt wrote: post #154

Earlier quoted context omitted.

To give a counterpoint, the lack of basic algorithmic knowledge of a developer in my team cost us a nasty production performance bug. I agree that whiteboard algorithms are not exactly our typical day work, but I'm fine with them being "foundations", things at back of your mind and you can conjure when needed.

If a single developer was able to cause a 'nasty' anything, your engineering process is completely wrong. It should have been caught at architectural discussions. It should have been caught during performance benchmarking. It should have been caught at code review. Didn't do any of those things? Don't blame the developer. No single individual encompasses all knowledge required to adequately address all of your tasks.…

I can’t upvote you enough.

The retort to this is usually along the lines of “we are moving fast and need people to write 100% correct code”. Perhaps that’s the case, but the solution is to put guidelines down (api review, unit testing, etc) instead of demanding people be infallible.

In this case a reasonable test case beyond “Did it compile?!?” Would have caught this.

Re: Google Tech Dev Guide

#207

Post by sidlls »

cromwellian wrote: post #92
lwansbrough wrote: post #2

"Given a string S and a set of words D, find the longest word in D that is a subsequence of S." Found under "Foundations of programming" -- this is exactly the type of problem I'd expect as question one under this section. When it's made by Googlers, that is. I make a lot of cool stuff day to day, and usually that requires a lot of code and knowledge about programming and topics that are rather advanced (currently I'…

(Disclaimer: I work at Google). This is going to sound like a humble-brag, but it isn't, I'm trying to give some life advice based on my experience: I have used "CS" algorithmic thinking on multiple projects, I've even used facets of abstract algebra and number theory from my Math degree to further my career and it lifted me out of poverty. Here's an example. A few years ago, I was researching ways to crunch down the…

Did your work on that project occur under a 45 minutes deadline on a whiteboard with someone watching you?

I see "It's the process not the result" all the time, but almost always from people who already work at Google and have for some time. From candidates and fresh hires I usually see the opposite.

Re: Google Tech Dev Guide

#208

Post by SamReidHughes »

seanmcdirmid wrote: post #204
SamReidHughes wrote: post #203

Earlier quoted context omitted.

Is the house panting problem this one? https://www.programcreek.com/2014/05/leetcode-paint-house-ja... I'd imagine you might want a bit of practice get refreshed. I know what you mean. But I'm guessing it's not a month of practice, and you're not thinking you have to memorize the problems beforehand. For me, it's a similar background (interpreters, compilers, text editors) and for any algorithms interview, what alway…

Maybe not a month, but many have done it for a month to get that dream job at google, the possibility is there and that could be the competition you are calibrated against. Ya, I think we are sometimes actually better off with the generic brain twister questions because the more specialized questions are harder evaluate. Like, my idea of writing a code editor might be completely different from yours because I’ve deal…

It does seem to me, reading online the past few years, like there has been an inflation in difficulty of a certain category of interview questions, as a result of people studying.

Usually, when interviewing people on an algorithms interview, I've asked an straightforward warm-up question, followed by a more interesting second question, that might be difficult for somebody that hasn't thought about anything interesting in 10 years. I don't think there was ever a situation where somebody got through the first just swimmingly, and then hit a wall on the second. The pain always starts on the warm-up question.

Re: Google Tech Dev Guide

#209

Post by TeMPOraL »

seanmcdirmid wrote: post #201
TeMPOraL wrote: post #175

Earlier quoted context omitted.

That would be my default interpretation too, but I've seen this phrase used plenty of times to mean "working hard", or "enduring work drudgery" (without any relation to ethical issues you mentioned), so I'm confused about the correct meaning of this term, and every time I see it, I have to infer from context what it is that a commenter is talking about.

The American meanings of work ethic relate to working hard or diligently. They don’t have anything to do with ethics. That would be under “work values” oddly enough.

Thanks for the clarification.

Re: Google Tech Dev Guide

#210

Post by [deleted] »

cwilkes wrote: post #206
bicubic wrote: post #156

Earlier quoted context omitted.

If a single developer was able to cause a 'nasty' anything, your engineering process is completely wrong. It should have been caught at architectural discussions. It should have been caught during performance benchmarking. It should have been caught at code review. Didn't do any of those things? Don't blame the developer. No single individual encompasses all knowledge required to adequately address all of your tasks.…

I can’t upvote you enough. The retort to this is usually along the lines of “we are moving fast and need people to write 100% correct code”. Perhaps that’s the case, but the solution is to put guidelines down (api review, unit testing, etc) instead of demanding people be infallible. In this case a reasonable test case beyond “Did it compile?!?” Would have caught this.

[deleted]
Post reply on HN