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

161–170 of 250 posts

Re: Google Tech Dev Guide

#161

Post by bicubic »

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…

tl;dr: sometimes algorithmic puzzle thinking comes in useful.

I don't think anyone is debating that. You don't need to write an essay worth of anecdotes. And your anecdotes don't really address the complaint: these algorithmic puzzles just don't present themselves at the majority of everyday work for the majority of everyday people. Not even at Google.

Preparing for a Google interview is like preparing for an exam on an arbitrary subject that's only loosely related to your field of work.

What this kind of interview actually tests for, is whether the candidate has the time and desire to do all the prep in the first place. It's heavily skewed towards younger individuals, especially recent graduates.

Re: Google Tech Dev Guide

#162

Post by pathseeker »

SamReidHughes wrote: post #64
m0zg wrote: post #51

Earlier quoted context omitted.

The problem here is the only non-bruteforce solution worth pursuing here involves DP with less-than-straightforward memoization rules, which the engineer is unlikely to actually use before or after the interview. So she has to waste a month studying _specifically for the interview_ and "refreshing" the skills she won't actually need on the job. It's like you're hiring a welder, but you want them to be good at jugglin…

Actually looking at their "brute force" solution, what I was referring to as brute force was their "greedy" algorithm, and the first optimization I came up with was the most optimal solution. I'd call that a very natural strategy to take -- try doing the words simultaneously instead of separately, and you see it. I don't even see that as DP. Not everybody will be as quick as me, but there are plenty of people that do…

>But if they have to spend a month refreshing any time they want a job, it means their brain drops skills they learn that are closely related to the job they do. That means their experience is worthless -- they aren't retaining it, long-term.

DP isn't used the vast majority of the time. That's not retaining "experience".

Re: Google Tech Dev Guide

#163

Post by mFixman »

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

This is the CS equivalent of "maths are useless since I'll never use them in real life". Even if you are a software engineer who works exclusively on Javascript you need to understand the basic of how things work.

Re: Google Tech Dev Guide

#164

Post by violinist »

scaryclam wrote: post #150
gundmc wrote: post #134

Earlier quoted context omitted.

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…

Have you recommended hires for people who didn't find any solution at all? If not, why not?

(Also a Googler, not GP commenter. Speaking just for me.)

Yes, I have. Generally this was a case where the candidate had a good grasp on an approach to the question by the end of the interview but wasn’t able to write it due to time constraints.

I see interviews as a dialogue between me and the candidate where I give them hints in the right direction when required. Very few candidates require 0 hints.

Re: Google Tech Dev Guide

#165

Post by pathseeker »

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…

>There's nothing wrong with straightforwardly engineered apps, screens, forms, databases. Most of the world subsists on this.

Most of Google subsists on this. Interviewing everyone for skills that only come up when you are pushing the boundaries of CS is pointless. 99% of engineers at Google fling protos and do menial translations on them.

Have a separate "CS" group if you want and apply the CS questions to them. For the rest, interview instead on their ability to write maintainable, testable, scalable software. Google would be worlds better off for it. It's shocking how incompetent the org is as a whole at delivering and maintaining quality software.

Re: Google Tech Dev Guide

#166

Post by thecatspaw »

mFixman wrote: post #163
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'…

This is the CS equivalent of "maths are useless since I'll never use them in real life". Even if you are a software engineer who works exclusively on Javascript you need to understand the basic of how things work.

Math isnt useless. But you wouldnt ask an english teacher math questions at an interview, would you?

Re: Google Tech Dev Guide

#167

Post by yorwba »

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

Hundreds of replies in, nobody seems to have noticed that the question is tagged "machine learning".

Re: Google Tech Dev Guide

#168

Post by superlopuh »

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

My first job out of school was writing a spell checker/auto completion system. If you want to weigh predictions by the expected number of keystrokes saved. This is a bit like the opposite problem, find the longest word D that is a supersequence of S (You want to find them all, to weigh by probability), but would essentially be solved with the same data structures. I assume that this sort of problem is not particularly rare, and is unlike sorting in that it's not quite as universal, and the one line function doesn't live in the standard library, or any package that I could find. The fact that the algorithms were still fresh in my mind helped immensely.

Re: Google Tech Dev Guide

#169

Post by C1sc0cat »

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.

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

Re: Google Tech Dev Guide

#170

Post by cromwellian »

pathseeker wrote: post #165
cromwellian wrote: post #92

Earlier quoted context omitted.

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

>There's nothing wrong with straightforwardly engineered apps, screens, forms, databases. Most of the world subsists on this. Most of Google subsists on this. Interviewing everyone for skills that only come up when you are pushing the boundaries of CS is pointless. 99% of engineers at Google fling protos and do menial translations on them. Have a separate "CS" group if you want and apply the CS questions to them. For…

I don’t think product excellence is a function of the interview process, it’s mainly a function of what you are promoted for, and rightly or wrongly, launching new things tends to give you a better career trajectory than fixing or maintaining old stuff.
Post reply on HN