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

31–40 of 69 posts

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

#31

Post by fpig »

Why is there so much complaining online about algorithmic questions? It’s really weird.

Surely there are way worse questions that companies ask.

Also, I stopped reading after his first argument which is incredibly stupid. He thinks the fact that he found inefficiencies in code at companies asking such questions proves something. The company I work for asks questions about testing yet we still have untested code. This is not strange, because outcomes depend on many things, not solely interview questions. It’s such an idiotic argument.

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

#32

Post by zerr »

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

To further clarify :) leetcode trivia & tricks != Algorithms/Computer Science.

Knowing the difference between arrays and linked lists is one thing, but knowing the puzzle tricks such as sliding windows, two pointers or some exotic DSs that are only used in such puzzles is another thing.

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

#33

Post by [deleted] »

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…

[deleted]

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

#34

Post by saagarjha »

zerr wrote: post #32
saagarjha wrote: post #29

Earlier quoted context omitted.

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

To further clarify :) leetcode trivia & tricks != Algorithms/Computer Science. Knowing the difference between arrays and linked lists is one thing, but knowing the puzzle tricks such as sliding windows, two pointers or some exotic DSs that are only used in such puzzles is another thing.

I think I mostly agree with this

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

#35

Post by Panzer04 »

As much as these sorts of questions get complained about, it occurs to me that they have their own convenient benefits if you take part in the system. Plenty of training resources, constrained problem space, etc. Want to get a tech job? Practice leetcode trivia for a couple of months. What's that next to 3-4 years of a uni degree?

If you really cared, it wouldn't be that hard to get good enough to deal with most of these "gotcha" algorithm questions.. (Partially giving myself a pep talk here :P)

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

#36

Post by dbcurtis »

nijave wrote: post #5

Meanwhile in real life it's mostly - better error handling (you don't want your batch to fail because 1 of 1 million items had an issue, usually) - sane retry/timeouts - fixing bad db queries

For some values of "real life". I don't mean that sarcastically... I mean that for many production environments (like customer-facing retail web site), I agree with you.

But that isn't the entire world. I've spent a lot of time doing hard realtime code. Often on limited-resource systems. (Oddly, its more difficult to get it right on resource-rich systems...) In the realtime world, it does require a certain amount of savvy to pick an optimal trade-off of run time, memory, and I/O. Hard realtime forces you to learn complexity analysis or die. You also have the luxury of a clear, bright benchmark for "good enough to ship", which shuts down a lot of purely philosophical arguments.

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

#37

Post by zarathustreal »

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…

Echoing my sibling commenters here, I’d love to hear more about this situation. Usually “inlining” and algorithmic complexity are juxtaposed as orthogonal types of optimization, with algorithmic optimization typically even being the reasoning for why the level of abstraction doesn’t matter very much. You typically get a much better speed up from going from O(n^2) to O(n) algorithms than from implementing e.g. Duff’s device, etc

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

#38

Post by jupp0r »

zerr wrote: post #13
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…

CP (Competitive Programming, Olympiad/leetcode puzzles) uses Computer Science (Algos & DS) the same way as e.g. Physics and Biology use Mathematics, i.e. it is a completely different discipline with its own trivia knowledge and tricks that has nothing to do with a software engineering.

It has been argued that programming in general has nothing to do with software engineering [1].

[1] https://www.oreilly.com/library/view/software-engineering-at...

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

#39

Post by darth_avocado »

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 think the answer to the age old problem of "do algorithmic interviews help" is: it depends.

Testing hard algorithms is probably not going to help in figuring out if someone is a good front end engineer who is only expected to build web or mobile apps. It will however be useful to identify if someone who's expected to regularly design system components, like say a cache layer for something, to actually understand the drawbacks of different caching strategies. Algorithms should be tested, but conditionally.

On the other hand, every engineer needs to know data structures and should be tested on them.

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

#40

Post by sopooneo »

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.

I would argue that, in practice, they are not completely separate. Too much abstraction makes it hard to tell what the underlying algorithm is. And even if you can figure that out, makes it hard to optimize.
Post reply on HN