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

171–180 of 250 posts

Re: Google Tech Dev Guide

#171

Post by C1sc0cat »

mav3rick wrote: post #44
lwansbrough wrote: post #41

Earlier quoted context omitted.

My thought process: 1.) this is an intersection problem, 2.) what does a quick search have to say about efficiently solving an intersection problem in $language? That thought process does not require any algorithm knowledge. That knowledge is already out there in abundance, and there are enough people smarter than me focused on those problems that I am wasting everyone’s time by implementing a solution myself. (Btw t…

And what if you don't have a standard library ? You're working on a new device, on a new language ?. Frameworks breed programmers with less adaptability, foundations breed problem solvers that can adapt across problems.

But the best solution is just buy a library - at my first job (Hydrodynamics research) we didn't write our own FFT - we just brought one from NAG.

Re: Google Tech Dev Guide

#172

Post by mlthoughts2018 »

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…

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 handful of operations related to applying latent semantic indexing and some in house vision model neural networks 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.

I would say that tech interviews which assess this type of skill are deeply irrelevant and fail even at the very task they attempt to solve. Not to mention how arrogant it is to reduce emphasis that should be placed on straightforward communication about real work experiences as a more important measure than performance on any type of interview coding tasks.

What you say just falls flat. You don’t give any reason to think that this stuff needs to be an interview-ready skill to be tested in a time-sensitive way. It could just be picked up later when you have a project where you need it. Most engineers can quickly grok this stuff from a book or online tutorials or talking to someone else or even just writing the problem down and locking themselves in a room for a few hours to think.

Any assumption that it needs to be already in your brain cache all the time prior to an interview or every day at a job is just harmful.

At worst it’s a thin excuse for promoting a hazing style of oneupmanship as a barrier to jobs, killing diversity of thought and at best it’s misguided reward for a certain type of extreme premature optimization thinking (that carries a lot of antagonistic culture with it too).

Re: Google Tech Dev Guide

#173

Post by devocracy »

dbt00 wrote: post #81
lwansbrough wrote: post #41

Earlier quoted context omitted.

My thought process: 1.) this is an intersection problem, 2.) what does a quick search have to say about efficiently solving an intersection problem in $language? That thought process does not require any algorithm knowledge. That knowledge is already out there in abundance, and there are enough people smarter than me focused on those problems that I am wasting everyone’s time by implementing a solution myself. (Btw t…

The problem with "just use a damn library" is that software is full of abstractions and they leak. If all you know is libraries, and you don't invest in knowing how underlying technologies and algorithms work, you're going to get destroyed and look completely lost at some point. Sooner than you think.

I'm 15 years into my career and have yet to be destroyed for not taking the time to learn the details of every abstraction I utilize. That seems like a massive wasted effort when I could be busy adding value to the products I'm building vs becoming an expert at all things.

Re: Google Tech Dev Guide

#174

Post by devocracy »

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.

Most math is useless to 95% of the population. I can't remember the last time I used any of the teachings of my calculus heavy undergrad.

Re: Google Tech Dev Guide

#175

Post by TeMPOraL »

C1sc0cat wrote: post #169
TeMPOraL wrote: post #149

Earlier quoted context omitted.

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

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.

Re: Google Tech Dev Guide

#176

Post by black-tea »

lioeters wrote: post #148
sirpunch wrote: post #118

Earlier quoted context omitted.

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…

Wow, an interview should never be so traumatic.. Your experience shows how much the process is broken, one-sided and blind to a person's value and potential. I know it's no consolation, but recently I saw a site with many brilliant people sharing their rejection stories: https://rejected.us/ It just goes to show, if a company cannot see your real worth, don't let it get you down, keep going and prove them wrong.

Why should they consider somebody's "potential"? They wanted someone who could solve that problem. He wasn't that person. It's as simple as that.

Re: Google Tech Dev Guide

#177

Post by cromwellian »

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…

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’ll learn a lot more than any 1 hr FtF interview.

My overall point is there’s this kind of attitude “calculus? I never need it.” Prevalent in society where people rail against subjects they were forced to learn and then claim their day job never needs them.

I think whether or not you actually use anything you learned in CS courses highly depends on what you want to work on. My interests happen to be in compilers, computer graphics, and cryptography and I find I need to quite often revisit stuff I learned in college.

Even when I was writing 8-bit games and demos on the Commodore 64 I found some need sometimes for these skills like replacing expensive functions with approximations.

I’m not saying interviews need to question you on these things, I’m saying these things are useful to study and learn and stay abreast of. Perhaps I’m biased because I kind of love math and find an inherent beauty in these things and so I find these kinds of puzzles fascinating. (The Shannon Fano plane is a particular example of a beautiful construct that I just adore for reasons I can’t explain)

Re: Google Tech Dev Guide

#178

Post by kamaal »

cromwellian wrote: post #170
pathseeker wrote: post #165

Earlier quoted context omitted.

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

That's an unfortunate consequence of the OKR process. If the company has to be chasing near moonshot projects all the time. Then they also align resources towards it. That means money is chasing those projects.

There is a huge incentive to keep launching new things. To keep doing something big. Its the classic throw-pizza-at-wall-see-what-sticks approach except the experiment is run among a huge group of people. So eventually some Pizza sticks.

But even in that case. I hear '20% time projects' culture have long been dead for now. So that means the projects have to come some one from the top to get some resources.

Re: Google Tech Dev Guide

#179

Post by SamReidHughes »

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…

The point is you are claiming that people need to study up a month for a Google interview. My point is that there are many people who do not need to study up for a month, or at all. They walk in, get asked some fun little data structures problems, and solve them.

This idea that some people like to push, that these interviews are all about memorization, is a false one.

Re: Google Tech Dev Guide

#180

Post by cmrdporcupine »

jsolson wrote: post #98
cmrdporcupine wrote: post #73

Earlier quoted context omitted.

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 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.
Post reply on HN