Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Algorithms Interviews: Theory vs. Practice (2020)

danluu.com

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Algorithms Interviews: Theory vs. Practice (2020)

#51

Post by chipdart »

fl0ki wrote: post #9

I have definitely seen senior developers put quadratic and even exponential algorithms into production and cause global outages. Code review didn't help, because their code was reviewed by other people who were interviewed to the same low standard. I continue to insist on algorithm & data structure interviews for software engineer candidates. Not every project needs them as much, but in large enough institutions, eve…

> I continue to insist on algorithm & data structure interviews for software engineer candidates. Not every project needs them as much, but in large enough institutions, every engineer is likely to run into at least one project that does. If they can't figure it out and can't get help from someone who can, their weak solution can easily cost the company and its other engineers far more than it would have cost to interview engineers properly and compensate the fewer qualified engineers commensurately.

I strongly disagree with this assertion. Using algorithms&data structures trivia in interviews means you will reject candidates who might happen to fail a inane trivia question in spite of otherwise being perfect fits and the ideal candidate.

Imposing trivia on algorithms&data structures as a requirement communicates the idea that you don't believe anyone, including the ideal candidate, is unable to learn and develop this skill while working at your organization. This is telling regarding the bar which is set at your organization to nurture development in this skill set.

If your org is indeed large, odds are you can find a subject matter expert within your ranks, which means it's utterly pointless to expect your engineers must be able to come up with perfectly optimal solutions on their own. They are a Slack message away from that.

The biggest blindspot you convey in your post is the ladder-pulling aspect of data structures & algorithms in today's recruitment process. Subpar engineers use it to depict themselves as competent or raising the bar within their organization by coming up with obscure puzzles that bear absolutely no relationship to the job they are hiring for. They spend days hand-picking a problem for which they have a solution to, they go over the problem as many times as they need, they proceed to grill candidates on this trivia, they make their hire/no hire decision on the 20minute performance a candidate has after being presented with a riddle, and then go back to not have to face that issue ever again in any production setting.

The worst offenders are interviewers who pull this stunt in spite of they themselves completely failing to understand their own problem.

Re: Algorithms Interviews: Theory vs. Practice (2020)

#52

Post by chipdart »

esafak wrote: post #14
taeric wrote: post #10

Earlier quoted context omitted.

Annoying counterpoint, of course, I've seen senior developers also stall out on avoiding quadratic code to the point that they didn't get the code delivered and then the project got scrapped. The most widespread failure I have seen, by far, is to write code that is so abstracted out that it isn't really clear on how to get the necessary parts inline to get at efficient code. You'll have an obvious path on how to load…

But computational complexity is a separate concern from level of abstraction.

> But computational complexity is a separate concern from level of abstraction.

It really depends. Abstractions can and often do to otherwise avoidable copies. It's pointless to argue about computational complexity of an algorithm if you don't even notice that an abstraction you're using is adding a performance penalty in the form of running a linear-time algorithm in the hot path, and is even preventing the runtime from optimizing away problematic code.

Re: Algorithms Interviews: Theory vs. Practice (2020)

#53

Post by chipdart »

taeric wrote: post #10
fl0ki wrote: post #9

I have definitely seen senior developers put quadratic and even exponential algorithms into production and cause global outages. Code review didn't help, because their code was reviewed by other people who were interviewed to the same low standard. I continue to insist on algorithm & data structure interviews for software engineer candidates. Not every project needs them as much, but in large enough institutions, eve…

Annoying counterpoint, of course, I've seen senior developers also stall out on avoiding quadratic code to the point that they didn't get the code delivered and then the project got scrapped. The most widespread failure I have seen, by far, is to write code that is so abstracted out that it isn't really clear on how to get the necessary parts inline to get at efficient code. You'll have an obvious path on how to load…

> This is super hilarious for code paths that try and hide network hits, such that you don't see that that loop is doing a network call per iteration.

True story: once I worked on a C++ project with a very ambitious junior developer who liked to portray himself as the local authority in performance and code quality. That junior developer once blocked a PR alleging performance problems because a function call was passing strings by value instead of moving them. Except that function call was only called once per run, and its responsibility was to make 1+n calls to a REST service.

