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

181–190 of 250 posts

Re: Google Tech Dev Guide

#181

Post by SamReidHughes »

seanmcdirmid wrote: post #69
SamReidHughes wrote: post #49

Earlier quoted context omitted.

> If you didn't know how to solve it before the interview started, you aren't going to figure out anything other than a brute force solution in 45 minutes. I'd never heard this problem before and it took a few seconds to think of something better than brute force. Many colleagues I've worked with would too, and could probably improve on their first non-brute-force idea over the span of 25 minutes.

Have you studied cracking the coding interview before? If so, then I think you’ve probably seen similar problems. I find these problems very annoying and I code a lot of clever algorithms in my research. But none of it is have the strong scanning variety, I mean, except lexing in a compiler. And that’s how I would solve this problem in any case: I would just construct a scanner for D that would simply add to the stat…

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 than the brute force solution in 45 minutes. As m0zg intended it, that means better than 2^n*|D|, which is easily true. As I intended it, that people could do better than the "greedy" algorithm in 45 minutes, well, my image of a canonical developer is going to get the greedy algorithm right away, and then have 45 minutes to improve on it. And, I think they'd be able to accomplish that.

Re: Google Tech Dev Guide

#182

Post by raverbashing »

chaosite wrote: post #151
raverbashing wrote: post #143

Earlier quoted context omitted.

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.

Ah my experience with them was before that timeframe.

Re: Google Tech Dev Guide

#183

Post by SamReidHughes »

pathseeker wrote: post #162
SamReidHughes wrote: post #64

Earlier quoted context omitted.

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

Your experience from 10 years ago isn't used the vast majority of the time either.

Re: Google Tech Dev Guide

#184

Post by mlthoughts2018 »

cromwellian wrote: post #177
mlthoughts2018 wrote: post #172

Earlier quoted context omitted.

I have worked on similar kinds of problems where obscure details about sparse matrix algorithms were required. My team ended up writing a large in-house search engine and ranking framework that combined image and text search, all in Cython, using various types of bit packed indices for fast filtering and our own implementation of a series of sparse matrix algorithms sort of ripping out CSC and CSR internals for a han…

I don’t think it’s hazing, Google internal culture frowns on that kind of alpha male coder oneupsmanship. its mostly likely a residual of the fact that people fresh out of school actually don’t have a lot of projects or experience to talk about. If you ask me what the perfect interview is? I’d say, send me a bunch of github repos you participate in and let me review your code, bugs, and discussions with collaborators…

I can’t speak to Google in terms of the alpha mentality, but it’s still irresponsible of the world’s most effective computer science company to support it, advertise it with study guides, etc. I expect more self-awareness than that, and less lazy thinking that you need such time constrained trivia to keep an artificial prestige barrier (because it very sincerely is not about detecting engineer effectiveness). Take some responsibility for the cargo cult copycats you are fueling. The same could be said about stack ranking and various other policies as well.

Regarding interviews, everybody’s a comedian. You say GitHub but some of the best engineers I know do not participate in open source projects or are prevented from doing so by their employers. I say just treat software engineering like every other professional field on the planet and just conversationally interview people in a technically detailed way, focus on their past projects, work history, ability to get specific about their work. And of course that would not be as good for people just out of school or who forgot ancient work project details.

I would be fine with a holistic average approach, where each of these different ways is applied, but each counts for little weight individually. So you can be forgiven for a code test flub if you’re sharp on your work experience technical details.

But we exist in a state far away from that... where things are overwhelmingly based on isolated, time-sensitive trivia given 100% of the decision weight.

Re: Google Tech Dev Guide

#186

Post by Radim »

mlthoughts2018 wrote: post #172
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…

I have worked on similar kinds of problems where obscure details about sparse matrix algorithms were required. My team ended up writing a large in-house search engine and ranking framework that combined image and text search, all in Cython, using various types of bit packed indices for fast filtering and our own implementation of a series of sparse matrix algorithms sort of ripping out CSC and CSR internals for a han…

> … applying semantic indexing … to the sparse data in a way that was both fast and let us store hundreds of millions of documents in memory on fairly normal hardware.

Fascinating. Would you mind sharing more, some links / white papers?

We did something similar with ScaleText.ai (as a step-up from Gensim), I'd be curious to compare notes and perf numbers. Drop me an email at radim@rare-technologies.com if interested. Thanks!

Re: Google Tech Dev Guide

#187

Post by webmaven »

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 recently had a German student explain to me that they understand hard (but dumb) work as what this phrase means.

Not quite.

It's a phrase derived from "Protestant Work Ethic":

https://en.wikipedia.org/wiki/Protestant_work_ethic

Stripped of the religious connotations the phrase as commonly used (eg. "having a good work ethic") essentially means "feeling an obligation to consistently work hard for your employer".

Re: Google Tech Dev Guide

#188

Post by webmaven »

cmrdporcupine wrote: post #73
intern4tional wrote: post #70

Earlier quoted context omitted.

You should include the fact that you work at Google (cause you do, and your response is not completely honest without that disclaimer). The parent's concern was that this is Google focused, and your response doesn't seem to disprove it in any way.

FWIW I work at Google and despise these kind of interview questions and think they have 0 relevancy to my job -- until they do, and then I look them up and research them -- which BTW is not a skill that this interview style tests for. It's to the point where I've done interview training here twice and both times thrown up my hands and chosen not to interview, because I can't imagine giving an interview that I myself…

So what was the interview process like when you were hired (by Google)?

Re: Google Tech Dev Guide

#189

Post by webmaven »

m0zg wrote: post #86
SamReidHughes wrote: post #64

Earlier quoted context omitted.

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…

That's not the point. I just automatically assumed a subsequence problem will involve DP. I only know this because I studied for interviews in the past, not because I ever had to solve a subsequence problem at work, and I've done some _very_ advanced stuff. I posit that ability to solve such problems is completely irrelevant to one's job performance, at Google or anywhere else. Google's own test of this hypothesis (h…

> Google's own test of this hypothesis (hiring a control group of people irrespective of their interview scores) seems to bear it out.

Link?

Post reply on HN