> Makes a lot of sense, you could solve all these questions without knowing specific algorithms as long as you are good at problem solving - which is, I assume, the intent of the process.
You could solve all these questions as long as you are good at problem solving, *given enough time*.
However, with tight time constraints and perfomance pressure, the only way you could solve all these questions is memorizing and practicing all these algorithms.
There was a hilarious rant about a FAANG hiring question that was something like: "Write an algorithm for detecting if a linked list has any loops in it, in linear time, using a constant amount of memory."
Apparently the correct answer is to use "Robert W. Floyd's tortoise and hare algorithm", which is trivial to explain and code.
The catch?
It took a decade of computer science research between the original statement of the problem and Floyd discovering the solution.
So... no worries, you have an hour, a marker, and a whiteboard. Your time starts: now.
I'm just imagining an engineer coming up with a novel solution to this problem in under the hour deadline and then not getting hired because it's not the "Robert W. Floyd's tortoise and hare" algorithm.
"So we specifically asked for linear time."
"Uh, yeah, I did it in log(n). That's better."
"It doesn't match what's on this paper they gave me. Thanks for your time. We'll be in touch."
it took a few million years until Newton figured out basic mechanics. but i don't think it's unreasonable to ask a junior engineer some basic kinematics questions!
You’re expecting the mechanical engineer to recall something they learned about kinematics, not derive it on the spot. It’s a test of knowledge, rather than cleverness. The equations of motion are also more central to physics and engineering.
A decent programmer should know that linked lists exist, their general properties, pros and cons, etc. However, cycle detection is not a particularly common operation, so not knowing Floyd’s algorithm tells you very little—-and their failure to do years of research in 45 minutes even less.
Yeah, I think a closer analogue would be asking something like "derive the conserved quantities of the gravitational two-body problem" and then dinging candidates for forgetting about the Laplace-Runge-Lenz vector
A software engineer? Sounds totally unreasonable. A mechanical engineer, sure, it's going to be required material on their education.
The tortoise and hare algorithm is not the foundational skill required to make software work the way an understanding of motion is for building structures. That's why it's often omitted from educational material yet these people are able to produce usable software after even something like a bootcamp (which I guarantee basically no bootcamps ever touched this algorithm).
I'm not sure I approve of asking even more well known algorithms like Djikstra's algorithm or A* in a job interview, unless the role was something that specifically required that area of knowledge like building pathfinders for video games or robots or something.
If they actually aren't looking for people who just cram CTCI or leetcode, coming to this answer from first principles is demonstrably far more difficult than you'd expect achieved in an interview.
Which becomes forgotten knowledge in about 6 - 12 months time after you've last needed to apply it, depending on how often you'd have to use that information.
These sort of questions have an incredible recency bias, and have zero relevance to engineering competence.
I have a theory that these q's legally favor recent grads without having any explicit requirement to do so. Helps them filter for young, freshly-trained students who they can mould into whatever they like inside of the FAANG-bubble.
It's funny you put it this way. I actually did a couple of hard level Leetcode problems and I thought they would help me immensely in my day to day life in addition to helping me get better at interviews.
No such avail. In fact, unless these algorithms and problem solving methodologies are baked into your memory there's no way you are white boarding a Leetcode hard level problem in an interview.
What I was impressed at an Uber interview was their system design interview process - which basically boiled down to 'how do I abstract retrying a 429 - rate limit exceeded.
What I take is that - the interviewer is expecting a very specific solution even in an open ended system design question. It's like throwing a needle in a haystack at you and expect you to get to the needle in like an hour :).
>> which basically boiled down to 'how do I abstract retrying a 429 - rate limit exceeded
They're probably looking for some sort of variable refilling leaky bucket implementation, which is funny because I believe this is exactly what they do internally. It was probably the task the interview had in front of them in their day-to-day and wanted you to do it for them!
This is a fair design question for a senior role (which this sounds like) that promotes disccussion, but expecting a specific solution is really only testing "does this person match my preconceived ideal for what a <dev> is?" which is really dangerous and has very little value.
You could solve all these questions as long as you are good at problem solving, *given enough time*.
However, with tight time constraints and perfomance pressure, the only way you could solve all these questions is memorizing and practicing all these algorithms.