[HN Gopher] Algorithms Interviews: Theory vs. Practice (2020)
___________________________________________________________________
Algorithms Interviews: Theory vs. Practice (2020)
Author : Vadim_samokhin
Score : 47 points
Date : 2024-06-02 07:18 UTC (1 days ago)
(HTM) web link (danluu.com)
(TXT) w3m dump (danluu.com)
| seudito wrote:
| ,, Just for example, I once wrote a moderate length tutorial
| (4500 words, shorter than this post by word count, though
| probably longer if you add images) on how to find various
| inefficiencies..."
|
| Is there a public version of the tutorial?
| siscia wrote:
| 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 also the hidden characteristics (your call
| of it is an plus or a minus) to select for quite confident
| engineers that usually can talk and defend their opinion. Which
| is quite useful in big tech.
|
| For the reason why this does not get fixed.
|
| It is not because no-one looked. People in the team know. We all
| know.
|
| But we are being told not to focus on them.
|
| With scales comes cost of running the whole machinery AND
| opportunity cost of not having the next product launched. With
| the scale of big tech, the opportunity cost easily dominate the
| cost of 1% increase in performance.
|
| People don't realize it, but it is working well and as designed.
|
| It is wasteful? Absolutely.
|
| It makes a shit tons of money? Definitely!
| ilrwbwrkhv wrote:
| A simple better way of interviewing is to simply ask the
| candidate to code review a piece of code. Works much better
| than any algorithmic exercise and gives you the fastest results
| in the least time for both the company and the candidate.
|
| But most companies are cargo cults. For example Stripe copies
| Airbnb which in turn copies Google.
| latkin wrote:
| 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.
| dang wrote:
| Related:
|
| _Algorithms Interviews: Theory vs. Practice_ -
| https://news.ycombinator.com/item?id=39493689 - Feb 2024 (1
| comment)
|
| _Algorithms Interviews: Theory vs. Practice_ -
| https://news.ycombinator.com/item?id=28838769 - Oct 2021 (8
| comments)
|
| _Algorithms Interviews: Theory vs. Practice_ -
| https://news.ycombinator.com/item?id=21961174 - Jan 2020 (76
| comments)
| nijave wrote:
| 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
| vundercind wrote:
| - 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.
| johnea wrote:
| The main difference between theory and reality;
|
| is that in theory, theory and reality are the same;
|
| but in reality, they're not...
| gardenhedge wrote:
| I'd nearly be offended to get a hard question related to Bing
| since it sucks so much ass.
| fl0ki wrote:
| 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, 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.
|
| There's also a difference between "don't interview for algorithms
| at all" and "interview for algorithms but occasionally accept an
| engineer weak in them". In the former case you're unlikely to get
| lucky enough to end up with any engineers good in algorithms, in
| the latter case some engineers can help others with algorithms,
| hopefully in exchange for other relevant skills. In other words,
| it's worth interviewing to make sure certain mixes of skills end
| up on your teams, not necessarily as a hard cutoff on one skill
| that means you pass on other candidates with other skills.
| taeric wrote:
| 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 all data for
| something, but no obvious path on how to get just the relevant
| points for the algorithm in. 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.
| esafak wrote:
| But computational complexity is a separate concern from level
| of abstraction.
| saagarjha wrote:
| I'm curious for more details. I imagine this has to be more
| interesting than "Just write the double for loop." "No." "Ok
| I guess we're canceling this project."
| zerr wrote:
| 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.
| saagarjha wrote:
| 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.
| mathgradthrow wrote:
| "knowing how to do math", is roughly how one who does not
| know any math beyond the tricks describe above describes
| mathematics.
| saagarjha wrote:
| Sorry which tricks are you talking about?
| zerr wrote:
| 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".
| saagarjha wrote:
| I mean making your entire interview just algorithms is
| stupid, yes
| tester756 wrote:
| >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
| TrackerFF wrote:
| 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.
| jupp0r wrote:
| 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.
| kemiller wrote:
| 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.
| brcmthrowaway wrote:
| God the amount of kvetching about algorithms and data structure
| interviews.. is it still has bad as it was a few years ago?
|
| During COVID, every tom dick and harry thought they could be a
| coder.
| mattgreenrocks wrote:
| The goofy thing is that these questions feed back into dev
| culture and create a perception that people who've worked at a
| FAANG must be a god of programming.
|
| Call it what it is: your intellectual laziness in evaluating
| people and your own bias towards "winners."
|
| Regression to the mean is very real. I doubt an org of sufficient
| size can truly beat it, if only because not every employee can do
| well in every situation/project, regardless of their skill level.
| beryilma wrote:
| A standard CS master student's understanding of algorithms is
| very very bad. I wasn't necessarily any better at the time
| either; so I think ability to learn is more important than
| knowing algorithms fresh out of school.
|
| The level of algorithm skills I deal with in code reviews is to
| correct and explain the redundance of statements like
|
| bool variable = true...
|
| if (variable == true) ...
|
| So I don't dare expect a deep understanding of O notation and
| algorithm efficiency.
| roughly wrote:
| 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 passing
| your algorithms interview, it's not testing what you think it is.
| vundercind wrote:
| 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.
| gdsdfe wrote:
| You can take a picture on your phone and let chat-gpt (or
| whatever else llm) just solve it for you it whatever language
___________________________________________________________________
(page generated 2024-06-03 23:01 UTC)