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

51–60 of 250 posts

Re: Google Tech Dev Guide

#51

Post by m0zg »

SamReidHughes wrote: post #49
m0zg wrote: post #36

Earlier quoted context omitted.

It doesn't. This seems like a typical Google interview question. 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. And brute force solution will not get you a good grade in a tech interview at Google. It's idiotic: once you do get hired by Google, easily 80% of your work is copying one proto buffer into another, an…

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

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 juggling as well, just for the interview.

Don't get me wrong, I'm not saying DP is useless, it came in handy a couple of times over the course of my 20+ year career. I'm just saying that you could always look it up, and the amount of signal you get out of someone solving this problem is very close to zero, because it amounts to: "this person solved this problem before the interview", whereas the question you really need to answer is "can this person solve the problems we need solved".

Re: Google Tech Dev Guide

#52

Post by saulrh »

lwansbrough wrote: post #24
MikeLui wrote: post #17

Earlier quoted context omitted.

What would you consider foundational?

Algorithms aren't foundational, in my opinion. Once you understand the syntax of programming, you can start learning about the applications of that syntax, which for 99% of developers rarely ends up in the shape of an explicit algorithm. It's not all bad, debugging is foundational for sure. I'd place a person's debugging skills, their ability to predict bugs, system design, knowledge of common (applicable) libraries…

> Having never needed to build my own sorting algorithm in 14 years of coding,

Neither have I. What I have had to do is recognize when I could do what I needed to do without sorting the array, understand various requirements when I'm writing comparison functions, understand why std::list::sort exists when std::sort is right there, debug a stalling mapreduce job, recognize when a library I'm using has done a stupid and written an intrusive data structure that sorts in N^2, etc. Are you seriously claiming that you'd be able to do any of that if you didn't know how sorting algorithms worked? If those things aren't in the documentation, or if you run into the intersection of that thing and some other issue, you're hosed unless you know the math.

For that matter, why are you so focused on sorting? You know what I have to write all the time? Tree and graph traversals. Why does it matter if I use a stack or a queue if my traversal will visit every node anyway? Why can I get away without maintaining a set of visited nodes in one case or the other? Hell, I have to implement something very much like a toplogical sort once a year or so. That's not something you'll ever learn by groveling over for loops in fifty languages.

I agree that you rarely need an explicit "algorithm". What you do need, regularly and consistently and on a basic level to write correct code that is usable in the real world, is knowledge of algorithms. In a perfect world everyone would know from reading the docs and from staring at stack frames that their code gets slow when they use particular data structures and libraries. We do not live in a perfect world. The engineer that cannot write a single sorting algorithm is not the one that just uses library functions for everything and is fine in the end. The engineer that cannot write a sorting algorithm is the one that writes a jumble of for loops and you improve runtime from eight minutes to eight seconds by replacing it all with hashes. The engineer that cannot write a sorting algorithm is the one that designs an API that fundamentally requires server-side session state that grinds to a halt at ten QPS. These are people that I have worked with. In every case the fundamental issue was that they had "started learning about the applications of the syntax" and never studied formal CS theory.

Re: Google Tech Dev Guide

#54

Post by elteto »

lwansbrough wrote: post #24
MikeLui wrote: post #17

Earlier quoted context omitted.

What would you consider foundational?

Algorithms aren't foundational, in my opinion. Once you understand the syntax of programming, you can start learning about the applications of that syntax, which for 99% of developers rarely ends up in the shape of an explicit algorithm. It's not all bad, debugging is foundational for sure. I'd place a person's debugging skills, their ability to predict bugs, system design, knowledge of common (applicable) libraries…

Foundational means the core set of principles/theorems/abstractions underlying everything else. Saying that debugging is foundational is like saying that knowing how to use a TI-89 is foundational for math. You don’t need a calculator or a computer to do math or computer science.

In the end you choose what you spend your time learning and if you decide that all this computer science is not worth it then that’s fine. But you will objectively become a better programmer if you understand these things. Even if you never use any of it.

Re: Google Tech Dev Guide

#55

Post by AlexCoventry »

m0zg wrote: post #36
akanet wrote: post #5

Earlier quoted context omitted.

That's certainly your opinion, but the subsequence problem is a very general, abstract question that offers the candidate a number of ways to arrive a progressively better solution by following their intuitions. It's not the greatest interview question, but it's certainly not the worst. This website appears to be for people who already know how to code, and offers many different paths as well.

It doesn't. This seems like a typical Google interview question. 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. And brute force solution will not get you a good grade in a tech interview at Google. It's idiotic: once you do get hired by Google, easily 80% of your work is copying one proto buffer into another, an…

> 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

Not with that attitude.

Re: Google Tech Dev Guide

#56

Post by AlexCoventry »

m0zg wrote: post #51
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.

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…

> only non-bruteforce solution worth pursuing here involves DP

What's wrong with starting with a hashtable of substrings of fixed length? For inputs with low autocorrelation, that'll get you a good average-case speed up.

Re: Google Tech Dev Guide

#57

Post by kagol »

m0zg wrote: post #51
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.

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…

> The problem here is the only non-bruteforce solution worth pursuing here involves DP with less-than-straightforward memoization rules

The solution commentary [1] doesn't mention DP.

[1]: https://techdevguide.withgoogle.com/resources/find-longest-w...

Re: Google Tech Dev Guide

#59

Post by izacus »

lwansbrough wrote: post #25
jrochkind1 wrote: post #6

Earlier quoted context omitted.

Seems like a pretty normal algorithms problem to me. Anyone that's taken a CS curriculum has done plenty of them.

Yes, and that's just about the only time they'll do them. That's the problem.

Only if you work on something basic your whole career.

Re: Google Tech Dev Guide

#60

Post by peterwwillis »

I checked out the "cloud infrastructure" section and there's no challenge questions or code snippets. It's less of a "Tech Dev Guide" and more of a "Here Are Some Bookmarks I Found, Check Off The Ones You Read". It's not a terrible idea, but more of a suggested reading list than a "guide".

There's at least 10 years of such articles and videos piled up on the internet. Going through them all will take a long time, and even if it covers working with Google products the way Google wants you to, it's not necessarily the way you're going to use Google products at your company.

What I really want is a single place where all of this can be documented, first as overviews, and then deeper knowledge that isn't exposed by blog posts or books, or even official documentation. I want an authoritative tech encyclopedia built on knowledge shared by a community of experts.

I'm trying to cobble something like that together right now, but it's surprisingly hard to organize in a way that isn't just a list of quick start guides for tools. And then there's what you present first, and how. Do you need to know Git merging strategies before you learn build pipelines, or can you just make some assumptions and wait til later?

Post reply on HN