Ask HN: What is the point of algorithm-heavy interviews? Who really cares about algorithm on daily bases. How often you solve algorithm-heavy tasks at work? |
Ask HN: What is the point of algorithm-heavy interviews? Who really cares about algorithm on daily bases. How often you solve algorithm-heavy tasks at work? |
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.
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.
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.
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.
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 would rather use a mechanic that has an underlying understanding of how a ICE works, rather than a tech that just plugs in a device and swaps parts.
I don’t need the mechanic to know how to fabricate an engine from scratch, but does have an understanding of what is under the hood.
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)
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.
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.
You're arguing a point they didn't make.
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.
> 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 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 :/
It's more about the company/interviewer ego than actually hiring someone who can provide value.
If one desires a job at a FAANG, it is fairly clear what ‘skills’ are expected to be demo’ed during the interview process.
It is as flawed as the SAT for college admission, but again, the individual knows what to focus on to maximize a successful outcome.
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 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).
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.
/s
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.
If anything interviews about the latest hip technology seem more prone to age selection to me.
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
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.
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.
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 :-(
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.
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 really struggle to see how regurgitating something someone's read/heard about something they didn't invent/modify conveys anything beyond memory.
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
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.
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 remains one of my favorite ancedotes: https://news.ycombinator.com/item?id=17106291
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.
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.
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.
But I do disagree with the statement I was replying to.
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.
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.
Marathon runners and sprint runners are both runners but they literally have completely different muscle structure.
So developers are judged by how well they do "sprint run" when they actually are supposed to be "marathon runners" on a daily basis.
Nice analogy!
Of course we're not talking about left-pad here, but implementing your own Diffie Hellman key exchange from scratch is usually a very bad idea.
How about the fact that "your stuff" is not algorithm. In 99% "your stuff" is to pick the right library
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!
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.
It's hard to have a logical rebuttal to something like this. It's engaging in the worst stereotypes.
I've replied to that comment above.