Wait.
Do you, really?
The only people who can do this off the top of their heads are
- People who write sorting algorithms in their day-to-day job
- People who recently encountered a performance issue in their code and thought it might be down to the choice of sorting algorithm
- People with a genuine interest in sorting algorithms
- Recently graduated university students
- People who've just been asked to do it in a whiteboard interview and have vowed to not make the same mistakes next time
These are scientifically ranked in ascending order of likelihood.
Notice I didn't mention "people who need to know which is the best sorting algorithm to use in a given situation", because those people don't need to know how to write a sorting function. Those people will use an existing sorting function which has been written and optimised a long time ago.
In fact, most developers can go their entire career without even needing to know what algorithm is being used when they call a generic sort() function. It's far more likely that you'll need to know how to get the data in a useful order in the first place if it comes to that, so knowing about indexes on an RDMBS might be handy.
Knowing about Big O might be handy, or at least knowing what it is, even if you can't go into detail. To me, knowing there is a difference is more important than knowing what that difference is. Knowing how to research it at the time is more important still.
So if you attend an interview and someone asks you to write a particular sorting algorithm, ask them whether anyone has ever had to do that in their role at that particular company.
And if they can't answer, then your response can just be, "I'll Google it when the time comes."
--
Cover image by Sophie Elvis on Unsplash
Top comments (18)
I do not think that is a valid excuse during an interview. It’s not the fact that you need to know it to work there, that’s like elementary school students saying when will I ever have to use math.
I would look at it another way: if you're being asked to regurgitate CS basics in an interview, rather than how you might creatively solve real world problems, the work they have in mind for you is probably fairly dull; or they have a very poor interview process.
I have zero formal CS experience. I would definitely need to look up the theory of writing a sort algorithm; but in one interview I was told I was only the second person to completely solve their sample problem. From what I gathered they had a fair number of CS graduates apply...
I'd have absolutely no hesitation telling a prospective employer why their interview process is borked. If they're not receptive to constructive criticism I don't want to work for them...
Some times we get to be choosy about the environment we want and in those scenarios I agree that looking for those indicators is of high value.
You're right: not everyone gets to be choosy; but I don't think that means you have to learn sort algorithms (or all the other possible 'standard' problems you might be set) for the purpose of passing ill-conceived interviews; and I think that was the point of the article ;)
I wouldn't advocate refusing to do a task in an interview; but you could instead talk through the processes you'd follow in order to solve a problem: e.g. why would I need a bespoke sort here when I know there are plenty of built-in options? Is performance really going to be such an issue that the extra development time is justified? How will I test performance? How do I establish if the solution I found is the most appropriate? etc. That demonstrates thought processes that are going to be much more useful to an employer than the fact you memorised something that can easily be found online.
I think that's kinda the point of this post - you probably don't need to know that in your day-to-day professional life.
You do need to know a bunch of other stuff, but implementing bubble sort, quick sort, or any other well-known algorithm (even FizzBuzz - that's true for all, not only for sort algorithms) is probably not something you need to know in order to be a good developer or an asset to your employer.
My point is advocating refusing to do a task by your interviewer is not in your best interest to get a job. We can be clever all we want with why we don’t need to know or prove something but they decide if you are in or out.
I agree with you in the fact that its probably not the best route in obtaining a job to go. My issue is when an interviewer asks me algorithm question(s) when they never use that in in their daily job. That frustrates me, 'why ask me that if its not an integral part of the job?'.
I can understand that, there are better ways to test someone’s working knowledge or ability to find it. Personally, I’ve worked with HR people and it seemed more personality based than technical based in my experience.
I'm not advocating "refusing to do a task", btw. I was more getting at demonstrating (without being too pedantic about it) that you can evaluate what you need to do to solve a problem, and how you might go about finding a solution. For something like sorting, Googling or looking on Stack Overflow is likely to be sufficient for most problems. If it was something esoteric, then more effort might be required.
There is a certain level of difficulty in learning and implementing these algorithm. That too for a non CS person its even harder.
Hence I don't consider it as an excuse. People want to ship projects and if that does not need to know those algorithms, then so be it.
Learning libraries/frameworks/OOPS should be enough I feel. There needs to be certain level of empathy for such developers, specially self startes.
I'm not even really on about learning things like libraries. What I used to look for back when I ran interviews was a general idea of how to approach things. If that was, "I don't know, but here's what I'd do to find out..." then that's great. If it was "here's a stock answer straight out the textbook but I can't explain why it's a good fit" then that's not so great.
I think that’s a good way to look at it, dev is very diverse in what you can encounter and it’s not fair to expect someone to know everything out there.
The tech community has a lot of bodies to fill the entry level so they want the best they can get, so if someone performs well on all their requests they will be more likely to get the position.
Like you said algorithms can be complex to learn, and more experienced devs likely have been exposed to algorithms and will be easier to identify.
Ultimately it comes down to the recruiter/hiring reps methods and what they value so it’s a gamble.
I second your opinion.
On a very similar topic, I posted this dev.to/swarupkm/will-i-still-be-ca... . I was glad to see some seasoned developers had their opinion similar to what you have mentioned.
I don't need to know a sorting algorithm, because I eat the whole box of Smarties by myself. I'm not sharing!
I totally agree with you.
I have in fact, only ever sorted one data set, and that was the lottery numbers in a little web-scraper :D
Ben, I love your writing style. It's super fun and conversational!
I'm not sure I'd be comfortable using that answer in an interview, but we'll see how it goes 😅
Why thank you:)
Sad but not necessarily wrong, I’m in the market and looking for entry level but I have a very diverse skill set. Transitioning from an IT position.