Whenever anyone complains about performance, ask for benchmarks. Odds are, even if they are technically right they are still wrong.

Re: Algorithms Interviews: Theory vs. Practice (2020)

#54

Post by chipdart »

TrackerFF wrote: post #28
tester756 wrote: post #16

Earlier quoted context omitted.

>their weak solution can easily cost the company and its other engineers far more than it would have cost to interview engineers properly and compensate the fewer qualified engineers commensurately. Anything that supports this? Because I don't believe it at all The only thing that I can think of that could cost company a lot is data corruption / database being destroyed Unless it is very specific case like HFT

That is pretty much my stance, too. I've seen a lot of critical fuckups in my years, but I have yet to see someone fuck up everything by using a woefully unsuitable algorithm. That, of course, does not mean that it doesn't happen - could very well be the case at the type of companies I haven't worked for, where performance is absolutely critical...but I have a hard time believing those places don't have safety guards…

> I've seen a lot of critical fuckups in my years, but I have yet to see someone fuck up everything by using a woefully unsuitable algorithm.

This bears repeating. With the exception of very niche applications, such as AAA games and scientific computing, the only realistic impact of picking a sub-optimal algorithm is slightly higher CPU utilization rates and background tasks taking a bit longer to finish.

This means the outcome of all this song and dance amounts at month to a few dollars per month.

Knuth mentioned something about premature optimization.

Re: Algorithms Interviews: Theory vs. Practice (2020)

#55

Post by chipdart »

BeetleB wrote: post #43
fl0ki wrote: post #9

I have definitely seen senior developers put quadratic and even exponential algorithms into production and cause global outages. Code review didn't help, because their code was reviewed by other people who were interviewed to the same low standard. I continue to insist on algorithm & data structure interviews for software engineer candidates. Not every project needs them as much, but in large enough institutions, eve…

> Not every project needs them as much, but in large enough institutions, every engineer is likely to run into at least one project that does. If they can't figure it out and can't get help from someone who can, their weak solution can easily cost the company and its other engineers far more than it would have cost to interview engineers properly and compensate the fewer qualified engineers commensurately. I worked a…

> I think you're subject to survivorship bias.

I think some people have a trick, and they desperately try to upsell their trick in order to subtly overstate the importance of their skillset. It's very hard to get anyone to be honest about the importance of their contributions when their livelihood depends on it.

Re: Algorithms Interviews: Theory vs. Practice (2020)

#56

Post by chipdart »

saagarjha wrote: post #29
zerr wrote: post #21

Earlier quoted context omitted.

My point is that just because Math is useful for both physicists and biologists, that does not mean that for a physicist position you should interview the candidate (a physicist) in Biology. Biology "is a completely different discipline with its own trivia knowledge and tricks".

I mean making your entire interview just algorithms is stupid, yes

> I mean making your entire interview just algorithms is stupid, yes

That's what recruiters do when they use leetcode-type problems as their first interview to filter out the bulk of their applicantions.

Re: Algorithms Interviews: Theory vs. Practice (2020)

#57

Post by chipdart »

BeetleB wrote: post #45
roughly wrote: post #19

If you don’t know Dan or haven’t read enough of his work to get this, > I can't pass algorithms interviews! When I say that, people often think I mean that I fail half my interviews or something. It's more than half. is insane. Dan’s day job is (or was, on the occasions that I’ve worked with him) to identify and solve the weirdest, gnarliest scaling and performance bugs in extremely large systems. If Dan isn’t passin…

> If Dan isn’t passing your algorithms interview, it’s not testing what you think it is. I think it's also much easier to see/solve problems in practice than on a theoretical whiteboard. I've rarely had to use Leetcode level algorithms at work. But when I did, it was much easier to solve than if I'd been given the exact same problem without the context of the experience I'd accumulated working on the project. Example…

> I quickly realized that the map had a high overhead - all those pointers in a red-black tree consume more RAM than my data!

That is true if you use std::map , which should only be used if you have a strong requirement in having sorted keys.

