7 ms·

Algorithms Interviews: Theory vs. Practice (2020)

seudito 2y ago
„ 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 2y ago
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 2y ago
  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 2y ago
  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 2y ago
Related: Algorithms Interviews: Theory vs. Practice - https://news.ycombinator.com/item?id=39493689 https://news.ycombinator.com/item?id=39493689 - Feb 2024 (1 comment) Algorithms Interviews: Theory vs. Practice - https://news.ycombinator.com/item?id=28838769 https://news.ycombinator.com/item?id=28838769 - Oct 2021 (8 comments) Algorithms Interviews: Theory vs. Practice - https://news.ycombinator.com/item?id=21961174 https://news.ycombinator.com/item?id=21961174 - Jan 2020 (76 comments)
nijave 2y ago
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 2y ago
  - 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.
- dbcurtis 2y ago
  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.
- hot_gril 2y ago
  I prefer to ask questions that are easier on the algorithm side and have time to see how well the interviewee covers edge cases, handles errors, shows me that it works, and writes tests. Our company's work is more about reliability than efficiency.
johnea 2y ago
The main difference between theory and reality; is that in theory, theory and reality are the same; but in reality, they're not...
gardenhedge 2y ago
I'd nearly be offended to get a hard question related to Bing since it sucks so much ass.
fl0ki 2y ago
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 2y ago
  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 2y ago
    But computational complexity is a separate concern from level of abstraction.
    - 2y ago
brcmthrowaway 2y ago
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 2y ago
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.
- nine_zeros 2y ago
  It absolutely is intellectual laziness. There is zero attempt by hiring management to improve their own quality. They use bottom of the barrel practices for hiring (such as leetcode), practices for collaboration (stack ranking), for distribution of rewards (skimping on existing employees in favor of hiring more headcount), and generally incapable of creating and sharing solid visions and giving people the resources to get them to fruition (Sitting back after OKRs are decided out of thin air, never truly explaining why something is important and never really supporting their reports to achieve those goals).
beryilma 2y ago
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 2y ago
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.
- BeetleB 2y ago
  > 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 wrote a C++ program that stored a large number of 32 bit numbers[1] in a map (both key and value were 32 bits). When I ran the program, it ran out of memory (something like 80GB of RAM). I quickly realized that the map had a high overhead - all those pointers in a red-black tree consume more RAM than my data! 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 someone gave me this problem as a whiteboard, I'd implement the map based solution, and would really struggle if I started getting questions about memory performance, and it would be silly to ding me for not choosing a binary search. In reality, my screwup was extremely simple to solve - given that I had a good understanding of the problem domain - something lacking in a whiteboard interview. So in general, people who do poorly in those whiteboard interviews may well solve the exact same problem with ease in an actual work situation. Another example: I wrote a DAG and needed to check if two (arbitrary) nodes were connected. I chose a fairly inefficient algorithm - recursive backtracking with no memoization. If I've already computed that B is connected to C, and I know A is connected to B, I don't need to run the whole algorithm to know that A is connected to C. I wrote the simple, inefficient version, knowing it was a poor algorithm. But my reasoning was that I wanted to write all my tests with corner cases working before I fixed the performance. Once I had all the tests written, I returned to optimize the algorithm. Then I said "Heck, let's see how bad it is with real world data." The algorithm was fast. Even when I significantly increased N. How come? Oh, it's because due to real world limitations in the problem I was solving, the maximum distance between any 2 nodes I was comparing was 7. Yes, in the abstract, it seemed very inefficient, but when you apply real world limitations, you realize there is nothing to gain by making it more efficient. Leetcode biased folks would have made the code more complex for little gain. [1] Maybe it was 64 bit - I forget.
vundercind 2y ago
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.
- lesuorac 2y ago
  Plenty of candidates can't figure how to use a for-loop to iterate over input or even how to handle nested data (Trees). If you're biggest worry about leetcode is does this language need a semi-colon at the end then I doubt you have trouble interviewing. --- Do you do much interviewing as an interviewer?
  - vundercind 2y ago
    I have in past roles. We never leetcoded anyone where I’ve been an interviewer. One place where I guided it my approach was to attempt to learn something from the candidate—this not-infrequently led to my being the only person (they claimed) to have ever e.g. engaged them in a conversation about a paper they authored and listed on their résumé. Which, wtf, how do you not get curious enough to skim that before the interview and ask a couple non-stupid questions about it? I don’t exactly have a dataset (who does? A few Bigcos but most interviewers are working with tea-leaves and guesses) but I really liked the “try to learn something” approach and would use it again. It helps that I don’t know much so it’s pretty easy for me to find something I don’t know that the candidate can teach me about, I suppose—maybe this doesn’t work so well for people who know a lot and also aren’t good at faking not-knowing things.
- lelandfe 2y ago
  Just one example, but I was failed on a technical I took recently. It had a runtime, so not a whiteboard. But the editor I had to use provided no checking and I only found out after minutes of work that debugger breakpoints were not supported (the interviewer had not used them before) So I failed the technical as I had to spend like a substantial amount of a 45m session console logging out values and experimenting as I went. It turned out I missed a few characters in my code. I was pretty beside myself.
gdsdfe 2y ago
You can take a picture on your phone and let chat-gpt (or whatever else llm) just solve it for you it whatever language
fpig 2y ago
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.
Panzer04 2y ago
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)
hot_gril 2y ago
I wrote an HN submission somewhere about the biases I've seen in algo interviews. One thing is they love questions that can be solved with some small twist on BFS or DFS, usually one that's a lot easier if you're doing it non-recursively. I've gone through entire multi-round interviews like that.
- kbob 2y ago
  Breadth-First Search or Depth-First Search, I think. It took me too long to guess those initialisms.
