> Who really cares about algorithm on daily bases.
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.
This is like saying that a car mechanic needs to have a PhD in thermodynamics to work on internal combustion engines.
99.9% of coders just need to know what things in their chosen language(s) are performance sensitive and what aren't - very few actually need to know the exact reason why. And even fewer need to be able to improve on said algorithms.
If something needs sorting, you call the sort function in the object. There's absolutely no need to know what algorithm it uses, the only thing that matters is that the end result is sorted correctly.
It is far from saying that. At best it's more like saying a car mechanic should understand how a car works (e.g., how does an internal combustion engine work) even though most car mechanics spend 80% of their time changing oil, oil filters, and rotating tires. I think it is completely reasonable that a car mechanic should understand how a car works because without that knowledge how do they diagnose what is wrong?
My main issue with this topic is everyone seems to complain at the difficulty and ridiculousness of the process yet proposes no viable alternatives. No one likes the idea of take home projects/coding assignments. People write blog posts complaining that they shouldn't have to do side projects to give themselves a portfolio. So what is left? Just the resume? That doesn't seem fair to people coming out of school or career changers that have no experience - how do we evaluate them? We can't ask them anything related to CS.
Work sample. Do you spend any parts of your days writing syntax clean implementations of complex algorithms on a whiteboard with no access to references? Because no one I know has a job anything like that.
Knowing enough about various algorithms to suggest different ones and their trade-offs in a brainstorming session when presented with a (vague) problem is something that actually happens in some jobs. That part is fine to simulate in an interview if it’s an important part of a particular job.
What most software engineering interviews should have but don’t are sections on fixing bugs and adding features in existing codebases. These are the bread and butter of a lot of jobs. But that doesn’t allow for interviewer dick waiving, so it’s pretty rare.
You do not need to learn how to analyze algorithmic complexity from a theoretical point of view, which would be very math-heavy.
But a college/university-level mathematics / comp-sci course in algorithms & data structures, usually only a 3 credit, 200-level course, isn't really asking too much.
Then you'd know why your O(n^2) algorithm sucks on any dataset larger than a toy without having to be scolded.
There's 10,000 shades of gray between not knowing shit other than sort() and having a PhD. Use some common sense.
Then it would be fine if all these interviews asked was, "Why does this code with a O(n^2) algorithm suck?" People seem to have more of an issue when the interviews seem to blow right past that into leetcode hards.
> 99.9% of coders just need to know what things in their chosen language(s) are performance sensitive and what aren't - very few actually need to know the exact reason why.
Genuine question: How would you describe the performance properties of an algorithm in API docs without talking about e.g. logarithmic, linear or exponential growth? How could you understand these concepts of growth without knowing some basic algorithms that demonstrate them?
It's not like API docs can contain explanations like "be careful, this algorithm gets a little slower each time you add a new item and this other algorithm get super slower each time!".
> And even fewer need to be able to improve on said algorithms.
Nobody is talking about inventing a new sorting algorithm. I'm talking about being able to analyse the CPU + memory growth properties of a complete program you wrote yourself (which are algorithms...) and fixing bottlenecks by applying appropriate standard data structures and algorithms.
I can understand intent of your question. But as per my experience, very few fresh devs read manuals. They try to search something like 'how to sort in python/php/java blah blah'. Now this may or may not an ideal way but it works. Not all have to deal with scale like google. (getting 1000 customers is big deal itself).
Now if you're really smart mechanic and brave enough to face interesting challenges, you start building solutions with intution. After sometime, you slowly realize & accept gap between your knowledge and PhD. So you keep learning and improving yourself on the fly. I am not undermining importance of algorithm knowledge but many businesses need just working solution. They deal with scale when business scales. Just trying to answer your genuine question. Performance comes in consideration if only business demands.
Also on side note, asking engine designer to make hands dirty and fit screw (in given time - without manual) is not always good skill-test if HIS JOB NOT REQUIRES IT. This thing is easy for mechanic as he is doing it daily. Designer will somehow make it work but obviously she will take more time than mechanic. Now there are always exceptions but hope you get the gist.
As a programmer, I want my user to have the best experience possible using my software. Using a generic sort function may be the optimal solution for me, as a programmer for getting the job done quickly, but in some occasions, it delivers an experience which is far from optimal for my user.
Let's take the sort function as an example.
There are many problems for which the sort function far from the optimal solution. For example, sorting billion numbers, each in [1,10000]. (You could do it in O(n), instead of O(nlogn), for large data sets it is significant)
That what you would do if you knew such a solution exist, but cant recall the exact implementation.
In most cases, people who have no background in CS theory wouldn't even know such a solution exists and will resort to the generic "one-size-fits-all" solution
100% agree. In all my years of coding and other people I know you literally never need to implement an algorithm yourself or do anything that is already provided by a library/framework. Knowing alrogithms/data structures is only ever useful for interviews and nothing else. On daily basis you just make classes and basic CRUD operations and mostly design rather than any hardcore logic let alone algorithm... Interviews are unrealistic.
> 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.
There is a huge difference between knowing the fundamentals and having detailed knowledge about things you hardly use at the ready. For example, how often do you need to implement a sorting algorithm ? How often do you even have to make an informed decision on which one to use ? The one time you do, you can just look up the different options and their trade-offs. All you need to know is that these trade-offs exist, so you know that you have to look them up that one time when it matters.
> 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.
So have I, but that's the complete other end of the spectrum. You need a high-level understanding of these concepts, sure, but don't get bogged down in details when they don't matter.
Knowledge of these subjects also doesn't mean someone is a good programmer. I've worked with people who had very in-depth theoretical knowledge, but who I wouldn't let within 10 feet of any production code. Usually people with an academic background. They would write a beautifully optimised piece of code but forget to do any input checking, error handling, etc. They were more concerned with their pretty algorithm than with writing robust, production-ready code.
Also, writing the most efficient code isn't always desired. Code also has to be robust, readable and easy to maintain. In a lot of cases a slight performance improvements come at the cost of readability and maintainability.
> You need a high-level understanding of these concepts, sure, but don't get bogged down in details when they don't matter.
I think we agree then. I don't think understanding sorting algorithm is super important (usually you don't do much in terms of configuring or choosing these when coding), but people should have a high-level understanding of the differences between e.g. dictionary data structures as you need to know which trade-offs to pick when using these as part of a library.
The point they made is that most coders don't need to worry about algorithms on a daily basis, and that reflects poorly on them in interviews where they expect you to not-so-subtly fake your cleverness with "aha!" moments when you're being drilled on the fine details of complex algorithms that you maybe once needed to implement in the past 20 years. (On the rare occasion that these coders need to worry about algorithmic scaling, they will re-use an implementation from their fine standard library or adapt one from another source, without turning it into a brain exercise of reasoning about and building the whole algorithm from scratch on whiteboard while a bunch of strangers are sitting there judging and prompting you to explain your thought process as you go).
It's nothing to do with whether you have the fundamentals of basic algorithms down or whether you can select an appropriate algorithm for a real world problem.
> On the rare occasion that these coders need to worry about algorithmic scaling, they will re-use an implementation from their fine standard library or adapt one from another source, without turning it into a brain exercise of reasoning about and building the whole algorithm on scratch on whiteboard while a bunch of strangers are sitting there judging you and prompting you to explain your thought process as you go).
> It's nothing to do with whether you have the fundamentals of basic algorithms down or whether you can select an appropriate algorithm for a real world problem.
I never said they should be able e.g. code the algorithm from scratch on a whiteboard.
I'm saying you should be able to explain the basic principles of e.g. an array, a linked list, a hash table and a binary tree, and where each would be appropriate to use.
If you don't know these basic principles, I find it very unlikely you would know how to select library components or adapt algorithms that scaled to modest datasets.
> I'm saying you should be able to explain the basic principles of e.g. an array, a linked list, a hash table and a binary tree, and where each would be appropriate to use.
I think most of us agree with that. But that's beside the point, because that's not the algorithm-heavy interview people are complaining about big time.
It depends what you're describing as algorithm heavy. Do you have any examples?
I've seen people arguing you shouldn't have to know how a linked list, hash table or binary tree work. I think every programmer should know these ones. I think having to describe how quicksort works is getting too much, but knowing e.g. some search tree and graph algorithms might be appropriate depending on your domain.
I realized that everyone needs a base level of algorithms knowledge to write and design good software. Ideally it is pretty basic (leetcode easy), but the initial employees at FAANG companies decided to have a hazing ritual by creating increasingly complicated questions (e.g. leetcode hard) and it is exacerbated by a large number of kids from universities who mindlessly play this game. It spread to all other tech companies too and the process is just destructive.
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 :/
This is the real answer. There is a huge difference between base line knowledge of ds/algos and what is being expected of candidates (especially juniors!).
It's more about the company/interviewer ego than actually hiring someone who can provide value.
Since the rules are known, the threshold has increased so much that people don't see any issue when leetcode hard questions are common place.
I have seen multiple instances where the interview questions are ridiculous by any sane terms. It incentivizes gaming the system by just getting good at algorithms and not building up other skills.
Just as an example, look at Google as a new user (without any brand context). The design is terrible, the product management is terrible, the hideous search bar everytime you open the android home screen, etc. all in my opinion caused by optimizing for one attribute in 99% of the hires. It causes them to think "oh well the data says people don't mind the change", but you can't track the growing discontent of the customer base. And you are a monopoly so don't have to give a shit about UX anyways.
I've interviewed a lot of candidates (~200), and my interview generally looks like:
* 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).
I agree that ability to look things up is a major skill, but testing it reliably is difficult since it's so high variance.
So, no, I don't let people use reference materials including stack overflow. But I'll answer questions, and not judge them harshly for things that would easily be looked up.
> 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?").
First of all, Newsflash! that's illegal in a programming interview, please solve this question using a whiteboard instead, show a mathematical proof if needed.
To create a barrier to entry that weeds out over 90% of applicants.
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.
I'd just like to add that is easier to compare candidates using algorithm challenges (you can check if the candidate reached the optimal solution, how long it took and so on).
I dislike this kind of interviewing because you miss the chance of hiring people that are different from your regular hires, but hey the FAANGs are doing great so who am I to criticize.
> I'd just like to add that is easier to compare candidates
But you might just be comparing one's ability to feign smarts versus another's ability to work out a problem from first principles. Comparing apples to oranges might be easy but the results may or may not be that useful.
This is such BS. FAANG H1B salaries are the same as regular employees. You have no idea what you're talking about and clearly just form your opinion on hearsay.
I'm not American, so I'm not endorsing the same belief, but isn't the main criticism against the treatment of H1B visa holders related to workplace treatment (i.e. work longer hours/accept extra work or you're kicked out of the country) instead of pay?
This maybe true of Infosys or Wipro etc. This is not the case in FAANG companies. They get the same salaries in FAANG and are no different from regular employees. Don't let HN skew your world view. It's cool to be anti FAANG where as people posting these are living somewhere remote, salty about immigrants.
This is such a veiled racist attack. "immigrant devs" bad, "American good". You know nothing about FAANG salaries for H1Bs. They are on par if not more than regular devs.
We've asked you repeatedly not to break the site guidelines. You've continued to break them repeatedly. If you keep doing that we will ban you.
I'm sure you can correct misinformation and make your substantive points thoughtfully if you want to. Please use HN that way, not this way or like https://news.ycombinator.com/item?id=21459960.
Yes everyone is a web developer who would never need to learn about "algorithms". Anything that works against this HN crowd is obviously a big plot against them. Never mind that most people can't differentiate when a map is better over a list. Or why binary search is fast. Don't know how or when to use a graph. These people are one trick ponies and never tend to grow out of their comfort zones. They don't have the foundations to work on new and exciting projects. But obviously it's the companies fault for wanting someone with strong fundamentals.
I never said it was a problem. I have a CS degree so it doesn't hugely bother me. IMO, it's a necessary hurdle to ensure that you aren't swamped by thousands of candidates at every location.
With that being said, I would consider knowledge of DSA and the knowledge required for a FAANG level interview to be subtly different. There's a big difference in knowing how to implement basic data structures, sorting algorithms, and implementing BFS/DFS on a graph, and being able to dissect a LeetCode style coding problem and implement a solution that's good enough for a FAANG-tier company.
As far as people being one-trick ponies, I would disagree. They've simply specialised in a different aspect of software engineering, and just like how a Google engineer can learn to build a dynamic API wrapper with Ruby meta-programming and Rails, a Ruby engineer can learn dynamic programming and Dijkstra's algorithm.
I once read it is a form of ageism because older people, in general, don't have as much time as young people due to family to study for those interviews.
Absolutely no idea if that is true but I think it is an interesting thought.
but someone who is old would have studied this repeatedly if they applied to multiple interviews of the same kind, so they would have internalised knowledge. Also it's sort of timeless knowledge that you can acquire on the job.
If anything interviews about the latest hip technology seem more prone to age selection to me.
A new job every six months was not the pattern ten years ago. Also, back then you would have been asked why manhole covers are round instead of write a bug free implementation of A* on a whiteboard. Neither of those are timeless bits of knowledge that one acquires on any job, other than maybe job interview coach.
It is not true at all. I have a family where I am the one primarily taking care of the (very young) kids (wife works long hours) and I have a job. I find time to keep my skills sharp. If you take 15-30min a day, every day, you will have no problem with these interviews (granted, it will take some practice to get up and running initially).
It evaluates someone's capacity to approach a complex task
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 can assure you algos and data structures are a big part of systems software. Without these it's impossible to write efficient and correct code. It is these fundamentals that have made me easily switch profiles from VR to Self Driving to Cloud.
No one is asking you to write them yourself. But it is important to know when Quicksort becomes quadratic. Or when separate chaining in a hash table can lead to linear look ups. I find it abhorrent that this thread thinks these things are unimportant. Just use a "Library". How about you know your stuff .
That's very different from "algorithm-heavy interview" process.
You could just ask "do you know when quicksort becomes quadratic?"
> Just use a "Library".
Not just a library, a battle tested one.
A bad implementation of quicksort can be much worse than "accidentally quadratic" bad.
a good library could shuffle the array before sorting it and never be quadratic.
Or has hints about quadratic behaviour in the documentation.
A good library could automatically choose the best sort algorithm for the input.
For example Java used quicksort for primitive types and mergesort for arrays of objects.
now it uses trimsort for both.
But the developer just calls `sort` on the collection.
> How about you know your stuff .
I bet you never encountered quadratic quicksort in your life.
The probability that quicksort will use a quadratic number of compares when sorting a large array on your computer is much less than the probability that your computer will be struck by lightning!
It might be a complex task, but most often then not I personally think it's the wrong type of complexity.
Most of my day challenges are complex but not in an algorithmic way, they are about structuring code, making components interact etc... the complexity is in keeping a lot of things in mind and create something that is easy to maintain and work on.
If you understand data structures and algorithms then, in my view, it demonstrates that
1. You recognize the importance of understanding the principles and foundations of your field.
2. You understand that knowing the fundamentals isn't about "writing algorithms everyday", it's about growing your ability to think deeply and creatively about a problem without constantly flailing around in ignorance.
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.
People complain about algorithm heavy interviews a lot but I honestly think they're pretty useful for several reasons (some are beneficial to the person interviewing as well).
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.
> not being able to code without an IDE, frankly this is a red flag... that makes it pretty clear they don't write a lot of code
Muscle memory is real. Plus as a polyglot I find the context helpful for jogging my memory for how to do something in a particular language.
I had to google how to declare a variable in Go the other day, but I've written 10ks of lines. I'd had a break and was confused with Python. Oh well. I'd have failed on several of your whiteboard red flags.
Bar none, what I most want to see as an interviewer is someone's own code on GitHub. But I can count on one hand the number of times I've ever seen that after 10 years of hiring :-(
> Bar none, what I most want to see as an interviewer is someone's own code on GitHub. But I can count on one hand the number of times I've ever seen that after 10 years of hiring :-(
I would also love to see my own code on GitHub (well, perhaps another platform but anyway). Unfortunately having a full time job as a software developer leaves too little time & energy for my own projects, and work stuff at my current place will probably never land on GitHub. :-(
(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.
They make the interviewer feel really smart, since the interviewer already has the answer to his own question. Each interviewer should be required to go through the process himself (single blind) every six months. Bet you’d see a lot of no-offers.
Someone here once posted that they realize that it has little to do with work, but they don't have time to test work related things. Plus candidates hate coding challenges. So the algorithm is the closest to it.
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.
You could argue lifting 5 pounds running long distance demands a lot more energy than lifting 5 pounds and dropping it. And I'm sure they carry a lot more than 5 pounds of gear.
It correlates with programming ability, especially for more junior candidates. More senior candidates can show their skills via system design.
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 think the HN crowd goes 50/50 on this. One half hates it and the other believes it's a necessary evil. And then there's the small minority that enjoys it.
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.
Often the problem isn't phrased as "please implement algorithm X", but "solve this business related problem that requires use of algorithm X". The expected answer is the same, though...you're supposed to implement algorithm X.
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.
Most people care for algorithms in some capacity in their day jobs.
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.
I don't write algorithms on a daily basis, but is does account for a significant fraction of my work time.
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.
There are pros and cons. Interviews are inherently imperfect. I’ve interviewed people who can do a bubble sort algorithm off the top of the heads, but cannot figure out how to use GitHub to save their lives. I’ve interviewed people who write great code, but can’t articulate their ideas well enough to sell them to management.
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.
Algorithmic interviews test for intelligence. Everyone prefers more intelligent and capable developers. At the end of the day an interview is a competition; the job goes not to any qualified candidate, but the best qualified.
The question is: what mistake should the developer not do?
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.
Most people who are hired will have recently graduated, due to the exponential growth of software developers. These interviews are really just an examination question, like you would do in school. Companies use them because they can easily show whether a person can retain and then apply knowledge of computer science. And must companies do not know how to test candidates otherwise.
You mean they’re trying to hire people stupid enough to work for them by putting them through things like take home projects, group, and multi-round interviews?
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.