Linus never used CVS because he couldn't stand it. The kernel had no version control until BitKeeper came along specifically because Linus wasn't sold on version control until he discovered BitKeeper, and then when McVoy killed their licenses, Linus chose to write his own system because he didn't like any of the existing ones.
But BitKeeper was created by an old guy (Larry Larry McVoy[1]) who was born in 1962. Not only that, but BitKeeper is built on top of SCCS[2] which predates RCS (and RCS predates CVS).
BitKeeper was a totally new solution to a very old problem that was "solved" years ago. It was created by an "old guy" who knew the wheel had a large flat spot and figured out how to make it round. It was subsequently adopted by another "old guy" (Linus) who refused to use wheels with flat spots.
This is not the kind of comment HN needs more of. A better version would (a) drop the snarky putdown, and (b) actually say what Google's conclusions are. Then readers could decide for themselves to what degree those findings contradict these, instead of being told what to think.
Another instance where silicon valley favors the young... he probably would've nailed this question if he'd been only a couple of years removed from school.
He also would've nailed it had he been given 10 minutes to do some research to refresh.
Silicon valley (and the numerous companies that mock the interview style) are testing for the wrong thing when they hire, then complaining about not being able to find good engineers.
You're given weeks to refresh your knowledge ahead of a Google interview. They tell you the basic CS fundamentals that are going to be covered. Binary trees are MOST ASSUREDLY on that list. They just don't have time during 45 minute interviews to let the candidate go on the Internet to look things up they should already have come prepared for.
Anecdotally, at a previous company, we tried an "open book" (i.e. you can use the web) interview policy for a few interviews. It was a train wreck.
I just don't get it why companies assume you can spend so much time to refresh and memorize topics just to prepare for an interview. Especially when this knowledge will only be used in the interview process and then forgotten about.
Not sure why you were downvoted, to be honest, because I think this is a reasonable take. I don't prep for interviews (or, these days, for sales discussions), except to read about the company and to consider how my skill set can help solve their problems.
Google's insistence on this preparation thing is doubly weird to me when I consider that literally nobody "prepares" for work every day in this manner; knowing what a developer can do after studying his brains out regarding things that will be ejected from the brain again immediately after the interview doesn't really send a meaningful signal.
>> You're given weeks to refresh your knowledge ahead of a Google interview
Begs the question, doesn't it?
>> Binary trees are MOST ASSUREDLY on that list
Sure they are... and my intro to CS textbook was ~500 pages. I'll bet I could find something to trip up just about anybody, especially when coupled with the pressure of doing it in front of the class ^H^H^H people that have $$$$/power over you.
At prior employers we've had very good luck with open-Google interview policies. I mean, we'd watch what you're Googling, and if you're copy-and-pasting we're going to drill you to make sure you actually understand it, but I expect to have a search engine when programming and I think you should too.
I prefer not to ask code questions at all, though.
It may be that we didn't give it a fair shake, as everyone who we tried it with probably would've failed anyway, but it turned what would normally be merely failing interviews into completely excruciating situations. When Googling is an option, a lot of people were spending all of their time in the interview attempting to cobble together vaguely relevant Stack Overflow responses. It wasn't just "I'm going to look up the exact name of this library function because I don't remember it", it was wholesale Googling of data structures and algorithms.
If all someone needs is help remembering the name of a specific function, then I'd rather provide them with that if I remember it or just spot them it as something trivially Googleable. I wouldn't hold that against someone unless it seems like they're completely unfamiliar with the language they've chosen to use. There's no need to give an otherwise good candidate the chance to self-destruct over trivial details like that by obsessively Googling everything to make sure it's exactly correct when that's not what I care about, and in so doing they aren't paying as much attention to overall algorithmic details, which I do care about. If they need more help than trivial Googling, then they can't solve the problem anyway, and me watching them thresh around on the Internet isn't helpful to anyone.
A good analogy is laptops in classrooms. A lot of students will attempt to use laptops to take notes, even though they inevitably serve as a distraction, and study after study has confirmed that students actually learn better when they take handwritten notes. Somewhat paradoxically, studies of classes where professors have banned laptops and forced handwritten notes show higher student happiness; they're aware on some level that they're more engaged with the class and are learning better, and appreciate that the choice to distract themselves is removed, because if the choice were possible, they might not be able to exist. Well, providing someone access to Google in a coding interview is very similar to letting students use laptops in classes, in a lot of ways.
I was on BOS around the same time patio showed up... It's amazing to see how "far" he has come. What he has mastered is marketing to developers, more than anything else. Of course it doesn't add up, because it's like all marketing: all sizzle, no steak.
We want someone who has less than 12 years of MANAGEMENT EXPERIENCE. The reason is that if you haven't been coding for 12+ years...you probably are not "hands-on" enough
This arbitrary cutoff makes absolutely no sense. I'd like to see your quantification of skill drop off per year of management.
If what you are wanting is a hands-on technical manager, then you need to say so.
And it shouldn't matter if the person has been hands on for 5 years or 20.
But I feel I'm being a little too generous regarding your motives here.
