5 ms·

> well-oiled Chinese Room Wow, this is really the perfect description of the general understanding of algorithms and computational complexity in the post-leet

> well-oiled Chinese Room Wow, this is really the perfect description of the general understanding of algorithms and computational complexity in the post-leet code era. I've found that far less people in software understand and are curious about algorithms than there were 15 years ago, despite the fact that almost everyone studies them now for interviews. I wonder how many people asking questions about computational complexity could tell you what the pumping lemma is, or how a regular language differs from pushdown automata. Or, more important, if they could answer the question "what is Big Omega for this problem?" or if they are really asking "what is big theta?". I'm still tempted sometimes to refresh on recurrence equations to provide the actual answer for these things rather than just applying some heuristic. Of course, in my experience, doing something like that would get you a failing score since they wouldn't know what you're doing and therefore assume you are wrong and an idiot "I can't believe that guy didn't even understand Big O".

eastbound 4y ago
> I've found that far less people in software understand and are curious about algorithms than there were 15 years ago, despite the fact that almost everyone studies them now for interviews. It may explain why no-one succeeds my interview test, but then I wonder what I should test on if I want someone correctly smart. My interview test is simply to find a string in a string and return true. It takes two for and one if, everyone fails, I generally stop them after one hour when there are booleans scattered everywhere. The way I give the exercise is “Please program a .contains(), without using .indexOf(), and no need to optimize anything, I’m not looking for anything fancy.” A 49 years old java programmer even complained that the test isn’t fair because it’s stressful to program in front of people, so now I take the habit of sitting in the next room, but then people try to overdo it and deal with UTF-8 before having the basic algo working. I’m pulling my hair wondering what’s this parallel world I’m in, or whether I’m introducing a bias which makes everyone fail (2 interviewees per month for 5 months).
- Gunax 4y ago
  If they are over-complicating it, then you are not communicating the problem well. Maybe change the problem to an array of ints. It's the same solution but you will not have anyone asking about UTF and text direction.
  - justinlloyd 4y ago
    > “Please program a .contains(), without using .indexOf(), and no need to optimize anything, I’m not looking for anything fancy.” If that is the statement that was given to me, I would clarify the interviewer is not looking for optimal run-time or anything fancy like handling UTF-8 or right-to-left -- because an interviewer often says "nothing fancy" and then will nitpick the fact the code you wrote on the whiteboard doesn't follow precise PEP-8 standards or use idiomatic Ruby or doesn't adhere to the latest C++-23 syntax -- and then I would write a total of six or seven lines of code C code (variable declarations, return statement, etc), which would be two for-loops and an if-statement. I could probably get that down to just the for-loops if I want to be "fancy" and bury the conditional in the for-loop test itself. I think the real problem is, we tend, in an interview situation, to overthink what the interviewer is asking for at times. I see this in a lot of take home tests people do when applying to companies, then ask me if they have done enough before submitting to the company they are interviewing with. That said, I've dealt with interviewers that give the take home test, or the white board test, and then complain that the candidate didn't go far enough by adding on un-asked for stuff. "Going the extra mile" as they say. The crux of the problem is the vagaries of interviewing style.
    - weaksauce 4y ago
      I think a lot could be mitigated if interviewers supplied a take home test and a different example take home test with an answer that showed the format of what they were actually looking for with depth/complexity/testing/etc.
- PheonixPharts 4y ago
  > A 49 years old java programmer even complained that the test isn’t fair because it’s stressful to program in front of people, so now I take the habit of sitting in the next room Whether programmers like it or not, live coding has become a standard for interviews these days. I can see anyone still unfamiliar with this doing poorly, I used to do awful at these until I realized this is just part of the game, but it's not unreasonable to expect candidates to be able to do whiteboard/live coding. However, you just sitting in the other room, tells me you also have a lot to learn about the structure of live coding interviews. Every major Big Co. that does these has a very well established flow, including providing helpful clues to the candidate. Most companies provide training to all interviewers to make sure this process is smooth, repeatable and fair to candidates. Common tips are to: first make sure the candidate understands the question, make sure they are thinking out loud the entire time. You don't let the candidate go too far down the wrong path. Most important you have a list of anticipated questions with stock answers to help stuck candidates, as well as a list of stock prompts to help them get on the right track if they are lost. For example, in your challenge, if a candidate is stuck you might ask as simpler subproblem "so how would you find out if a sting contained the letter 'a'?" and if a candidate starts heading down the wrong path, prompt with "hmmm... I think I see where you're going, but I recommend you back up a bit and rethink this part here" It sounds like you're in a small shop so I highly recommend you enlist a few friends (especially some that have done interviewing at large companies) to help you work out the kinks in the interview itself.
