6 ms·

Ask HN: What is the point of algorithm-heavy interviews?

53 points by groomed 7y ago

Who really cares about algorithm on daily bases. How often you solve algorithm-heavy tasks at work?

skyzyx 7y ago
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.
muzani 7y ago
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.
- caseymarquis 7y ago
  Except most people are trying to hire distance runners who will be lifting at most 5 pounds (~2.5kg).
  - ratsimihah 7y ago
    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.
    - gotts 7y ago
      I believe what caseymarquis meant is not the amount of energy throughput but the kind of activity. 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.
      - ratsimihah 7y ago
        Oh thanks for putting me back on track (get it get it?) Nice analogy!
throwaway_009 7y ago
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 :/
- dillonmckay 7y ago
  The rules of the game seem to be well-known at this point. 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.
  - throwaway_009 7y ago
    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.
- protonimitate 7y ago
  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.
mister_hn 7y ago
To cut older people from fresh graduates and then offer fresh graduates lower wages.
iM8t 7y ago
Not all interviews are algo-heavy. I recently interviewed for a position in AWS and the challenge was a simple floodfill argo (leetcode easy).
- dillonmckay 7y ago
  Did you get an offer?
  - iM8t 7y ago
    Yes. :)
patatino 7y ago
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.
- riffraff 7y ago
  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.
  - bradleyjg 7y ago
    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.
    - abraCadabstrax 7y ago
      Is it to keep the cover from falling in the hole?
- steev 7y ago
  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).
nprateem 7y ago
To waste your time. > 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?").
- kgraves 7y ago
  > let me check on Google... 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
- booleandilemma 7y ago
  I have a coworker at my job who specifically asks questions he finds through googling “google interview questions”.
zerr 7y ago
1. Ageism (prefer early 20s) 2. Making switching jobs harder
- amadeuspagel 7y ago
  Why exactly should a company make switching jobs to them harder, for the benefit of their competitors?
  - groomed 7y ago
    When big companies agree, and all play the same game.- They can save money and time.
- mav3rick 7y ago
  It's all a conspiracy. Or maybe a CS job that pays millions should require CS fundamentals.
amadeuspagel 7y ago
It might work as an intelligence test.
- booleandilemma 7y ago
  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?
11235813213455 7y ago
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
- stevefan1999 7y ago
  oh, fibonacci numbers, why do i take 10 seconds to figure it out
- groomed 7y ago
  The problem is that knowledge needed for exams is needed for exams only, and does not correlate with your overall expertise.
  - mav3rick 7y ago
    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.
    - walterstucco666 7y ago
      I think it is often much better not to write them yourself, but rely on a battle tested implementation. 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.
      - mav3rick 7y ago
        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 .
seanwilson 7y ago
> 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.
- theshrike79 7y ago
  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.
  - caspper69 7y ago
    No, it's not. 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.
gaogao 7y ago
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.
EnderMB 7y ago
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.
- mav3rick 7y ago
  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.
  - EnderMB 7y ago
    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.
mgaw 7y ago
For me there are two reasons: (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.
- rimliu 7y ago
  I think you are mistaking a programming-related problem for a CS-related problem.
  - mgaw 7y ago
    Hm I would say writing an algorithm is both programming-related and CS-related.
jefftk 7y ago
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).
- booleandilemma 7y ago
  Am I allowed to check stackoverflow during your interview process?
  - jefftk 7y ago
    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.
d--b 7y ago
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.
- groomed 7y ago
  You mentioned all three things that algo-strong dev will also do. Because there is no correlation
t-h-e-chief 7y ago
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.
onion2k 7y ago
Algorithms in interviews happen when people who enjoy writing algorithms get promoted to positions responsible for hiring.
Snoozus 7y ago
They're really useful if you are looking for someone to do algorithm-heavy work. Also to check if someone actually has the CS background they claim.
bradleyjg 7y ago
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.
inertiatic 7y ago
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.
LandR 7y ago
You realise that not everyone is a web developer?
baron_harkonnen 7y ago
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.
- nprateem 7y ago
  > 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 :-(
  - clarry 7y ago
    > 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. :-(
majky538 7y ago
Think twice before getting hired. Some companies are like nice looking Instagram profile, but behind the scene it just sucks.
olingern 7y ago
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.
- nprateem 7y ago
  > It becomes a medium where candidates can convey competency I really struggle to see how regurgitating something someone's read/heard about something they didn't invent/modify conveys anything beyond memory.
gorbachev 7y ago
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.
GuB-42 7y ago
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.
new_realist 7y ago
Algorithmic interviews test for intelligence. Everyone prefers more intelligent and capable developers.
new_realist 7y ago
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.
bb88 7y ago
For FAANG and other companies with large data: Yes. For solving actual scaling issues, it makes sense for any candidate to understand this stuff. 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.
cyberprunes 7y ago
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.
croh 7y ago
Do you know Goodhart's law ? https://coffeeandjunk.com/goodharts-campbells-law/ https://coffeeandjunk.com/goodharts-campbells-law/ Software engineering is craft and there are many metrices. But sadly people focus heavily on algorithm/ds only.
SamReidHughes 7y ago
There isn't anybody who can make good software architecture who isn't also good at data structures / algorithms.

53 points by groomed 7y ago

Who really cares about algorithm on daily bases. How often you solve algorithm-heavy tasks at work?

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.

muzani 7y ago

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.

caseymarquis 7y ago
Except most people are trying to hire distance runners who will be lifting at most 5 pounds (~2.5kg).
- ratsimihah 7y ago
  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.
  - gotts 7y ago
    I believe what caseymarquis meant is not the amount of energy throughput but the kind of activity. 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.
    - ratsimihah 7y ago
      Oh thanks for putting me back on track (get it get it?) Nice analogy!

throwaway_009 7y ago

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 :/

dillonmckay 7y ago
The rules of the game seem to be well-known at this point. 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.
- throwaway_009 7y ago
  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.
protonimitate 7y ago
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.

mister_hn 7y ago

To cut older people from fresh graduates and then offer fresh graduates lower wages.

iM8t 7y ago

Not all interviews are algo-heavy. I recently interviewed for a position in AWS and the challenge was a simple floodfill argo (leetcode easy).

dillonmckay 7y ago
Did you get an offer?
- iM8t 7y ago
  Yes. :)

patatino 7y ago

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.

riffraff 7y ago
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.
- bradleyjg 7y ago
  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.
  - abraCadabstrax 7y ago
    Is it to keep the cover from falling in the hole?
steev 7y ago
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).

