Google Tech Dev Guide • Hacker News Board

Re: Google Tech Dev Guide

#221

Post by ___alt » Wed, Dec 19, 2018, 5:10 PM UTC

bicubic wrote: post #156

___alt wrote: post #154

Earlier quoted context omitted.

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

My intent was not to blame the developer, I'm aware of the context they work in and as you have guessed correctly our engineering process is fucked up in many way.

The developer writing the correct implementation was just the earliest point where it could have been avoided in this case, I didn't want to frame it as the developer's fault, but simply wanted to say that some algorithmic knowledge still comes in handy.

My original comment wasn't clear enough about this I confess.

Re: Google Tech Dev Guide

#222

Post by ___alt » Wed, Dec 19, 2018, 5:14 PM UTC

cwilkes wrote: post #206

bicubic wrote: post #156

Earlier quoted context omitted.

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

I can’t upvote you enough. The retort to this is usually along the lines of “we are moving fast and need people to write 100% correct code”. Perhaps that’s the case, but the solution is to put guidelines down (api review, unit testing, etc) instead of demanding people be infallible. In this case a reasonable test case beyond “Did it compile?!?” Would have caught this.

In this case the two points where we should have caught the issue would have been:

* Integration testing with a specific data set that was different from actual production data.

* Code review (they're not systematic yet but we're working on that) because the faulty code had a sketchy section and the conversation around it would have lead to a better version (that's what actually happened when fixing the bug)

Re: Google Tech Dev Guide

#223

Post by fatjokes » Wed, Dec 19, 2018, 5:25 PM UTC

arvinsim wrote: post #107

mav3rick wrote: post #46

Earlier quoted context omitted.

Because APIs and languages change every few years. Concepts and foundations don't. If I move to a company using a new language, I am good enough to pick it up because the design of my sofware is more about the data structures and their interactions.

The reality is that the majority of companies do hire on the basis of APIs, languages and frameworks.

Sure. But that's not foundational. That's just a job.

Re: Google Tech Dev Guide

#224

Post by mav3rick » Wed, Dec 19, 2018, 5:33 PM UTC

sidlls wrote: post #192

mav3rick wrote: post #79

Earlier quoted context omitted.

Google's requirements also allow easy mobility between teams. If all I knew was one framework, I'd always have to prove myself again when I move teams. The hiring bar ensures that most candidates can adapt due to their strong CS base.

No, these interview questions do not signal for that kind of adaptability. They're a signal that someone studied (crammed for a few weeks, often) a small slice of CS. They're a poor signal for the work engineers do there, or anywhere, in almost every case.

Please hire using frameworks knowledge for your company. More power to you.

Re: Google Tech Dev Guide

#225

Post by mav3rick » Wed, Dec 19, 2018, 5:37 PM UTC

C1sc0cat wrote: post #171

mav3rick wrote: post #44

Earlier quoted context omitted.

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.

Google couldn't buy a page rank library unfortunately. Nor can they evolve search or develop tensorflow with people that just work off of libraries.

Re: Google Tech Dev Guide

#226

Post by C1sc0cat » Wed, Dec 19, 2018, 5:44 PM UTC

mav3rick wrote: post #225

C1sc0cat wrote: post #171

Earlier quoted context omitted.

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.

Google couldn't buy a page rank library unfortunately. Nor can they evolve search or develop tensorflow with people that just work off of libraries.

And what proportion of HN readers are in that situation ?

Not that where I worked wound not have built things from scratch - still whish I had had the budget to use ML for one project but with hard ware costs of £250,000 just for the hardware in early 80's it wasn't cost-effective.

Re: Google Tech Dev Guide

#227

Post by mav3rick » Wed, Dec 19, 2018, 5:49 PM UTC

C1sc0cat wrote: post #226

mav3rick wrote: post #225

Earlier quoted context omitted.

Google couldn't buy a page rank library unfortunately. Nor can they evolve search or develop tensorflow with people that just work off of libraries.

And what proportion of HN readers are in that situation ? Not that where I worked wound not have built things from scratch - still whish I had had the budget to use ML for one project but with hard ware costs of £250,000 just for the hardware in early 80's it wasn't cost-effective.

And there in lies the problem. HN extrapolates its skill set to be the need of ALL companies. And companies should only test for that.

I do systems for a living. There is no way I would be successful if all I knew were frameworks.

Re: Google Tech Dev Guide

#228

Post by seanmcdirmid » Wed, Dec 19, 2018, 5:50 PM UTC

SamReidHughes wrote: post #208

seanmcdirmid wrote: post #204

Earlier quoted context omitted.

Maybe not a month, but many have done it for a month to get that dream job at google, the possibility is there and that could be the competition you are calibrated against. Ya, I think we are sometimes actually better off with the generic brain twister questions because the more specialized questions are harder evaluate. Like, my idea of writing a code editor might be completely different from yours because I’ve deal…

It does seem to me, reading online the past few years, like there has been an inflation in difficulty of a certain category of interview questions, as a result of people studying. Usually, when interviewing people on an algorithms interview, I've asked an straightforward warm-up question, followed by a more interesting second question, that might be difficult for somebody that hasn't thought about anything interestin…

> that might be difficult for somebody that hasn't thought about anything interesting in 10 years.

Coming from doing research for the past 10 years and now looking for a dev job, I have the opposite feeling: all these interview questions (even the hard ones) are way too boring.

Re: Google Tech Dev Guide

#229

Post by saulrh » Wed, Dec 19, 2018, 7:16 PM UTC

pathseeker wrote: post #153

saulrh wrote: post #31

Earlier quoted context omitted.

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…

I got pissed off at the "Google this, Google that" sentence because it's bad faith debate technique. The point could have been made just as well with a comment about company towns or cyberpunk megacorporations. The hysterical repetition contributes nothing to the part of the argument that matters in real life and serves solely to incite unthinking, involuntary anger.

And, yeah, the complaint probably should have gone in its own post, and had some more explanation. Double-posting still feels wrong somehow.

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

You don't ask those questions when interviewing a civil engineer because a licensed civil engineer has passed the FE and PE, eight-hour open-note tests that permit only basic scientific calculators. So not only are civil engineers tested on their ability to handle the basics from memory - you know as well as I do that writing the notes for a serious-business open-notes test is half the difficulty all by itself - they're tested in conditions which impose far more constraints and pressure. I don't think I've done a single interview where I didn't go back and forth with the interviewer to get hints and clarify requirements. Eight hours locked in a room with pencil and paper, fuck that.

I agree that Google's interview is stupid, but I've gotten into this argument dozens of times over the last decade and every time I try to think of an alternative I come up with something that has its own weaknesses. For example, one of the reasons I went for a CS degree instead of a software engineering degree is that it's absurdly difficult to pick up formal CS theory on the job but you'll be learning software engineering every day. Take-home tests are unscalable and derided as insulting wastes of applicants' time. Contract-to-hire is too easy for employers to abuse. I can't even imagine how badly a licensing test for CS/software engineering would go.

The best I can come up with is to do the same style of interview but on a computer. Which I think Google might even do these days, but I went with the whiteboard one because I don't want that much riding on my laptop working that day and I run at a greater disadvantage coding on a loaner laptop than I do on the whiteboard.

Re: Google Tech Dev Guide

#230

Post by agentultra » Wed, Dec 19, 2018, 7:17 PM UTC

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…

> Algorithms aren't foundational

Ok. I'll tell you that I want my API to never take longer than 100ms as part of our service level objective. Code you contribute to our system is consistently failing to meet our objectives. Make it faster.

We're designing a game engine. Our objective is a smooth 50 frames per second. We want to do dynamic lighting, destructible voxel terrain, the works. Code you're contributing is consistently dropping our frame rate. Make it faster.

We make financial trades in some secondary market. Our goal is to ensure all transactions are atomic and take less than 100ms to complete. Code you're contributing is consistently failing serialization of the transactions leading to failed trades. Fix it.

These are but a handful of examples where algorithmic knowledge is useful. There are more. Without algorithmic knowledge you'll simply be rediscovering everything on your own, making up new things that don't make sense, and struggling to stay useful to your team.

There are programming tasks that clearly don't require it. Most web development jobs for SMEs are competing on price with other contractors for a commodity resource: time. For those jobs a pragmatic knowledge of the programming language, tools, and libraries is sufficient: the problem you're solving is valuable but low-effort where time is of the essence. The faster you can pop out a web app and move on to the next one the better.

These things belong to the same class of skill: programming. However I think algorithms are still foundational because even in the latter case performance and correctness still come up in less critical areas: time to first paint, real-time updates, etc. Even a cursory understanding of the difference in magnitude between O(n) vs O(n²) is useful if you understand that using the right data structure will solve 90% of your problems.

> Once you understand the syntax of programming

Syntax is trivial. semantics are what matter. Take Hy as an example: it's a lisp syntax. But a Hy program is only a Python program. ReasonML takes this idea even further allowing programmers to work in whatever local syntax they find useful.