15 ms·

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

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

ska 12y ago
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.
- msandford 12y ago
  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.
ahomescu1 12y ago
> 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".

ska 12y ago

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.

msandford 12y ago
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.

ahomescu1 12y ago

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