I remember an interview where I was asked to solve an algorithm from my college days. In the 10 years out of college, I've never needed it and to remember how to solve it during a timed interview seems completely unreasonable.
I ultimately joined that company as, I believe, the oldest engineer at the time. (At the time, I felt the remaining gauntlet of questions they asked were appropriate for the position I was applying for. And in retrospect, it was the younger interviewers, significantly junior to me, who were asking all the questions that required rote-memorization to answer, and the more experienced interviewers didn't.)
In another case, I was I getting interviewed (again, via phone) with a bunch of CS algorithm questions. Now, I have a CS degree, but none of this stuff comes up day to day. I told the interviewer that if these were the kinds of questions, then it didn't seem my 20 years of experience were what they were looking for. The interviewer, someone probably 15 years younger than me, was really flustered, since he was reading stuff right from some collection of questions they had previously prepared and this response didn't match any of the acceptable answers that were listed. The company recruiter called me back later and apologized because the feedback she got from the interviewer was that they were not prepared to interview someone with my experience. Oh, and any tips I could give their recruiting team to address this would be appreciated.
I told them I'd be happy to help improve their interview process, at my normal hourly rate.
I don't think these filters are explicitly designed to reject candidates based on age, but it does result in it as a side-effect due to the freshness of those topics in the younger candidates' mind. And it just ends up being "easier" to go with the candidate who can recite the answer they are looking for, vs actually evaluating the candidate's fitness for the given job. Or hiring someone and seeing how they work out. There's this need to "hit the ground running" with new hires, and a perception that somehow, those who can answer these random trivia CS questions are able to do that better. This isn't an excuse, however I think it does give us some information on how to address the existence/perception of age discrimination where it does exist.
(BTW, I took your use of "implicitly" as being unsavory, to mean "we won't need to reject people due to age, we'll just set them up to fail our test, and maintain our youthful culture", which is where a lot of the rhetoric around age discrimination is focused. That is, I don't necessarily consider it to be the result of bad actors, but inexperienced people who are forced into doing something they don't fully understand or appreciate the complexity of, and they just want to get it off their plate. Admittedly, you might have meant it as I describe in the former paragraph.)
If you know how quicksort works, I think this is a great question because it tests your ability to explain technical material to another human. I think that is a vital skill in all programming jobs.
Of course, if you happen to not know it yourself, you're sunk.
> I told the interviewer that I had not done that in years and I wouldn't implement a sorting routine from scratch these days because I'd use a sorting routine from a library.
Let's say you have a list of events. For each event, you know the year, month, and some other data. You want them sorted chronologically. Obviously you're not going to code the sort by hand. Maybe you'd consider:
1. First sort them all by month.
2. Now that the months are in order, sort again by year to group the years together.
But that does require you to know what a "stable sort" means, and it's likely you won't have a good intuition for that unless you're familiar with at least one unstable sort like quicksort.
> I don't think these filters are explicitly designed to reject candidates based on age, but it does result in it as a side-effect due to the freshness of those topics in the younger candidates' mind.
You say that like freshness is some immutable fact.
I'm a college dropout. Much of the stuff you learned 20 years ago in college, I never got a chance to learn.
So when I started interviewing, I hit Wikipedia and started learning and implementing some algorithms. It's not that hard to refresh your brain, and I'm a better programmer because of it.
Since then, I have often been able to apply that knowledge to my work. I'm continually surprised how often some seemingly muddle hairball of a problem is really just a graph traversal, or a topological sort, or a heap, etc. when you look at it right.
Algorithms and data structures are just new perspectives you can use to approach your work. Who wouldn't want more ways to be able to look at a problem?
> Let's say you have a list of events. For each event, you know the year, month, and some other data. You want them sorted chronologically. Obviously you're not going to code the sort by hand. Maybe you'd consider:
myList.sort(key=lambda x: castToTimestamp(x))
While this is true, that was not the context of how the question was asked.
Obviously you're not going to code the sort by hand.
Maybe you'd consider: 1. First sort them all by month. 2. Now that the months are in order, sort again by year to group the years together.
You've used a relatively massive number of words to describe radix sort (my favorite sort, incidentally).
However, the other response to your comment is exactly what I was talking about. No one is going to get extra points for reimplementing any sorting function while they're on the job (unless designing and optimizing sorting functions actually is the job, which is insanely rare). They're going to get recognized for getting the list of events persisted, queried, and displayed to the user in a meaningful way.
I'm a college dropout. Much of the stuff you learned 20 years ago in college, I never got a chance to learn.
That you didn't get a chance to learn it doesn't negate the fact that asking someone how to implement quicksort during an interview is a red-herring and misdirection from the actual work that will be done on the job. It is in no way representative of the tasks the wide majority of programmers, software engineers, software architects, and systems operations people are asked to do. The actual value in studying sorting algorithms is being able to calculate and recognize the work done and compare their complexity, aka Big-O notation. And, in fact, the different sorting algorithms are used in school explicitly to demonstrate measuring, recognizing, and studying complexity. Showing one implementation doesn't demonstrate that one knows how to do that (although, could be used as a lead in to further questions, as you point out, about, say, stability).
In my experience, this kind of interview question is not intended to demonstrate knowledge of measuring complexity; if they were, it would be phrased differently. "How would you implement quicksort" is a throwaway question on the part of the interviewer. It allows someone to check a box that shouldn't be there in the first place.
So when I started interviewing, I hit Wikipedia and started learning and implementing some algorithms. It's not that hard to refresh your brain, and I'm a better programmer because of it.
If this helps you get the job, then great. But it's not a great interview experience and it ends up excluding a lot of people, for whatever reason.
Rather, let's talk about specific times or experiences that the complexity of some system the candidate wrote or had to deal with presented a problem that needed to be solved.
Admittedly, that doesn't work if your candidates, for whatever reason, are young/fresh out of school, and don't have experience to be able to talk about. Then questions about the specifics of quicksort are applicable. The reason I related my second anecdote was to show that they recognized that the interview method they had were using ended up catering to a specific kind of candidate and wasn't inclusive enough to the wide range of candidates that were available and appropriate for the position. I don't know if they ended up changing their sourcing and interviewing process after that though.
Since then, I have often been able to apply that knowledge to my work. I'm continually surprised how often some seemingly muddle hairball of a problem is really just a graph traversal, or a topological sort, or a heap, etc. when you look at it right.
You shouldn't be: most things are. I think it's a problem in our industry that many people don't recognize that, and it leads to a lot of reinventing of the wheel. Maybe it's because they never learned it, and are not interested in continuing to brush up on it. If you're keeping the specifics of a specific algorithm fresh in your mind by cramming right before an interview, that's great (I, personally, don't have the time, nor interest, to cram for a single interview). Being able to recognize a graph traversal, or that a database implements a specific kind of b-tree and what that means for read and write performance is separate from being able to implement those things, or describe implementing them, on a white board or, ahem, over the phone.