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 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've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
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.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
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 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...
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 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 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.