nprateem 7y ago

To waste your time. > 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?").

kgraves 7y ago
> let me check on Google... 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
booleandilemma 7y ago
I have a coworker at my job who specifically asks questions he finds through googling “google interview questions”.

zerr 7y ago

1. Ageism (prefer early 20s) 2. Making switching jobs harder

amadeuspagel 7y ago
Why exactly should a company make switching jobs to them harder, for the benefit of their competitors?
- groomed 7y ago
  When big companies agree, and all play the same game.- They can save money and time.
mav3rick 7y ago
It's all a conspiracy. Or maybe a CS job that pays millions should require CS fundamentals.

amadeuspagel 7y ago

It might work as an intelligence test.

booleandilemma 7y ago
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?

11235813213455 7y ago

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

stevefan1999 7y ago
oh, fibonacci numbers, why do i take 10 seconds to figure it out
groomed 7y ago
The problem is that knowledge needed for exams is needed for exams only, and does not correlate with your overall expertise.
- mav3rick 7y ago
  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.
  - walterstucco666 7y ago
    I think it is often much better not to write them yourself, but rely on a battle tested implementation. 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.
    - mav3rick 7y ago
      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 .

seanwilson 7y ago

> 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.

theshrike79 7y ago
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.
- caspper69 7y ago
  No, it's not. 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.

gaogao 7y ago

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.

EnderMB 7y ago

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.

mav3rick 7y ago
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.
- EnderMB 7y ago
  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.

mgaw 7y ago

For me there are two reasons: (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.

rimliu 7y ago
I think you are mistaking a programming-related problem for a CS-related problem.
- mgaw 7y ago
  Hm I would say writing an algorithm is both programming-related and CS-related.

jefftk 7y ago

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).

booleandilemma 7y ago
Am I allowed to check stackoverflow during your interview process?
- jefftk 7y ago
  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.

d--b 7y ago

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.

groomed 7y ago
You mentioned all three things that algo-strong dev will also do. Because there is no correlation

t-h-e-chief 7y ago

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.

onion2k 7y ago

Algorithms in interviews happen when people who enjoy writing algorithms get promoted to positions responsible for hiring.

Snoozus 7y ago

They're really useful if you are looking for someone to do algorithm-heavy work. Also to check if someone actually has the CS background they claim.

bradleyjg 7y ago

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.

inertiatic 7y ago

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.

LandR 7y ago

You realise that not everyone is a web developer?

baron_harkonnen 7y ago

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.

nprateem 7y ago
> 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 :-(
- clarry 7y ago
  > 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. :-(

majky538 7y ago

Think twice before getting hired. Some companies are like nice looking Instagram profile, but behind the scene it just sucks.

olingern 7y ago

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.

nprateem 7y ago
> It becomes a medium where candidates can convey competency I really struggle to see how regurgitating something someone's read/heard about something they didn't invent/modify conveys anything beyond memory.

gorbachev 7y ago

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.

GuB-42 7y ago

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.

new_realist 7y ago

Algorithmic interviews test for intelligence. Everyone prefers more intelligent and capable developers.

new_realist 7y ago

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.

bb88 7y ago

For FAANG and other companies with large data: Yes. For solving actual scaling issues, it makes sense for any candidate to understand this stuff. 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.

cyberprunes 7y ago

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.

croh 7y ago

Do you know Goodhart's law ? https://coffeeandjunk.com/goodharts-campbells-law/ https://coffeeandjunk.com/goodharts-campbells-law/ Software engineering is craft and there are many metrices. But sadly people focus heavily on algorithm/ds only.

SamReidHughes 7y ago

There isn't anybody who can make good software architecture who isn't also good at data structures / algorithms.