GuB-42 2y ago
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).

„ 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 2y ago

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 2y ago
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 2y ago
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 2y ago

Related: Algorithms Interviews: Theory vs. Practice - https://news.ycombinator.com/item?id=39493689 https://news.ycombinator.com/item?id=39493689 - Feb 2024 (1 comment) Algorithms Interviews: Theory vs. Practice - https://news.ycombinator.com/item?id=28838769 https://news.ycombinator.com/item?id=28838769 - Oct 2021 (8 comments) Algorithms Interviews: Theory vs. Practice - https://news.ycombinator.com/item?id=21961174 https://news.ycombinator.com/item?id=21961174 - Jan 2020 (76 comments)

nijave 2y ago

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 2y ago
- 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.
dbcurtis 2y ago
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.
hot_gril 2y ago
I prefer to ask questions that are easier on the algorithm side and have time to see how well the interviewee covers edge cases, handles errors, shows me that it works, and writes tests. Our company's work is more about reliability than efficiency.

johnea 2y ago

The main difference between theory and reality; is that in theory, theory and reality are the same; but in reality, they're not...

gardenhedge 2y ago

I'd nearly be offended to get a hard question related to Bing since it sucks so much ass.

fl0ki 2y ago

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 2y ago
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 2y ago
  But computational complexity is a separate concern from level of abstraction.
  - 2y ago

brcmthrowaway 2y ago

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 2y ago

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.

nine_zeros 2y ago
It absolutely is intellectual laziness. There is zero attempt by hiring management to improve their own quality. They use bottom of the barrel practices for hiring (such as leetcode), practices for collaboration (stack ranking), for distribution of rewards (skimping on existing employees in favor of hiring more headcount), and generally incapable of creating and sharing solid visions and giving people the resources to get them to fruition (Sitting back after OKRs are decided out of thin air, never truly explaining why something is important and never really supporting their reports to achieve those goals).

beryilma 2y ago

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 2y ago

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.

BeetleB 2y ago
> 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 wrote a C++ program that stored a large number of 32 bit numbers[1] in a map (both key and value were 32 bits). When I ran the program, it ran out of memory (something like 80GB of RAM). I quickly realized that the map had a high overhead - all those pointers in a red-black tree consume more RAM than my data! 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 someone gave me this problem as a whiteboard, I'd implement the map based solution, and would really struggle if I started getting questions about memory performance, and it would be silly to ding me for not choosing a binary search. In reality, my screwup was extremely simple to solve - given that I had a good understanding of the problem domain - something lacking in a whiteboard interview. So in general, people who do poorly in those whiteboard interviews may well solve the exact same problem with ease in an actual work situation. Another example: I wrote a DAG and needed to check if two (arbitrary) nodes were connected. I chose a fairly inefficient algorithm - recursive backtracking with no memoization. If I've already computed that B is connected to C, and I know A is connected to B, I don't need to run the whole algorithm to know that A is connected to C. I wrote the simple, inefficient version, knowing it was a poor algorithm. But my reasoning was that I wanted to write all my tests with corner cases working before I fixed the performance. Once I had all the tests written, I returned to optimize the algorithm. Then I said "Heck, let's see how bad it is with real world data." The algorithm was fast. Even when I significantly increased N. How come? Oh, it's because due to real world limitations in the problem I was solving, the maximum distance between any 2 nodes I was comparing was 7. Yes, in the abstract, it seemed very inefficient, but when you apply real world limitations, you realize there is nothing to gain by making it more efficient. Leetcode biased folks would have made the code more complex for little gain. [1] Maybe it was 64 bit - I forget.

vundercind 2y ago

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.

lesuorac 2y ago
Plenty of candidates can't figure how to use a for-loop to iterate over input or even how to handle nested data (Trees). If you're biggest worry about leetcode is does this language need a semi-colon at the end then I doubt you have trouble interviewing. --- Do you do much interviewing as an interviewer?
- vundercind 2y ago
  I have in past roles. We never leetcoded anyone where I’ve been an interviewer. One place where I guided it my approach was to attempt to learn something from the candidate—this not-infrequently led to my being the only person (they claimed) to have ever e.g. engaged them in a conversation about a paper they authored and listed on their résumé. Which, wtf, how do you not get curious enough to skim that before the interview and ask a couple non-stupid questions about it? I don’t exactly have a dataset (who does? A few Bigcos but most interviewers are working with tea-leaves and guesses) but I really liked the “try to learn something” approach and would use it again. It helps that I don’t know much so it’s pretty easy for me to find something I don’t know that the candidate can teach me about, I suppose—maybe this doesn’t work so well for people who know a lot and also aren’t good at faking not-knowing things.
lelandfe 2y ago
Just one example, but I was failed on a technical I took recently. It had a runtime, so not a whiteboard. But the editor I had to use provided no checking and I only found out after minutes of work that debugger breakpoints were not supported (the interviewer had not used them before) So I failed the technical as I had to spend like a substantial amount of a 45m session console logging out values and experimenting as I went. It turned out I missed a few characters in my code. I was pretty beside myself.

gdsdfe 2y ago

You can take a picture on your phone and let chat-gpt (or whatever else llm) just solve it for you it whatever language

fpig 2y ago

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.

Panzer04 2y ago

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)

hot_gril 2y ago

I wrote an HN submission somewhere about the biases I've seen in algo interviews. One thing is they love questions that can be solved with some small twist on BFS or DFS, usually one that's a lot easier if you're doing it non-recursively. I've gone through entire multi-round interviews like that.

kbob 2y ago
Breadth-First Search or Depth-First Search, I think. It took me too long to guess those initialisms.

GuB-42 2y ago

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