I generally don't recommend using one of these and/or memorizing the Big-O performance of algorithms. If you find yourself doing that, then you don't understand what the algorithms are actually doing, and that's a more fundamental issue that you should address.
When interviewers ask you to state the Big-O performance of an algorithm, they don't do it to see if you know the Big-O notations of algorithms, per se. They test to see if you understand how the algorithm performs. And if you know your algorithms, then that should be a (relatively) easy question to answer.
Fun fact: I've never had an interview where someone asked me about any of these CS algorithms/data structures. More often than not, you are asked to write a solution to a particular problem and then assess its performance. That is something you can't memorize, but certainly something you can 1) understand, and 2) practice.
This is a good point, of course rote memorization will not replace actual understanding, and one would hope any decent interviewer would be able to instantly tell the difference. I don't think the point of charts like these is to cheat at interviews.
That said:
I've never had an interview where someone asked me about any of these CS algorithms/data structures.
This likely varies by job domain/region/experience/whatever - I've only had one interview where I wasn't asked some arbitrary academic question about a data structure I'd never need to know in practice. Technical interviews are pretty varied, and usually broken, but this sort of thing has definitely been a theme for me. Usually in the context of a challenge problem, like you said, but I've been asked to cough up and compare and contrast options to fit a problem. A huge theme of my interview experience is "okay, tell me what the Big-O of your current solution is, and then improve it given the data is constrained by whatever". Studying a chart like this helps me, at least, even though I do understand conceptually why the values are what they are.
So, yeah, I agree, that's ridiculous. I do sorta see what they're getting at though - they want to hear you talk it through. My similar example is "how many gas stations are there in the Continental US?". Who knows or cares about the answer, but a dev employer would care about how you approach the problem.
I generally don't recommend using one of these and/or memorizing the Big-O performance of algorithms. If you find yourself doing that, then you don't understand what the algorithms are actually doing, and that's a more fundamental issue that you should address.
When interviewers ask you to state the Big-O performance of an algorithm, they don't do it to see if you know the Big-O notations of algorithms, per se. They test to see if you understand how the algorithm performs. And if you know your algorithms, then that should be a (relatively) easy question to answer.
Fun fact: I've never had an interview where someone asked me about any of these CS algorithms/data structures. More often than not, you are asked to write a solution to a particular problem and then assess its performance. That is something you can't memorize, but certainly something you can 1) understand, and 2) practice.
This is a good point, of course rote memorization will not replace actual understanding, and one would hope any decent interviewer would be able to instantly tell the difference. I don't think the point of charts like these is to cheat at interviews.
That said:
This likely varies by job domain/region/experience/whatever - I've only had one interview where I wasn't asked some arbitrary academic question about a data structure I'd never need to know in practice. Technical interviews are pretty varied, and usually broken, but this sort of thing has definitely been a theme for me. Usually in the context of a challenge problem, like you said, but I've been asked to cough up and compare and contrast options to fit a problem. A huge theme of my interview experience is "okay, tell me what the Big-O of your current solution is, and then improve it given the data is constrained by whatever". Studying a chart like this helps me, at least, even though I do understand conceptually why the values are what they are.
You can say that again.
I once had a phone screen where I was asked to estimate how many feathers would fit inside the volume of your typical brick.
That was my biggest WTF interview to date.
Fortunately, my other interviews have been pretty pleasant (so far).
So, yeah, I agree, that's ridiculous. I do sorta see what they're getting at though - they want to hear you talk it through. My similar example is "how many gas stations are there in the Continental US?". Who knows or cares about the answer, but a dev employer would care about how you approach the problem.
Its 2022,and your approach is still valid.I bet it will still be valid in 2040.