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

151–160 of 250 posts

Re: Google Tech Dev Guide

#151

Post by chaosite »

raverbashing wrote: post #143
joshuamorton wrote: post #133

Earlier quoted context omitted.

This isn't really true. I've asked a few different interview questions in my time, and the number of candidates who have gotten the "optimal" solution currently sits at 0, to any of the questions. Despite this, I've suggested that we hire some of those "wrong" answer candidates. And given the interview feedback I've seen, I'm not the only one like this.

Might be something more recent then, though I agree that there are questions which are more flexible than others

This was the way I was taught to conduct interviews at Google when I was there ~3 years ago, so it can't be that recent.

That was the ideal though, I'm not that surprised that in practice it doesn't actually work.

Re: Google Tech Dev Guide

#152

Post by paganel »

cromwellian wrote: post #140
paganel wrote: post #136

Earlier quoted context omitted.

> The gist of that article is by using edit-distance/levenstein distance to 'cluster' JS code fragments, you can improve the efficiency of GZIP by bringing more code into its 32K window OR optimize the huffman codes it uses. However, edit-distance doesn't know anything about the LZ algorithm's mechanism. That sounds really cool, and even though I couldn't understand the technical details I understood the gist of it.…

Everything has gotten bulkier in Gmail, not just the JS, but th CSS, the DOM, the fonts, assets overall because Gmail is an app that’s over a decade old and features have mostly been added, not removed. This is the fate of all legacy software, OSes, native apps, they all eventually burst under their own weight, and are rewritten clean. Inbox was that dream :) In particular, Gmail has been engineered to mostly be serv…

Happy to hear that and happy to hear that in the end there were people at Google that managed to impose a KISS-like view on one of their most used products.

> Web apps got native app envy after installables and app stores took off. I think we’ve woke up from that now and you’ll gradually see it improve.

Yeah, the hype was big with SPAs, I also hope that Google diverging from that path will set an example for the rest of the industry and things will become more "normal" again.

Re: Google Tech Dev Guide

#153

Post by pathseeker »

saulrh wrote: post #31
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'…

Funny, I use this kind of thing all the time when I'm programming. I wrote a comment citing the pigeonhole principal to justify a test case not thirty minutes ago. And I'm not even doing anything wizardly or revolutionary, just improving some concurrency code in a random worker binary. As for your comment about "diversity of thought": These problems seem sterile when they're presented in the most general possible for…

>Finally, would you have reacted anything like this if the page had been spat out by your favorite Ruby super hacker wizard greybeard man? If it'd been an artisan webpage hand-crafted in the hipsterest coffee shop in oregon? If it's been on microsoft's recruiting page?

You work for Google and you want to defend the org, we get it. Get over yourself. This really detracts from the rest of your post so I would consider removing it if you can still edit.

The entire point was that testing for these low-level fundamentals really has nothing to do with software engineering. It would be like hiring civil engineers based on being able to do some equations from memory that they would normally reference a book (or the Internet) for in real life. Not only is it not measuring their ability to engineer so it lets terrible engineers in, but it also rejects amazing engineers who don't have optimal solutions to things memorized that you would almost never be using in day-to-day engineering.

Re: Google Tech Dev Guide

#154

Post by ___alt »

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

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.

Re: Google Tech Dev Guide

#155

Post by pathseeker »

gundmc wrote: post #134
keyanp wrote: post #111

Earlier quoted context omitted.

Good point! I ran into this case studying for interviews a while ago. The "maximum subarray problem"[1] is a common interview question, you are generally expected to be able to come up with the O(n) solution. Well has a great passage about the origins of the problem and how multiple excellent algorithmists could not improve on a O(n^2) run time[2]: > Grenander observed that the cubic time of Algorithm 1 was prohibiti…

It's much more important to explain your thought process, work through the problem, and come up with any solution than it is to come up with the optimal solution in these interviews. I think that's what people who rail on standard coding interviews don't understand. It's not about memorizing the answer to algorithm puzzles. In fact - if a candidate seems to know a problem by heart, that interviewer's feedback will of…

I've had coworkers at Google tell me that they've informed candidates verbatim "don't bother giving me the O(n^2) solution" right when they start to go down that path. Hard to get much more of their thought process when you shut them down immediately.

Re: Google Tech Dev Guide