- Beldin 4y ago
  > ...I wonder what I should test on if I want someone correctly smart. Why would you want that? Look for someone who can (and is happy/eager to) learn *from you*. Edit: smart isn't bad, but it's not much of a signal - there are plenty of ways to be smart but not very productive. Moreover, any test in an interview setting well be extremely limited. Ability & willingness to grow seems a lot more useful (and at least equally well testable).
- weaksauce 4y ago
  Either you aren't screening candidates that have no obvious coding skills or the job description is wildly off the mark. That's a pretty easy coding test for basic strings.
- throwanem 4y ago
  If you've just failed ten interviewees in a row, then either your sourcing is broken, or you're doing interviews wrong. Might be both, can't be neither. Granted, I don't think it's all that hard a problem, and while I'm not at keys to check I think off the top of my head it should be solvable for constant strings in linear time - not like you're asking for sequence alignment or anything like that. But if it demonstrates something relevant to the role and ten in a row can't hack it, then your pipeline's not finding you good candidates and that needs to be fixed. And if it's not relevant - which is highly plausible, as who ever needs to or even should reimplement heavily optimized standard library functions, especially for as hairy a type as strings - then why even ask it in the first place? edit, at keys: Yeah, it's simple to do this in linear time with constant strings (ie no backtracking): const cases = [ { subject: "now is the time for all good men to come to the aid of their country", searchFor: "n to come t", expect: true, }, { subject: "now is the time for all good men to come to the aid of their country", searchFor: "time flies", expect: false, }, { subject: "short skirt", searchFor: "looooooooong jacket", expect: false, }, { subject: "symbolized as ∆v and pronounced delta-vee", searchFor: "∆v", expect: true, }, ]; // TODO cases covering match at start and end, etc function contains(subject, searchFor) { let searchIdx = 0; for (let i = 0; i < subject.length; i++) { if (subject[i] === searchFor[searchIdx]) { searchIdx += 1; if (searchIdx + 1 === searchFor.length) { return true; } continue; } // We found a mismatch between subject and search // strings. Return to the first char of the search string; // we'll have to try to find a new match searchIdx = 0; } return false; } function assertEqual(expected, actual) { if (expected !== actual) { throw new Error("Assertion failed"); } } cases.forEach((testCase, i) => { const { subject, searchFor, expect } = testCase; try { assertEqual(contains(subject, searchFor), expect); console.log(`PASS: case ${i + 1}`); } catch (e) { console.error(`FAIL: case ${i + 1}`); } }); It's trivial in quadratic time too, of course, although I would expect a candidate for a senior role to be able at least to find the linear solution, if not to start there outright. In entire fairness, I have to admit that we do use problems of similar complexity (both cognitive and algorithmic) for our first tech session, which I frequently administer. In my experience, people tend to handle stuff like that pretty well, even with considerably less experience than it sounds like your candidates have. But - and I think this is crucial - none of those problems involves operating on strings. As another commenter here suggested, you definitely need to express this in terms of Array<number> or some similar contrived type that's obviously not as complicated as strings, because anyone who's been around for a while will certainly have been burned often enough by string complexity that they're not likely to assume they can treat it purely as an array of bytes iso8859-1 style. I certainly wouldn't assume that! To be clear, I would ask if I could safely assume that for the purposes of the problem, or more likely I would look at the tests around the problem and see if any of them included obviously non-Latin-1 chars and thus cue me that they need special handling. (If I can't see the tests while I'm writing the code that's supposed to pass them, you'd better believe I will ask about that!) I wouldn't necessarily ding a candidate for not asking, though. For one thing, this is all pretty basic info, and would certainly be available in "real life" - so if it isn't available in the interview, then the interview isn't a sufficiently accurate representation to produce a clean signal. For another, and for the same reason, the perceived power differential between panelist and candidate has to be taken into account. You're not going to get a clean signal if you bring your ego into the session, or otherwise give the candidate cause to feel more intimidation than the context naturally inspires. Some folks are more confident than others, sure - but it's a technical interview, and confidence isn't really of interest beyond the baseline of not seeing a candidate dissolve into a puddle of flop sweat. (And, in any case, if that does happen then it's at least as much my fault as anyone's, because if I'm not able to help people be comfortable enough to even function on my team or in my engineering org, then I'm not doing my job right!) So yeah, granted, I haven't interviewed with you and I don't know any details beyond what you've chosen to describe, so take this advice for whatever you find it to be worth. But, especially in a language like Java which I gather makes it more necessary to account for utf8 weirdness in strings than the languages I more commonly work with, I definitely think you'll see a significant improvement with just that one simple change of not using strings where you really don't need to in the first place. That might not be the only thing that needs attention - I suspect your pipeline may need some love, too - but I'm fairly confident it's an excellent place to start. (For what it's worth, my experience with tech interviews extends well beyond the candidate's role; I've been participating in them as a panelist for a good few years now, and lately, by request, have been doubling up my sessions as mentoring/shadowing opportunities for other engineers and EMs who want to improve their own panelist skills. Granted, I've approached this discussion largely from the candidate's perspective - but then too, I'd argue very firmly that if you're not considering how your interviews might go from the candidate's perspective, then that's something you need to work on, too.)
- foobarian 4y ago
  Hey! That's my question :-) I've been doing pretty much exactly this for the past 10 years. A common solution I've seen is a single while loop with gnarly logic inside to monkey with the string index, rewind when no match, etc. Then imagine that kind of code in your business critical backend.
- TacticalCoder 4y ago
  > ... but then people try to overdo it and deal with UTF-8 before having the basic algo working. Wait... We all know (?) that Java was conceived before Unicode 3.1 came out and somehow thought that 16 bit chars would forever be enough to hold unicode codepoints and hence Java strings are now a mess of both char and codepoint methods but... What's UTF-8 got anything to do with your question, even after a basic algo is working? If I'm using Java's charAt(...) on both strings, what's the encoding got anything to do with matching if the substring is present? Who cares that one character may have a codepoint encoded using more than one Java char primitive? It's either encoded the same in both strings or it won't match right? I'm confused. EDIT: you said it's not fancy, so you're not looking for people to match combining codepoints in one string matching another codepoint in the other string or things like that right?
  - akhmatova 4y ago
    What's UTF-8 got anything to do with your question, even after a basic algo is working? ربما يجب عليك التفكير أكثر قليلا في السؤال.
- akhmatova 4y ago
  A 49 years old java programmer even complained that the test isn’t fair And you had to mention their age ... why, exactly? As opposed to "a left-handed Java programmer", or "a Java guy wearing a Slayer T-shirt"? No -- for some reason, with this candidate -- their age was especially relevant to you. Why? But then people try to overdo it and deal with UTF-8 before having the basic algo working. Because of one too many experiences with live coding interviews, (on appearances) pretty much exactly like yours -- in which one gets flushed (or otherwise dinged) for failing to proactively treat such edge-case details as encoding gotchas, zettabyte-scale strings sharded across multiple time zones, etc. I’m pulling my hair wondering what’s this parallel world I’m in, or whether I’m introducing a bias which makes everyone fail (2 interviewees per month for 5 months). In fact, you are introducing just such a bias. There has recently been good, solid research done into the fact that performative (that is: on a whiteboard, in front of a group) "programming" tests are really basically high-pass anxiety filters. That is, implicitly designed not to measure programming ability, but the (studied) ability to ... successfully complete peformative rituals in front of random strangers you've never met. If you aren't aware of this research (or your capacities for empathy aren't at a level where this is intuitively obvious to you) -- then you shouldn't be conducting these kinds of interviews in the first place. No matter how good you are at programming per se.
sideshowb 4y ago
> I've found that far less people in software understand and are curious about algorithms than there were 15 years ago Maybe because so many SW job descriptions these days seem to consist of plugging library into framework, and anyone interested in algorithms would be bored? Not saying that's what you're recruiting for, but the industry has expanded massively while I'm guessing the number of algorithm heavy jobs has stayed roughly constant.
majormajor 4y ago
> I've found that far less people in software understand and are curious about algorithms than there were 15 years ago, despite the fact that almost everyone studies them now for interviews. I would argue people who prep with LeetCode aren't studying algorithms at all, they're doing something much closer to memorizing. I've seen people who I assume did a bunch of cramming like that because they'll be like "oh this is [xyz]" and throw out a solution in a hurry, and then I ask them to modify it in a non-standard way, and it's almost as if the idea that an off-the-shelf regurgitation of the "normal" solution for a problem not being able to handle a modified scenario is something they've never thought about. Like "oh this is a search problem" -> "what if [something that essentially boils down to the graph potentially having cycles]?" -> [head expodes instead of thinking about, say, tracking what nodes have already been seen]
closeparen 4y ago
Well first a lot of software we work on now isn’t pushing performance limits. The long poles in these development projects are requirements and domain understanding. The software that does push technical limits is likely to push IO, storage, and reliability related limits rather than compute. Distributed systems and big data are topics with a lot of interest in the last 15 years! We call them “computers” and algorithms are very important for computation, but many commercial applications these days actually use them in their capacity as telecommunications devices and data storage and retrieval systems, with the actual “computing” part being much less ambitious.

eastbound 4y ago

> I've found that far less people in software understand and are curious about algorithms than there were 15 years ago, despite the fact that almost everyone studies them now for interviews. It may explain why no-one succeeds my interview test, but then I wonder what I should test on if I want someone correctly smart. My interview test is simply to find a string in a string and return true. It takes two for and one if, everyone fails, I generally stop them after one hour when there are booleans scattered everywhere. The way I give the exercise is “Please program a .contains(), without using .indexOf(), and no need to optimize anything, I’m not looking for anything fancy.” A 49 years old java programmer even complained that the test isn’t fair because it’s stressful to program in front of people, so now I take the habit of sitting in the next room, but then people try to overdo it and deal with UTF-8 before having the basic algo working. I’m pulling my hair wondering what’s this parallel world I’m in, or whether I’m introducing a bias which makes everyone fail (2 interviewees per month for 5 months).

Gunax 4y ago
If they are over-complicating it, then you are not communicating the problem well. Maybe change the problem to an array of ints. It's the same solution but you will not have anyone asking about UTF and text direction.
- justinlloyd 4y ago
  > “Please program a .contains(), without using .indexOf(), and no need to optimize anything, I’m not looking for anything fancy.” If that is the statement that was given to me, I would clarify the interviewer is not looking for optimal run-time or anything fancy like handling UTF-8 or right-to-left -- because an interviewer often says "nothing fancy" and then will nitpick the fact the code you wrote on the whiteboard doesn't follow precise PEP-8 standards or use idiomatic Ruby or doesn't adhere to the latest C++-23 syntax -- and then I would write a total of six or seven lines of code C code (variable declarations, return statement, etc), which would be two for-loops and an if-statement. I could probably get that down to just the for-loops if I want to be "fancy" and bury the conditional in the for-loop test itself. I think the real problem is, we tend, in an interview situation, to overthink what the interviewer is asking for at times. I see this in a lot of take home tests people do when applying to companies, then ask me if they have done enough before submitting to the company they are interviewing with. That said, I've dealt with interviewers that give the take home test, or the white board test, and then complain that the candidate didn't go far enough by adding on un-asked for stuff. "Going the extra mile" as they say. The crux of the problem is the vagaries of interviewing style.
  - weaksauce 4y ago
    I think a lot could be mitigated if interviewers supplied a take home test and a different example take home test with an answer that showed the format of what they were actually looking for with depth/complexity/testing/etc.
PheonixPharts 4y ago
> A 49 years old java programmer even complained that the test isn’t fair because it’s stressful to program in front of people, so now I take the habit of sitting in the next room Whether programmers like it or not, live coding has become a standard for interviews these days. I can see anyone still unfamiliar with this doing poorly, I used to do awful at these until I realized this is just part of the game, but it's not unreasonable to expect candidates to be able to do whiteboard/live coding. However, you just sitting in the other room, tells me you also have a lot to learn about the structure of live coding interviews. Every major Big Co. that does these has a very well established flow, including providing helpful clues to the candidate. Most companies provide training to all interviewers to make sure this process is smooth, repeatable and fair to candidates. Common tips are to: first make sure the candidate understands the question, make sure they are thinking out loud the entire time. You don't let the candidate go too far down the wrong path. Most important you have a list of anticipated questions with stock answers to help stuck candidates, as well as a list of stock prompts to help them get on the right track if they are lost. For example, in your challenge, if a candidate is stuck you might ask as simpler subproblem "so how would you find out if a sting contained the letter 'a'?" and if a candidate starts heading down the wrong path, prompt with "hmmm... I think I see where you're going, but I recommend you back up a bit and rethink this part here" It sounds like you're in a small shop so I highly recommend you enlist a few friends (especially some that have done interviewing at large companies) to help you work out the kinks in the interview itself.
Beldin 4y ago
> ...I wonder what I should test on if I want someone correctly smart. Why would you want that? Look for someone who can (and is happy/eager to) learn *from you*. Edit: smart isn't bad, but it's not much of a signal - there are plenty of ways to be smart but not very productive. Moreover, any test in an interview setting well be extremely limited. Ability & willingness to grow seems a lot more useful (and at least equally well testable).
weaksauce 4y ago
Either you aren't screening candidates that have no obvious coding skills or the job description is wildly off the mark. That's a pretty easy coding test for basic strings.
throwanem 4y ago
If you've just failed ten interviewees in a row, then either your sourcing is broken, or you're doing interviews wrong. Might be both, can't be neither. Granted, I don't think it's all that hard a problem, and while I'm not at keys to check I think off the top of my head it should be solvable for constant strings in linear time - not like you're asking for sequence alignment or anything like that. But if it demonstrates something relevant to the role and ten in a row can't hack it, then your pipeline's not finding you good candidates and that needs to be fixed. And if it's not relevant - which is highly plausible, as who ever needs to or even should reimplement heavily optimized standard library functions, especially for as hairy a type as strings - then why even ask it in the first place? edit, at keys: Yeah, it's simple to do this in linear time with constant strings (ie no backtracking): const cases = [ { subject: "now is the time for all good men to come to the aid of their country", searchFor: "n to come t", expect: true, }, { subject: "now is the time for all good men to come to the aid of their country", searchFor: "time flies", expect: false, }, { subject: "short skirt", searchFor: "looooooooong jacket", expect: false, }, { subject: "symbolized as ∆v and pronounced delta-vee", searchFor: "∆v", expect: true, }, ]; // TODO cases covering match at start and end, etc function contains(subject, searchFor) { let searchIdx = 0; for (let i = 0; i < subject.length; i++) { if (subject[i] === searchFor[searchIdx]) { searchIdx += 1; if (searchIdx + 1 === searchFor.length) { return true; } continue; } // We found a mismatch between subject and search // strings. Return to the first char of the search string; // we'll have to try to find a new match searchIdx = 0; } return false; } function assertEqual(expected, actual) { if (expected !== actual) { throw new Error("Assertion failed"); } } cases.forEach((testCase, i) => { const { subject, searchFor, expect } = testCase; try { assertEqual(contains(subject, searchFor), expect); console.log(`PASS: case ${i + 1}`); } catch (e) { console.error(`FAIL: case ${i + 1}`); } }); It's trivial in quadratic time too, of course, although I would expect a candidate for a senior role to be able at least to find the linear solution, if not to start there outright. In entire fairness, I have to admit that we do use problems of similar complexity (both cognitive and algorithmic) for our first tech session, which I frequently administer. In my experience, people tend to handle stuff like that pretty well, even with considerably less experience than it sounds like your candidates have. But - and I think this is crucial - none of those problems involves operating on strings. As another commenter here suggested, you definitely need to express this in terms of Array<number> or some similar contrived type that's obviously not as complicated as strings, because anyone who's been around for a while will certainly have been burned often enough by string complexity that they're not likely to assume they can treat it purely as an array of bytes iso8859-1 style. I certainly wouldn't assume that! To be clear, I would ask if I could safely assume that for the purposes of the problem, or more likely I would look at the tests around the problem and see if any of them included obviously non-Latin-1 chars and thus cue me that they need special handling. (If I can't see the tests while I'm writing the code that's supposed to pass them, you'd better believe I will ask about that!) I wouldn't necessarily ding a candidate for not asking, though. For one thing, this is all pretty basic info, and would certainly be available in "real life" - so if it isn't available in the interview, then the interview isn't a sufficiently accurate representation to produce a clean signal. For another, and for the same reason, the perceived power differential between panelist and candidate has to be taken into account. You're not going to get a clean signal if you bring your ego into the session, or otherwise give the candidate cause to feel more intimidation than the context naturally inspires. Some folks are more confident than others, sure - but it's a technical interview, and confidence isn't really of interest beyond the baseline of not seeing a candidate dissolve into a puddle of flop sweat. (And, in any case, if that does happen then it's at least as much my fault as anyone's, because if I'm not able to help people be comfortable enough to even function on my team or in my engineering org, then I'm not doing my job right!) So yeah, granted, I haven't interviewed with you and I don't know any details beyond what you've chosen to describe, so take this advice for whatever you find it to be worth. But, especially in a language like Java which I gather makes it more necessary to account for utf8 weirdness in strings than the languages I more commonly work with, I definitely think you'll see a significant improvement with just that one simple change of not using strings where you really don't need to in the first place. That might not be the only thing that needs attention - I suspect your pipeline may need some love, too - but I'm fairly confident it's an excellent place to start. (For what it's worth, my experience with tech interviews extends well beyond the candidate's role; I've been participating in them as a panelist for a good few years now, and lately, by request, have been doubling up my sessions as mentoring/shadowing opportunities for other engineers and EMs who want to improve their own panelist skills. Granted, I've approached this discussion largely from the candidate's perspective - but then too, I'd argue very firmly that if you're not considering how your interviews might go from the candidate's perspective, then that's something you need to work on, too.)
foobarian 4y ago
Hey! That's my question :-) I've been doing pretty much exactly this for the past 10 years. A common solution I've seen is a single while loop with gnarly logic inside to monkey with the string index, rewind when no match, etc. Then imagine that kind of code in your business critical backend.
TacticalCoder 4y ago
> ... but then people try to overdo it and deal with UTF-8 before having the basic algo working. Wait... We all know (?) that Java was conceived before Unicode 3.1 came out and somehow thought that 16 bit chars would forever be enough to hold unicode codepoints and hence Java strings are now a mess of both char and codepoint methods but... What's UTF-8 got anything to do with your question, even after a basic algo is working? If I'm using Java's charAt(...) on both strings, what's the encoding got anything to do with matching if the substring is present? Who cares that one character may have a codepoint encoded using more than one Java char primitive? It's either encoded the same in both strings or it won't match right? I'm confused. EDIT: you said it's not fancy, so you're not looking for people to match combining codepoints in one string matching another codepoint in the other string or things like that right?
- akhmatova 4y ago
  What's UTF-8 got anything to do with your question, even after a basic algo is working? ربما يجب عليك التفكير أكثر قليلا في السؤال.
akhmatova 4y ago
A 49 years old java programmer even complained that the test isn’t fair And you had to mention their age ... why, exactly? As opposed to "a left-handed Java programmer", or "a Java guy wearing a Slayer T-shirt"? No -- for some reason, with this candidate -- their age was especially relevant to you. Why? But then people try to overdo it and deal with UTF-8 before having the basic algo working. Because of one too many experiences with live coding interviews, (on appearances) pretty much exactly like yours -- in which one gets flushed (or otherwise dinged) for failing to proactively treat such edge-case details as encoding gotchas, zettabyte-scale strings sharded across multiple time zones, etc. I’m pulling my hair wondering what’s this parallel world I’m in, or whether I’m introducing a bias which makes everyone fail (2 interviewees per month for 5 months). In fact, you are introducing just such a bias. There has recently been good, solid research done into the fact that performative (that is: on a whiteboard, in front of a group) "programming" tests are really basically high-pass anxiety filters. That is, implicitly designed not to measure programming ability, but the (studied) ability to ... successfully complete peformative rituals in front of random strangers you've never met. If you aren't aware of this research (or your capacities for empathy aren't at a level where this is intuitively obvious to you) -- then you shouldn't be conducting these kinds of interviews in the first place. No matter how good you are at programming per se.

sideshowb 4y ago

> I've found that far less people in software understand and are curious about algorithms than there were 15 years ago Maybe because so many SW job descriptions these days seem to consist of plugging library into framework, and anyone interested in algorithms would be bored? Not saying that's what you're recruiting for, but the industry has expanded massively while I'm guessing the number of algorithm heavy jobs has stayed roughly constant.

majormajor 4y ago

> I've found that far less people in software understand and are curious about algorithms than there were 15 years ago, despite the fact that almost everyone studies them now for interviews. I would argue people who prep with LeetCode aren't studying algorithms at all, they're doing something much closer to memorizing. I've seen people who I assume did a bunch of cramming like that because they'll be like "oh this is [xyz]" and throw out a solution in a hurry, and then I ask them to modify it in a non-standard way, and it's almost as if the idea that an off-the-shelf regurgitation of the "normal" solution for a problem not being able to handle a modified scenario is something they've never thought about. Like "oh this is a search problem" -> "what if [something that essentially boils down to the graph potentially having cycles]?" -> [head expodes instead of thinking about, say, tracking what nodes have already been seen]

closeparen 4y ago

Well first a lot of software we work on now isn’t pushing performance limits. The long poles in these development projects are requirements and domain understanding. The software that does push technical limits is likely to push IO, storage, and reliability related limits rather than compute. Distributed systems and big data are topics with a lot of interest in the last 15 years! We call them “computers” and algorithms are very important for computation, but many commercial applications these days actually use them in their capacity as telecommunications devices and data storage and retrieval systems, with the actual “computing” part being much less ambitious.