Entirely! Example: When has anyone ever actually needed to know the exact details of a red-black search tree?! In my decade of professional software development has this not appeared once. Not even remotely. Yet this is apparently "standard required knowledge" for interviewing at google, amazon and co.
The point the author is making is that interviews often question knowledge that is so far removed from actual work (aka the Arab influence on modern day Spanish), that it is kind of a joke.
I call this mind wanking. Interesting and may be fun. But not actually relevant.
Instead of asking far removed questions, I interview with actual current hard engineering problems that I or my team is faced with. That way you learn something, they know what actual work would look like. No time wasted. Win win.
> Yet this is apparently "standard required knowledge" for interviewing at google, amazon and co.
What makes you think that? My experience is that Google at least would never ask a question about red-black trees. I doubt Amazon would either. These big companies stick to questions that don't require a lot of specific knowledge because they know that a question about red-black trees mostly tests how recently you've studied red-black trees. I've done a bunch of whiteboard interviewing, and I would be shocked to be asked a question about red-black trees at a competently run company.
"Cracking the Coding Interview" explicitly mentions red-black trees as a topic that you're unlikely to see in an interview (for obvious reasons).
I think the places you see these sorts of questions asked are smaller companies that are imitating the big players without really understanding how to do it right.
Was it before or during interview? If during, like "you should have studied it", then it is wrong way yo do it.
If it was before, then I think it is fine. It basically test whether you are able to learn something like red-black trees when needed. I would consider such question a good one.
>In my decade of professional software development has this not appeared once. Not even remotely.
I don't say this to personally attack you, but Google and other top tech companies have made it clear that years of experience no longer holds the same weight as other industries, perhaps because other industries are more tightly regulated with what its members can do. Otherwise reference checks would handle most of the technical interview ("Did this guy actually build X, Y, and Z at your company?" "Yes." "Great!"). You can spend 10 years in a bad position and Google can't know every company to decide whether it should hire from your company or not.
This has been one of software development's strengths: literally bootstrapping yourself from "Hello World" to 120k+. It's hacks and cheat codes compared to becoming a doctor or physical engineer (the ones that need a license). It means a disadvantage upbringing can be overcome with time and tenacity. It's a romantic notion, but because of this, you have to evaluate the candidate or risk a bad hire. And bad hires, as we all know from the same echo chamber that gave us teach-yourself-boostrapping developers, can utterly ruin your business and you never want to be a manager known for making a bad hire.
Otherwise, we'd all take an exam, refresh it every number of years, and be free to disregard most of the technical interview. Getting well-regarded regulation and certification is no easy task, and I suspect there's not movement behind this because you can't kill people with software as easily as you can with a surgeon's scapel or a bad bridge.
The industry is actively fighting against glue-things-together developers by asking serious CS questions. It hasn't accepted that we have to branch the "Developer" position into more well-defined roles and add specialties (Security, AI, UI/UX). It hasn't accepted that a lot of work is actually glue-things-together.
There are certain jobs where "knowing the details of a red-black search tree" are actually very important. These jobs are generally related to implementing low level, high-performance libraries in certain contexts, conducting research, etc.
They're appropriate questions for interviews in some cases. But very few. Even at the companies you note.
I'm a recent grad, I like to keep track of interview questions. Personally I've been asked dozens of whiteboard questions across a number of companies. I have friends who have interviewed at countless places. I don't know a single person who has been asked a red black tree question.
I was asked a question like that once and knew the general details but was quizzed on the specifics - needless to say I did not get the job and my elementary knowledge about red-black trees was specifically mentioned as a reason for my rejection. This was at a highly publicised tech startup that people consider a very good employer in the industry.
The point the author is making is that interviews often question knowledge that is so far removed from actual work (aka the Arab influence on modern day Spanish), that it is kind of a joke.
I call this mind wanking. Interesting and may be fun. But not actually relevant.
Instead of asking far removed questions, I interview with actual current hard engineering problems that I or my team is faced with. That way you learn something, they know what actual work would look like. No time wasted. Win win.