[bmay]

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

[pjlegato]

Knowing what these structures are and having a working knowledge of how to use them is not the same skill as being able to implement them from scratch (on a whiteboard, in an hour or less.)

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.

[bmay]

1) If you know what a DAG is and how to use it, you can most likely implement and traverse one in way less than an hour.

2) I've never heard of anyone being asked to implement a red-black tree during a Google interview.

[vonmoltke]

> 1) If you know what a DAG is and how to use it, you can most likely implement and traverse one in way less than an hour.

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.

[Ar-Curunir]

Whiteboard code interviews don't require you to flesh out such things in any great detail; they're intended as proxies for your thinking process.

[vonmoltke]

You should tell that to some of my whiteboard coding interviewers, then. Plus, I feel that many of the interviewers who claim to be interested in though process still have a "right" way in mind and will dock interviewees for not approaching a problem the way they would.

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

[theli0nheart]

Ugh, this sort of computer science-shaming needs to stop. I've been building software professionally for 10 years now and not once have I ever needed to weigh the pros / cons of a DAG versus rb-tree. 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. Somehow I've managed to make a career out of this. ¯\_(ツ)_/¯

[badminton1]

But ask yourself: how does your browser layout engine and scripting engine work? Is CSS some sort of self-hosting language that just materialized out of nowhere? Or there's somewhere a group of people responsible for it? (e.g: Google's Chromium team, Mozilla's Firefox team, Apple's Safari team, Microsoft's Edge team, etc.) Those people DO need to know data structures.

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.

[fail2fail2ban]

> But ask yourself: how does your browser layout engine and scripting engine work?

[But ask yourself: how does your car's engine work?]

[badminton1]

My point is: he can focus on HTML, CSS and JavaScript all he wants, and remain abstracted from internals. That's fine.

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.

[theli0nheart]

> My point is: he can focus on HTML, CSS and JavaScript all he wants, and remain abstracted from internals. That's fine.

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.

[pjlegato]

A better analogy would be hiring engine designers by spending 90% of the interview asking them questions about low level metallurgy, and 10% about engine design as such. I would reverse those ratios.

[Ar-Curunir]

A lot more people do stuff that interacts with the details of the browser engine than they do that interacts with the car engine; much more common (and easier) to find bugs in the browser engine than in your car engine.

Now if I was just browsing the internet, then, sure, your analogy might be more apt. But that's not what we're doing.

[daveFNbuck]

How do you scale without worrying about implementation detail? You sound more like a product manager than a software engineer. Their interviews are very different.

[cc81]

Of course there are jobs that require deep knowledge of advanced data structures, algorithms and optimization.

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

[theli0nheart]

I built a web app that scaled from 0 to several hundred thousand users in a few days. Somehow I managed. A key thing in becoming a good engineer is learning how to delegate certain technical decisions to those who are better equipped to handle them.

https://news.ycombinator.com/item?id=2348702

[srean]

Provided they exist in your organization and have the spare bandwidth for your needs, and itwould be them who solved the problem that needed to be solved not you.

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.

[theli0nheart]

> Provided they exist in your organization and have the spare bandwidth for your needs.

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.

[srean]

> but how many times did PageRank need to be invented? After that the true problems at Google were scaling and monetization.

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.

[daveFNbuck]

Again, it sounds like your skills lie mostly in product management rather than software engineering. While you have a valuable skillset, it's not what Google needs from a software engineer. You're good at a different job.

[theli0nheart]

TIL I'm not a software engineer. Who knew!

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

[daveFNbuck]

If you're not a software engineer, why bring up your accomplishments as evidence that Google should hire you as one?

I'm pretty sure that the people who Google hires to do Javascript/HTML/CSS do not normally go through this type of interview.

[jimbokun]

"A key thing in becoming a good engineer is learning how to delegate certain technical decisions to those who are better equipped to handle them."

Like someone with a good understanding of computer science?

[badminton1]

Well, now think in Google scale. You said hundred thousand users? add at least 3 orders of magnitude

[bradleyjg]

Horses for courses. There are people that would hate doing client training but love weighing the pros and cons of a DAG vs RB tree. They too can make a career of it.

It's a big industry, plenty of different ecological niches to fill.

[srean]

I will hazard a guess that whatever you did it was not as impactful as GFS or mapreduce at scale.

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

[theli0nheart]

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

[srean]

Where did I say engineers are not or dont need to be fantastic communicators.

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.

[theli0nheart]

> 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, again, disagree. Technical ability and communication skills are equally important. You need both to be an effective engineer.