If you do not have a requirement to keep sorted keys, you should use std::unordered_map which internally implements a dictionary as a hash table, exactly as std::unordered_set.

> As I was storing only once and doing lookups many times, it was simpler to simply sort all the keys, and then store the values. When I needed to do a lookup, I'd do a binary search and find it. Algorithmically same complexity as a map.

If you used std::unordered_map instead, you would be doing the same thing with a constant-time computational complexity instead of logarithmic, while retaining linear space complexity.

Re: Algorithms Interviews: Theory vs. Practice (2020)

#58

Post by TrackerFF »

fl0ki wrote: post #42
TrackerFF wrote: post #28

Earlier quoted context omitted.

That is pretty much my stance, too. I've seen a lot of critical fuckups in my years, but I have yet to see someone fuck up everything by using a woefully unsuitable algorithm. That, of course, does not mean that it doesn't happen - could very well be the case at the type of companies I haven't worked for, where performance is absolutely critical...but I have a hard time believing those places don't have safety guards…

I agree at the level of source code, but sometimes algorithm skills affect the whole architecture. Even simple things like where certain data and logic would optimally exist can have cascading and compounding consequences for the whole rest of the system. To see better solutions, you have to know what's possible with algorithms and data structures. To give a contrived example that I think should make sense no matter…

Yes, I absolutely buy the argument that doing things the optimal way will make a difference at scale.

When some method is being called, or some data structure is being used, trillions or quadrillions of times (all the users of facebook/tiktok/etc. clicking on something / using a feature) - even small optimizations can add up quickly, which can obviously mean more compute or storage.

But I do not believe that you will find a single point of failure for those cases. In fact, no single person should be able to create such failures. And at companies that operate at such scale, there are many, many safety measures put up - not to mention the continuous performance analysis and reviews.

Re: Algorithms Interviews: Theory vs. Practice (2020)

#59

Post by GuB-42 »

In my experience, good developers have some algorithmic skills, this is a correlation, not necessarily causation. That is, they are not good because they know algorithms, but when you are a developer, you necessarily work with algorithms, even when your job rarely requires you to write them. If you don't know, it means you may not understand what you are working with or even worse, be unwilling to. Programming is a field where being willing to learn is important, as things move fast (at least on the surface) and every job is different.

So I think it kind of work as a filter. It is not perfect, other signals are needed, in particular, as the article says, the interview format may be a problem, but recruiters need something to test. And algorithms have the advantage of being relevant to the job (unlike logic puzzles), hard to bullshit (unlike experience), fair (unlike personal situation), and not too time consuming (unlike assignments).

Re: Algorithms Interviews: Theory vs. Practice (2020)

#60

Post by TrackerFF »

roughly wrote: post #19

If you don’t know Dan or haven’t read enough of his work to get this, > I can't pass algorithms interviews! When I say that, people often think I mean that I fail half my interviews or something. It's more than half. is insane. Dan’s day job is (or was, on the occasions that I’ve worked with him) to identify and solve the weirdest, gnarliest scaling and performance bugs in extremely large systems. If Dan isn’t passin…

In my experience, algorithmic interviews work great for people that

A) Are deeply interested in the topic. If you dabble in competitive programming, then these interviews should be a breeze.

B) Young people out of college, with a fresh memory of data structures and algorithms classes.

C) High IQ individuals. This one might be controversial, but I've met plenty of people that were just intellectually sharp enough to deduce the solutions, without having touched the material in 10 year, nor have been "grinding" LeetCode. But even these folks might not get through, if they haven't practiced - as you also have to solve the problems quick enough.

D) Those that are willing to grind LeetCode for months and months, and dedicate all their time to such prep.

One common trait has also been the ability to work under pressure / stress. If you're a good test-taker, you have an advantage. If tests make you anxious, that could be enough to derail your performance.

I don't remember which company that did the internal study, but they found that women fared worse at whiteboard interviews due to higher rates of anxiety and lower self-confidence, compared to guys - even though they were equals as far as technical knowledge and work performance goes.

Post reply on HN