Algorithms Interviews: Theory vs. Practice (2020)
1–10 of 69 posts
Re: Algorithms Interviews: Theory vs. Practice (2020)
#2„ 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?
Re: Algorithms Interviews: Theory vs. Practice (2020)
#3I 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!
Re: Algorithms Interviews: Theory vs. Practice (2020)
#4Related:
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)
Re: Algorithms Interviews: Theory vs. Practice (2020)
#5Meanwhile 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
Re: Algorithms Interviews: Theory vs. Practice (2020)
#6The main difference between theory and reality;
is that in theory, theory and reality are the same;
but in reality, they're not...
Re: Algorithms Interviews: Theory vs. Practice (2020)
#7I'd nearly be offended to get a hard question related to Bing since it sucks so much ass.
Re: Algorithms Interviews: Theory vs. Practice (2020)
#8I 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…
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.
Re: Algorithms Interviews: Theory vs. Practice (2020)
#9I 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.
Re: Algorithms Interviews: Theory vs. Practice (2020)
#10I 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 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.