#156

Post by bicubic »

___alt wrote: post #154
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'…

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. Someone with the foundations you want could just as easily have fucked up something else.

Re: Google Tech Dev Guide

#157

Post by pathseeker »

seanmcdirmid wrote: post #76
nradov wrote: post #75

Earlier quoted context omitted.

This seems related to Goodhart's law: "When a measure becomes a target, it ceases to be a good measure." If the hiring process for some tech companies has become so dysfunctional that they actually consider brain teaser coding questions to be meaningful then we should expect that competitors with more results oriented hiring processes will eventually beat them in the market.

Perhaps the tenacity and work ethic needed to study a couple of months for an interview selects for people who would do the job well anyways? Maybe that is what it means to be Googly as a culture fit? Anyways, practicing solving clever small programming problems at least isn’t boring (though I’m beginning to burn out on it), it reminds me of prepping for a high school or ACM programming contest. As long as it elimina…

>work ethic

Translation: have enough free time so spend months preparing for an interview after work hours or have no actual work ethic and do it at your current job.

Basically, fuck people with families, commitments, or already mentally demanding jobs.

Re: Google Tech Dev Guide

#158

Post by adrianN »

jorblumesea wrote: post #72
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'…

These problems appear in every comp sci text book. For example: https://ebookclass.com/product/algorithms-4th-edition-4th-ed... Chapter 5 has multiple pages devoted to string algos and problem solving with strings. https://algs4.cs.princeton.edu/50strings/ I don't think it's fair to blame Google for something that is fundamental for computer science students.

And yet "I open any textbook and look for the matching algorithm" is not an accepted answer to this question. You're supposed to either invent the algorithm from scratch or memorize interview problems and be lucky.

Re: Google Tech Dev Guide

#159

Post by mkohlmyr »

TeMPOraL wrote: post #149
seanmcdirmid wrote: post #76

Earlier quoted context omitted.

Perhaps the tenacity and work ethic needed to study a couple of months for an interview selects for people who would do the job well anyways? Maybe that is what it means to be Googly as a culture fit? Anyways, practicing solving clever small programming problems at least isn’t boring (though I’m beginning to burn out on it), it reminds me of prepping for a high school or ACM programming contest. As long as it elimina…

> work ethic I sometimes wish people explain what they mean by that, because I'm confused by the phrase. I assume it's some Americanism that has a broad range of meanings. Cramming trivia for interviews doesn't sound like the "work ethics" I see when I google the term, but then again, I recently had a German student explain to me that they understand hard (but dumb) work as what this phrase means.

I agree it can be hard to put your finger exactly on what it is.

My best sense of it is that it is something approximating your ability to follow through on some task that a) was never, or has seized to be interesting or otherwise stimulating or b) is sufficiently difficult that many people would allow themselves to quit. Often related to the idea that there is some form of delayed gratification to be had.

Re: Google Tech Dev Guide

#160

Post by pathseeker »

sirpunch wrote: post #118
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'…

In case you think these questions are not actually asked in Google interviews, I should add that I was asked this very question in Google SDE interview just 6 days ago. I failed to answer this and was consequently rejected. Also, the interviewer asked me nothing other than this question. Nothing about the breadth of work that I have done in different sectors, my interest/passion, personal projects etc. I was so upset…

>I was so upset after the interview was over and I cried a lot after reaching home. :(

Yep, this is a side effect of the image Google portrays combined with the idiotic interview process. They cultivate an image of being prestigious both internally (the NIH syndrome is extreme) and externally. They claim that all external experience is irrelevant once you start at the great big G (which is bullshit, but that's beyond the point) so you will just be interviewed on "fundamentals".

So you go in and do you interview, and all of the interviewers ignore your 20 years of developing guidance systems for rockets at NASA and have you write algorithms on a whiteboard to find palindromes or overlapping rectangles while the interviewer emphasizes that the code will be photographed (so don't fuck up the syntax!!).

At this point, an org you think is prestigious has convinced you that your only relevance in the big leagues is these whiteboard questions, which you fumble on because you haven't been grinding on leetcode for the last 2 months. REJECTED. A snap judgement based on your public performance skills has deemed you incapable of handling the very fundamentals of engineering. So what is it you've been doing your whole life?

It's no wonder people cry.

Post reply on HN