> In the real world, you use a well-tested premade off the shelf library to traverse a DAG or implement a red/black tree.
How do you know that DAGs and rb-trees are the best solution to your problem if you don't even know basic data structures?
How do you know that DAGs and rb-trees are the best solution to your problem if you don't even know basic data structures?
If you can drive, you probably have a pretty good idea of whether a car or a truck or a motorcycle or a tank is the best vehicle for a particular transport application, and you can probably actually drive all of those with minimal practice. That doesn't require you to know how to build a car, a truck, a motorcycle, and a tank from scratch. That's a different skillset.
Google pays far above market rate, so they have the luxury of hiring petrochemists to work a gas pump. Even at Google, once all the shiny is stripped away, most of the projects are simple CRUD.
2) I've never heard of anyone being asked to implement a red-black tree during a Google interview.
I know what it is and how to use it. I can implement and traverse one. I seriously doubt I could do it in an hour, especially if I don't have at least standard library documentation available.
Anyway, the post I was replying to said, " you can most likely implement and traverse one in way less than an hour" (emphasis mine). That statement has nothing to do with thought processes. To me, that requires "flesh[ing] out such things in any great detail".
For you to be able to focus on CSS, HTML and JavaScript, someone, somewhere needs to make CSS, HTML and JavaScript work for you in the first place.
[But ask yourself: how does your car's engine work?]
But here we are talking about one of the companies responsible for implementing such technologies, where the science he implies as not being very relevant IS relevant.
It's the difference between applying to a truck driver work, to a truck engine designer work. For the latter, knowing the theory of an internal combustion engine IS relevant.
The majority of engineering positions that Google hires for are exactly this. The Chrome / Chromium team is just one team at Google. Most of the engineers who work there are building/scaling iOS apps, web apps, and are doing the exact same work that I do all day long.
Now if I was just browsing the internet, then, sure, your analogy might be more apt. But that's not what we're doing.
> While you have a valuable skillset, it's not what Google needs from a software engineer. You're good at a different job.
See https://news.ycombinator.com/item?id=12653628. Far more "software engineers" at Google do the exact same thing that I do all day long than do the type of work you're referring to.
I'm pretty sure that the people who Google hires to do Javascript/HTML/CSS do not normally go through this type of interview.
I'm confused by this statement. What do you mean?
> I'm pretty sure that the people who Google hires to do Javascript/HTML/CSS do not normally go through this type of interview.
Completely false.
This is more like Al Gore claiming he invented/solved/built the internet.
If Google was only about CRUD and banal CSS, it probably wouldnt have become the Google that it is. They became so by handling challenging and ever changing problems. In such a scenario you need generalists with strong fundamentals who can pivot quickly from one problem to another, quickly, not a stackoverflow cut-paster. The latter skill has ts moments but you cannot survive on that alone, if you are in the critical path.
You can delegate to entities other than humans.
> If Google was only about CRUD and banal CSS, it probably wouldnt have become the Google that it is.
That's totally true, but how many times did PageRank need to be invented? After that the true problems at Google were scaling and monetization. Do you think the team responsible for making sure AdWords looked right on every device under the sun would agree with your statement? I'm sure a lot of the work that went into that "CRUD and banal CSS" is the same code that's made Google billions of dollars.
> They became so by handling challenging and ever changing problems. In such a scenario you need generalists with strong fundamentals who can pivot quickly from one problem to another, quickly, not a stackoverflow cut-paster. The latter skill has ts moments but you cannot survive on that alone, if you are in the critical path.
These skill-sets are not mutually exclusive.
Quite a few times actually. It was not quite obvious at that time how to run Pagerank and other algorithms efficiently at that scale while keeping running costs down. If it was just a library call and delegation away, they wouldnt have had such a meteoric rise.
We're talking about two different things here—the theoretical PageRank and the practical one. My point is that the skills required to scale a thing like PageRank—writing code to parallelize tasks, divvy up traffic, etc.— are very different than the ones involved in inventing PageRank as an algorithm.
No we are not.
Pagerank at its mathematical core was not that novel, basic undergrad stuff. The application was novel, not the equation, you would find that in a beginners linear algebra book. The real deal was (i) realizing that those equations can be applied for solving an aspect of web search and (ii) scaling it up with cheap hardware of that time and keep operational costs low to be profitable. What I am saying is that one needs a good understanding of CS fundamentals and the ability to reason to pull that off with a competitive advantage. You dont get that just by tweaking CSS or for example knowing your Java platform well or by delegating. These kind of problems are not one off. You have to keep ahead of the competition constantly, innovate constantly, have to do stuff that your competition has not yet figured out how to do.
Now that this particular scaling problem has been in the mainstream it does not seem that big a deal to solve, it was at that time. If it hadnt been, every run of the mill tech company would have been doing it to eat Google's lunch. Their manager's ability to delegate did not seem to have helped them much there.
> No we are not.
> Pagerank at its mathematical core was not that novel, basic undergrad stuff.
Whatever you say, Mr. Page. :)
> You dont get that just by tweaking CSS or for example knowing your Java platform well or by delegating. These kind of problems are not one off. You have to keep ahead of the competition constantly, innovate constantly, have to do stuff that your competition has not yet figured out how to do.
More false analogies here. The skills involved in solving technical problems are easily translatable from one technical domain to another. You make it seem like implementing an algorithm to scale servers is necessarily more complex than implementing an algorithm to stack shapes on a webpage in a space-efficient way. It's not.
> Their manager's ability to delegate did not seem to have helped them much there.
You're completely misunderstanding me. I'm not using the term "delegation" here as a managerial term. I would bet you that the team that scaled PageRank relied on countless open-source and freely available tools and tech that others wrote. This doesn't lessen their ingenuity at all, but it should be clear that even the most complex tech is built on the shoulders of others.
Oh, please. This back-and-forth and condescending attitude is getting so tiring for me. Yes, I've read the paper multiple times.
> this stuff is taught in intro linear algebra courses
I graduated with a B.S. in Applied Mathematics from Yale. I'm familiar with this stuff, thanks.
> At its core it's just a random walk on a graph;
I'm tired of making this point. There is a big difference between understanding a ground-breaking discovery and making the discovery itself.
> Of course, modelling the web this way and tweaking the middle to produce optimum results was a big deal. You'd be a fool to believe that PageRank hasn't evolved in 20 yrs.
I never once said this. I said that after PageRank was developed, most of Google's engineering resources went into scaling and monetization.
Like someone with a good understanding of computer science?
But you can easily scale quite a lot of systems to millions of users without having to know any cs at all. You just need to know how to use and configure different layers of caches, design your database(s) properly and some minor tricks around code (and knowing how to analyze performance).
It's a big industry, plenty of different ecological niches to fill.
> I'm too busy dealing with CSS bugs, figuring out why customer retention is lower than it should be, training my clients on how to use a bug tracker, scaling, and hundreds of other things which are magnitudes more important than this implementation detail
For hard-tech those become important only after there is an implementation that solves a high barrier to entry technical problem. Then you can get a good run of the mill PM to keep it chugging.
I completely disagree, and your statement is emblematic of what is wrong with popular perceptions of what it means to be a good software engineer.
The best engineers I've ever worked with are fantastic communicators and understand the product that they are building to the core. Being able to ask a good question or drill down into correct requirements is far more important than knowing how to traverse a binary tree, at any level.
All I am saying is that if you are in a hard tech area with problems that has not yet been solved well enough to be monetizable, communication and delegation is not what is going to solve it. Agile, extreme or whatever is 'in' at the moment is not going to do it. It gets solved by ability to reason about technical things. I can for instance communicate the need to cure cancer (bad example sorry) or delegate willy nilly, but sorry thats not going to solve it.
> I can for instance communicate the need to cure cancer (bad example sorry) or delegate willy nilly, but sorry thats not going to solve it.
I, again, disagree. Technical ability and communication skills are equally important. You need both to be an effective engineer.