Live data from Hacker News

Algorithms Interviews: Theory vs. Practice (2020)

danluu.com

21–30 of 69 posts

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

#21
post #13

Earlier quoted context omitted.

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.

Knowing how to do math is generally useful as a biologist or physicist. Sure there’s trivia or whatever but knowing how an array works is definitely important for software engineering, just like knowing how to do algebra is also important for biologists.

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

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

#22
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…

In the set of errors that cause production outages, inefficient algorithms is a pretty small subset though. I still think it can be a useful proxy for other things you might value in engineers though.

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

#23
Question based on some surprising-to-me chatter in a thread some weeks back about interviews:

When people claim that some shocking proportion of allegedly-accomplished candidates can’t write basic code to perform even a simple task on a whiteboard—do they mean pseudocode, or something akin to that? Or are they counting off points for getting actual syntax wrong?

Because I’ve been paid to write code for more than two decades but will reliably screw up syntax details on a language I wrote 200 lines of earlier that same day. Like I’ll use the wrong “elseif” (or is it elif? elsif? else if? God I don’t remember). Basic shit like that. I might well fail a fizzbuzz even, by those standards, unless asking some really dumb questions about the language won’t raise red flags.

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

#24
post #3

I read until the appendix but I find the intro wrong. From my experience big tech interviews are not for making sure that candidates don't write O(n^2) loops. Code reviews are for that, some of the times. Those interviews are there because we haven't figured out a better way to interview yet and this seems somehow correlated with the job. I don't think it is correlated, but it looks like it is! Those interviews have…

I usually find this author's posts pretty insightful, but this one was a miss for me. Just a rambling mishmash of ranting and humblebragging.

The main point (I think? Hard to extract a thesis from this one besides "algo interviews bad") doesn't even hold up: "People say algo interviews reduce costly algo issues in production, but these issues still happen in production, therefore algo interviews don't work/those people are wrong." This conclusion doesn't follow. Who's to say that there wouldn't be twice as many, or twice as severe, algo problems if companies didn't interview this way? I'm not asserting that's the case, but it's consistent with the data points provided.

Outside of official HR statements, perhaps, I don't think anybody pretends leetcode-style interviews are actually ideal for evaluating corporate software engineer candidates. Everyone knows they are deeply flawed and provided limited value. They persist because they seem to be the least worst option, all things considered.

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

#26
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

- cache more. Even if it’s kinda dumb caching.

- everything becomes stream processing when you really need performance and/or your dataset gets big enough.

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

#27
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…

The problem is that small organizations cargo cult large organization interviews, when for most small organizations (ones that are not building infrastructure for others) speed of delivery is vastly more important than algorithmic purity. Lots of n^2 and even 2^n algorithms are in fact perfectly reasonable in many contexts.

Even in large organizations, lots of people aren't touching the massively-scaled systems and are in fact just application developers.

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

#28
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…

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

In fact, the vast majority of fabled horror stories I've heard in the industry are seemingly just that...fabled.

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

#29
post #21

Earlier quoted context omitted.

Knowing how to do math is generally useful as a biologist or physicist. Sure there’s trivia or whatever but knowing how an array works is definitely important for software engineering, just like knowing how to do algebra is also important for biologists.

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

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

#30

Earlier quoted context omitted.

Knowing how to do math is generally useful as a biologist or physicist. Sure there’s trivia or whatever but knowing how an array works is definitely important for software engineering, just like knowing how to do algebra is also important for biologists.

"knowing how to do math", is roughly how one who does not know any math beyond the tricks describe above describes mathematics.

Sorry which tricks are you talking about?
Post reply on HN