If you're writing a web-app knowing how the TLB works is just as relevant as knowing how a red-black tree works. Which is to say, not very.

> but known VHDL or semiconductor physics isn't a good predictor of success in that

Sure, I'll grant that. But I would also argue that a lot of what people are doing to interview isn't a great predictor of success either. Data structures and algorithms are important in some jobs, but knowing how to use git, automated deployment, testing, and shipping products or features seems a lot more relevant to job success than the "how to tell if there's a loop in a linked list in linear time with constant space" question that everyone seemed to love 5-10 years ago.

I also believe a lot of interview questions are poorly conceived. I can't, however, see why anyone would be surprised to not get many (any) detailed hardware questions in a typical software interview process. And absolutely, there are important questions you must ask about process, testing, deployment, tool sets.

But understanding algorithms and data structures is fundamental to the job, even if you spend most of your time not thinking about it at all. This is important, and failing to realize it is a prime source of hard-to-analyze, hard-to-extend, hard-to-test, and hard-to-maintain code.

An application developer (I'm leaving aside the can of worms opened by "web-app") absolutely should understand at least roughly how a red-black tree works. They shouldn't have to be able to implement one properly for you on a white board, and they shouldn't remember all the details or even the definition off the top of the head. However, given a description and a implementation (perhaps partial) they should be able to work out and describe how it works, why i works, and say something sensible about the issues in properly implementing and testing one, sure. Bonus points for knowing a couple of places they come up in practical use. Obviosly, some exception for the most junior positions.

Even if they get things wrong in the details it can be fine. But not being able to speak sensibly about such a data structure is a significant red flag. Done right, questions like this can reveal a lot about a candidates ability to do the job, even if they never directly do this. (the caveat there being on "done right". This sort of question isn't pass/fail, it's the discussion that is useful)

On the other hand, understanding the details of a TLB really doesn't to me seem to have the same sort of halo effect -- getting into details on this in a software position (with certain exceptions) seems to be more a waste of the time.

> An application developer (I'm leaving aside the can of worms opened by "web-app") absolutely should understand at least roughly how a red-black tree works.

Thanks for completely dodging any kind of substantive point I might have had. I can move the goalposts such that my opinion is always right and I can always win, too. But I generally try not to because that isn't the point of HN, at least as far as I can tell.

Here's my point. There are many, many software jobs. Only a fairly small subset of them need serious data structures and algorithms work. But interviews tend to focus on data structures and algorithms brain teasers, regardless of the actual day-to-day of the job.

I say "fairly small subset" here because that's the actual truth. There's a huge swath of programming that can get by magnificently with nothing more than arrays and hashtables.

I had a friend interview with Google to work in their uptime group or something like that. He had to solve some brainteaser about generating an in-order list of numbers that meet a certain criteria in O(n) time and constant space. I get that someone somewhere thought it was a good idea. But if you're tasked with keeping failures from happening being able to solve that brainteaser doesn't say anything about your suitability for the job. Being able to imagine disaster scenarios and how they'll play out seems a lot more important to me.

Now I'm not Google so who is to say that my opinion is right and theirs is wrong. Perhaps they're happier with the subset of folks who can do both. But it seems like they might well be missing out on the people who can imagine how bad it could get and help plan for that but who didn't take advanced data structures and algorithms.

> I had a friend interview with Google to work in their uptime group or something like that. He had to solve some brainteaser about generating an in-order list of numbers that meet a certain criteria in O(n) time and constant space. I get that someone somewhere thought it was a good idea. But if you're tasked with keeping failures from happening being able to solve that brainteaser doesn't say anything about your suitability for the job. Being able to imagine disaster scenarios and how they'll play out seems a lot more important to me.

I think Google's approach to hiring has generally been "let's hire really smart and overqualified people and then they'll be suitable for any job".

I really didn't mean to dodge anything. By that comment I meant that web-app and application is a fuzzy line, and I'd rather not distinguish between them.

Give that, I don't accept your premise. There is a huge swathe of programming that can get by day-to-day using nothing more than arrays and hashtables. And, all else being equal, in my experience this work is consistently done much better by people who can understand and reason through what is going on in a slightly more complex data structure, or describe the function of a recursive algorithm, etc. Completely avoidable design errors are often made by people ignorant of why what they were doing was algorithmically silly or using inappropriate data structures. This is often all so avoidable.

I was very explicit that I don't think you should give "brain teasers" and expect people to "perform" them in an interview. And I was very explicit that I think there are lots of other areas that are at least as (and often more) important to get into in an interview situation.

However, any developer with reasonable fundamentals can reason about a red-black tree, even if they've never seen one before.

So yes, I don't expect you prove the big O of the search time, but i might ask you why we would want to balance a tree at all, and what the balancing algorithm is achieving once you're shown it. And I'm not going to ask anyone to implement one from scratch on a board, but I might show you an implementation and ask you what your thoughts on testing and corner cases to analyse would be.

These are perfectly applicable questions (perhaps excepting entry level), and vastly more relevant than how a TLB works, which was my point. To be honest, I'd probably use something even simpler, but don't feel R-B to be unfair.

I even stated that you don't have to get these answers "right" but the discussion is useful. If you get the details wrong but say sensible things, that's great. If you can't reason anything out about it even with some handholding, it's a bad sign.

So I feel you've completely mischaracterized my response, as what I'm talking about has nothing whatsoever to do with your friends description of their google interview.

Now to your broader point - would I prefer a candidate who was an ace at algorithms but couldn't reason about system failures and risk mitigation over someone who could "imagine disaster scenarios and how they'll play out" but can't talk sensibly about a simple data structure?

Honestly I wouldn't particularly want either of them on my team, so I hope there are better candidates.

Well, you've addressed a lot of what I said and done so fairly reasonably. I think I've mostly been complaining that there are a lot of companies who value brain teasers over thinking ability and you say you're not in that camp. Fair enough.

> Honestly I wouldn't particularly want either of them on my team, so I hope there are better candidates.

It'd be nice, but Google is hiring up lots of people and it's getting hard to get everything you want. Better, faster, cheaper. Pick two.