I find that statement really depressing to be honest. Why would you be so happy to deprive yourself of a huge source of potentially useful information that is the foundation of our field that shouldn't take long to learn?
Algorithm and data structure knowledge helps you write processor + memory efficient code that scales well, and stops you reinventing the wheel when you know how to classify what category of algorithms your problem fits into (e.g. it's a graph problem, or a search tree problem, so now you know where to look for solutions).
You might not need this knowledge every day but someone who understands fundamental algorithms and data structures surely has an edge over someone who does not. If you've been programming for a while, going through a book to learn the fundamentals should only take you a few days as well - why do people make such a big deal about this?
I've interviewed programmers before who couldn't explain what a linked list or a hash table was, and when you'd you use one of those over an array. To me, that's a super bad sign they don't know how to assess algorithmic complexity when coding. It might not matter for some kinds of coding with modest datasets but it'll bite you eventually.
I don't see an end to this. Its as if all companies expect people to be competitive programmers, and they optimize only on one parameter :/
* I describe the problem
* They ask questions to figure out parts I didn't specify (which lets me evaluate how they handle resolving ambiguity)
* They propose a brute force solution, and I ask them how quickly it runs and how much space it needs (talking in big-O is a fast way for me to tell if they understand their solution)
* They propose a much more efficient solution (often with hints) and we again talk about time and space complexity (which again lets me see whether they understand how to compare solutions like this. I'm also happy to hear other tradeoffs like "this is optimal but too complicated to be worth maintaining")
* They code their solution (which lets me see if they can actually code, and check how well their description of their algorithm matches their actual algorithm)
This isn't a daily job sort of task, but it's not far off, much faster, and very information dense. I'm not testing "do you know the right algorithm" (and will hint that part).
> Who really cares about algorithm on daily bases. How often you solve algorithm-heavy tasks at work?
Practically no one and practically never for the majority of developers.
It's a trend started by Google, and since lots of startups don't bother thinking for themselves (and the interviewer wants to sound knowledgeable) some of them also ask these questions.
Perhaps this type of interview is more popular in some places rather than others - I've never had one like this, although occasionally people ask questions like "how many piano tuners are there in your city?" (answer: "let me check on Google..." or "why, are you thinking of starting a piano tuning company?").
IMO, this is the sole purpose of algortihm-heavy interviews. Companies like Google can put out a job ad and receive thousands and thousands of applicants, and the sad truth is that many of them could probably do the job that is required of them.
By putting in a loose requirement around what is essentially problem solving via known algorithmic techniques that you'll rarely ever use in day-to-day life, you can both weed out most applicants and ensure that the developers that perform the best aren't looking for an insane pay packet. After all, if you can stack rank yourself purely in programming ability, you've probably got an impressive CV and a body of previous work that means you probably don't need to work at FAANG or Microsoft to create something incredible.
I'd probably also say that there is an element of ageism, purely because older people have more responsibilities, and ultimately are more willing to spend time in the office over strictly working 9-6.
Absolutely no idea if that is true but I think it is an interesting thought.
It's like in school, you learn many things, not necessarily useful in your daily life, but you learn to learn, and that's what they can see when they confront you with a challenge
Of course, some people who heavily train for this have maybe an advantage, like in school exams.. Personally I never specifically trained for an interview, I just like algorithms, doing some leetcode.com challenges when I've time is a pleasure
I often hear that learning algorithms / data structures is pointless these days because it encourages reinventing the wheel or it wastes time. I believe the opposite is true. People who are ignorant will keep reinventing the wheel, they just won't realize they are doing it and how poorly they are doing it.
Learning algorithms and data structures will enhance your ability to write software because you will have a deeper understanding of how things work. When you understand how things work you can build interesting things.
Of course, if you just want to be a non-contributing faceless code monkey at a corporation where you don't matter and get a decent paycheck well, you probably can skate by in mediocrity. If you want to be able to build things that don't rely entirely on the work of others that actually understood what they were doing then you need to put in the time. The return on that investment lasts a lifetime.
Even though we many software engineers aren't doing challenging enough work to require algorithms work daily (though, wouldn't you want to be doing this kind of work?) algorithms problems have a lot you have to do. Even if you don't use a linked list every day, designing a linked list and searching it isn't really different than designing a User class. The difference is it will take a few features of iterating on a User class before you bump into design issues where these will pop up right away.
And even though people complain about not being able to code without an IDE, frankly this is a red flag. I've seen candidates white board weird code (lots of semicolons, or no returns in python) that makes it pretty clear they don't write a lot of code.
Finally, white boarding algorithms questions are nice for interviewees because you can study one topic that will apply equally for multiple companies. Take home projects are great, but you have to do a unique one for each company. You can practice leetcode every night and you're preparing for a wide range of places all at once.
(1) We want to hire people who are able to solve programming-related problems. Now how do you find out if a candidate can do this? Looking at their CV doesn't tell you much. You can build up a long impressive CV without being able to program. So it would be nice to see them solve a problem right here and now.
Ideally, that would be a problem of the type you would often encounter in your actual work. But there are few programming-only problems in my work. And the hard ones are about designing a larger part of a system, or fitting something new into the context of something old, or trying to understand some old code to be able to adapt it.
My point is: All of these take a massive amount of context into account. Giving a candidate all that context would take weeks.
An algorithm challenge works because it has a good ratio of "time it takes to explain the problem" to "the problem is actually non-trivial to solve".
(2) We do these algorithm questions on a whiteboard, with one interviewer also standing and talking through the development of the solution with the candidate. I believe this gives me a sense of whether I can and want to work together with the candidate either on an actual whiteboard when sketching solutions to problems or when pairing.
It has a lot of false negatives, but companies like Google have so many candidates it doesn't matter.
I liken it to military push ups. Someone who can do a lot of them also has good enough physical strength to do all kinds of physical work.
Alternatively, you test if people can glue APIs together or really know web or mobile dev, but backend work really does need a level of algorithmic competency.
I was apart of the former half who hated algorithms until I was tasked with help hiring people. The only thing I believe that is worse than an algorithm is me spending 8+ hours of my free time on a "take home" problem. So, I used pretty easy to solve algorithms alongside real problems I had solved recently for interviews.
Being on the other side as the interviewer really made me see the value of algorithms. It becomes a medium where candidates can convey competency. I think it has gotten murky due to the lines between a web developer and software engineer blurring. That statement alone can be a can of worms.
Anyway, I would say algorithms / data structures for backend development do come up when laying the groundwork for a new project or something that might see a lot of traffic. Lots of things in development model certain data structures (queues, stacks, graphs, etc.) so knowing them allows you to converse with your co-workers and conceptualize them to others. Probably comes up somewhere between 2-5% of the time. Design patterns probably get brought more as their a bit more applicable for everyday tasks. It really depends on who you're around, how challenging the work is, and what the engineering culture is like.
I've failed these sort of interviews by suggesting I'd rather find a well tested library and use it than implement the algorithm on my own. What's the point really.
Bottlenecks matter. And the better you are at algorithms means the less rework that needs to happen.
If on the other hand you're doing day to day business logic, no, it does not make sense. 80% of all jobs are like this.
Some might be able to exclusively tackle tasks that don't require algorithmic knowledge, but this severely limits their options on what tasks they can pick up in a team.
I haven't worked with an incompetent developer that was an algorithm wiz. And I haven't encountered a developer who's skills I would envy that wouldn't have known a lot about algorithms.
Is using a whiteboard the best way to hire or even the best way to test these? I don't believe so.
But to go the extra step and claim just because perhaps in your line of work you don't use something daily it's useless? That's asinine. To make an obvious exaggeration: a pilot doesn't handle emergency landings on a daily basis, perhaps ever in their career, but if I was hiring a pilot to fly my plane you damn well know I'd try to find out whether that's a skill they possess.
Some algorithms I have written:
- List A and list B have common elements, go from A to B with a single insertion, deletion and reordering operation.
- You have two dates/times, get the number of working hours between the two, with business hours and holidays taken into account.
- Various forms of dependency management: we need to run an operation, that operation needs other operations to run first, themselves having their own requirements, etc...
- Decode a character string where each character is 6-bit wide.
- Have a set of data with different periods. Generate a schedule with a major/minor cycles. The algorithm has to understand things like 333ms = 1/3s.
- And many smaller things I don't remeber.
Most of the time, it fits in a single page, it is no big thing, I am not trying to prove P=NP here. Just that there isn't an already written library for every problem on earth. And even if there is, it may require a truckload of dependencies you'd rather avoid or it may not fit your particular problem without a lot of messing around. Or it might just be poorly written and unsupported, libraries are written by people with a wide range of resources and skill levels.
Algorithms are part of the job, if you don't know the basics, it will affect your productivity. I've seen people struggle for days on basic problems, hopelessly struggling with libraries. Or after great effort, come up with a broken solution that will need to be redone eventually.
Of course, algorithms are not the whole picture. But if a coder can't do it, there is at least one aspect of the job he lacks. And it turns out that it is easy to test for in an interview. Proper design is more important, but it is usually apparent only after thousands of lines have been written and requirements have changed several times, not something that is easy to test for.
Both soft + hard skills are mandatory. Hard skills are probably 33%-50% of the job, while working with people and being able to solve complex human problems in engineering is 50%-67% of the job.
Interview with algorithms or not — I don’t care. But don’t think for one second that an ability to write code is the only important part of being an engineer.
A bad developer will not implement properly the separation between infrastructure code and business code.
A bad developer does not care about readability, so the code will be laden with functions that have side effects, and things of that nature.
A bad developer does not comment their code in a meaningful way.
None of these are easy to find out in an interview. It turns out that questions about algorithms are good proxies to find people who are interested and proficient in computer science.
Sure you will miss some good developers that aren't good at algorithms, but there is a better chance that you do not hire bad candidates.
2. Making switching jobs harder