Devil's avocado: if they're truly CS fundamentals, then they should be baked into you good and deep during the course of your college education. It shouldn't be painful at all.
Maybe you're just not doing serious programming. Most people I know implement data structure searches quite often.
If you're writing scripts, or JS code for web pages or something like that, then maybe you don't use CS stuff, but ... are you able to write a web browser if you had to? Are you able to write an operating system or navigational software for a spacecraft? If not, then maybe just see this as revealing sectors of your skill set that could be beefed up, rather than presuming that none of that stuff is important.
> Maybe you're just not doing serious programming. Most people I know implement data structure searches quite often.
Wow. Really? Most serious people I know use other people's implementations that have already been highly optimized and well tested because they have better shit to do than reinvent the wheel.
I suppose if you want to write your own red-black tree from scratch, that's your prerogative. The last time I did was 20 years ago and not only will I never do that again, I will laugh at anyone who does it without a damn good reason.
> Wow. Really? Most serious people I know use other people's implementations that have already been highly optimized and well tested because they have better shit to do than reinvent the wheel.
Ditto. Those who decided to reinvent even basic data structure stuff left me a huge string of bugs to fix, which I eventually got so fed up with, that I started replacing their code wholesale with off the shelf solutions to stem the flow at my last job.
Aside from fixing an untold number of implementation bugs, the replacement caught several usage bugs as well, due to actually having some error checking built in.
We had just plain broken hashtables, "lock free queues" that didn't use memory barriers... or interlocked intrinsics... or even volatile, if my memory is correct - and not a debug visualizer to be seen before I got my hands on them, of course.
> I suppose if you want to write your own red-black tree from scratch, that's your prerogative. The last time I did was 20 years ago and not only will I never do that again, I will laugh at anyone who does it without a damn good reason.
Besides laughing, I'll tend to -1 the code review as well.
In many performance-programming situations you are subject to constraints that prevent use of a general solution or else makes use of a general solution massively inefficient.
For example, your data structure is on the GPU and your data is in a texture in a certain specific format because of other reasons.
If you wrote the above reply without considering this kind of case, it probably means you haven't been exposed to very much of this kind of case ... ... which was my original point.
The question isn't whether you should reinvent the wheel, it's whether you can if need be. It is important for companies to weed out candidates that can talk a good game but are useless when it comes to actual programming. So maybe in the process good candidates fall through the cracks, but then again, nobody has invented a perfect way to interview candidates.
In any case, how would you even go about knowing whether a certain piece of existing code that you blindly pulled in from some random place is optimized for your particular use case without first being able to conceptually understand it - which is all an interview is. Nobody expects candidates to create production ready code on a whiteboard.
Nobody's advocating rewriting your own red-black tree from scratch, for no reason. People applying data structures talent and skill aren't copying down algorithms they have in the standard library.
CS fundamentals like BSTs are definitely not used to teach programming--things like video game projects are--they're used to teach algorithm design and analysis. CS is an academic science, it's not a technology trade.
I think a more fundamental skill these days is figuring things out. For instance, a test where you actually have to google for the docs to something and figure out how to use it might make more sense.
The idea that "serious programming" means abstract data structures or coding in assembly is weird to me. I would consider a lot of people serious programmers who, while they may know how to do those things, don't actually do them almost ever.
What material did you spend time on that you don't know how to reverse a binary tree?
It isn't a difficult problem, even having never seen it before. This is one of those warmup problems to test how comfortable a candidate is with basic concepts such as recursion.
Especially as a fresh grad. Reviewing for a week or two if you've gone to a good school/actually did your work instead of 'consulting google' is definitely enough...
