I'll be the contrarian and claim that inverting a binary tree is a perfectly reasonable interview question. (Although not anymore now that it's famous). It combines basic background knowledge (what is a binary tree and how is it structured?), ability to reason logically (binary tree algorithms are often recursive, "inverting" a tree with no children is a no-op, otherwise you want to swap the children, and the children's children, and...), and enough familiarity in one language to write simple constructs without an IDE or stackoverflow holding your hand. None of this requires you to be Jeff Dean.
I will agree that the guy who kicked all this off has a legitimate complaint if the recruiter failed to adequately explain the interview process, and I'm sure there are lots of bad interviewers that focus on meaningless details or obscure trivia. But I don't agree that the concept of having candidates write code is fundamentally awful.
I also think it's an extremely simple question, but only if you've ever taken a data structures class.
Turns out a lot of people in our industry don't! I have a Computer Engineering degree, and know this stuff mainly due to this being my hobby (and having tried out for the IOI in high school). But there are former classmates who are only vaguely aware of these data structures, because they never got any exposure to them despite writing real programs.
I don't think there's a super strong argument that most computer engineers need to know much of anything about base data structures. There are so many other concepts that are more important to writing and deploying useful software (especially in the enterprise world) that at no point involve writing complex data structures. Data structures (or rather, knowledge of the internals) are much more domain specific than some of us would like to admit, especially in the age of RoR and Unity. There are many more design patters more important to know about than being able to implement quicksort (it took 6 years for researchers to write the first bug-free implementation!)
Google does it because they can. They're probably filtering out a lot of people who treat code as prose rather than a technical manual though. Which is probably why Google libraries look the way they look.
The biggest surprise for me is how many game programmers don't know about this stuff. It seems like the sort of stuff you'd run into pretty quickly
I don't get the obsession with binary trees questions on interviews. I've had several in a couple different interviews. You know how many times I've coded a binary tree algorithmn, in 15 years as a professional programmer? Zeeeeero. They just aren't that common in actual code.
Why not ask questions about, say, working with a general tree data structure, like XML or an HTML DOM? That's something that comes up all the time in many fields. Why the obsession with low-level pointer juggling?
that doesn't mean the interview question was bad, presumably in the actual google interview they defined the problem. people are confused because he didn't define "invert" in the twitter post
I'm still not entirely sure what that means. Does it mean you recursively swap left and right branches, or does it mean you create a new data structure where the bottom elements become the top elements?
Apparently it means to swap the left and right subtrees. How's that "inversion"? I'd call it "flipping" or "mirroring" or something... If this is the case, then it's a trivial solution: invert(left_child); invert(right_child);
Quite a few times. If you are doing things related to computer vision, machine learning, maps, language processing, compilers, speech etc - you are going to use all these CS stuff fairly regularly. You are even going to need stats, linear algebra and probabilities (I'd to literally do bunch of math quite a few times at work on whiteboard).
Most of the crowd here seems to be doing CRUD, JS, iOS stuff. You won't need much of CS/Algorithm skills there and I understand their statements like "I have never needed to touch binary trees in 15 years". Unfortunately they are trying to make case that this is same everywhere. Sure not all jobs at GOOG/FB/MS require strong CS skills but lot of projects at these companies do. It's not reasonable expectation to walk in to these companies who literally thrive just because of their algorithms and say I don't give a damn about CS but look at this package manager I built. In my opinion, people who can't work with something as simple as binary trees won't last a day in many of the projects at these companies. Learning frameworks and languages are easy, problem solving using CS primitives is hard earned skills.
I find myself implementing trees fairly often (and manipulating them even more often), but since I'm not using a language that requires lots of pointer juggling and lifetime reasoning, I consider implementing them a pretty basic task.
Interesting. What type of software do you work on? I ask because I write code for robotic control loops and looking to explore any possible angle. Someone who writes trees often could help broaden my horizons.
I work a pretty regular dev job (database analytics/reporting tool essentially). I of course never have to _invert_ binary trees, that's a pretty artificial example, but I had to write a method for pretty-printing tree structures for debugging something just this week.
This is a good question.
Normal web dev job? Never. Having fun with genetic algorithms? More than once.
At my day job, I did have to write a CSV parser once. Once. Don't quite remember why using an existing solution wasn't an option. I think the input wasn't exactly proper CSV format, but was very similar.
I will agree that the guy who kicked all this off has a legitimate complaint if the recruiter failed to adequately explain the interview process, and I'm sure there are lots of bad interviewers that focus on meaningless details or obscure trivia. But I don't agree that the concept of having candidates write code is fundamentally awful.