3 ms·

Well it is a specialized problem. If you've never worked on anything similar previously, it is going to take time. Don't even need to interview for selective bi

Well it is a specialized problem. If you've never worked on anything similar previously, it is going to take time. Don't even need to interview for selective billion dollar companies like Anthropic to encounter these types of problems - after college I interviewed for various electronics/hardware companies where you'd get asked to optimize low-level code - which would have looked quite foreign, if you had never actually worked on such problems before.

Onavo 9mo ago
If you ask an EE to debug react state management code without prior exposure they won't do too well either. But on the other hand they can easily pick up most of it after a week long crash course while training a performance engineer who can optimize code for a specific architecture would take months.
- ignoramous 9mo ago
  > EE to debug react state management ... easily pick up most of it after a week long crash course while training a performance engineer ... would take months Isn't that mostly because as you go up the abstraction layer, tools and docs to teach yourself the tricks of trade fast are in abundance (let alone a popular layer like React)? Which inturn is likely a function of incentives and opportunities.
  - fny 9mo ago
    It's because the higher up the stack you go, tools become more declarative and literate. Calling sort is far easier than understanding the algorithm for example.
    - giancarlostoro 9mo ago
      > Calling sort is far easier than understanding the algorithm for example. This was one of my gripes in college, why am I implementing something if I just need to understand what it does? I'm going to use the built-in version anyway.
      - komali2 9mo ago
        > why am I implementing something if I just need to understand what it does? So you can pass job interviews, of course!
      - robmccoll 9mo ago
        Because that's the entire point of college. It's supposed to teach you the fundamentals - how to think, how to problem solve, how to form mental models and adapt them, how things you use actually work. Knowing how different sorting functions work and what the tradeoffs are allows you to pick the best sorting function for your data and hardware. If the tools you have aren't doing the job, you can mend them or build new tools.
      - ksenzee 9mo ago
        The problem is that a computer science degree isn't the right training for most software engineering jobs.
        giancarlostoro 9mo ago
        My degree was not specifically CS, it was a related degree, the focus was on landing jobs, but they still covered some CS concepts because some students were in fact doing a CS degree. I was more focused on show me what I need to build things. I have never had to hand-craft any algorithm in my 15 years of coding, it just makes no sense to me. Someone else figured it out, I'm contempt understanding the algorithms.
        shakna 9mo ago
        In my twenty years, I've rerolled famous algorithms "every now and then". Its almost wild to me that you never have. Sometimes you need a better sort for just one task. Sometimes you need a parser because the data was never 100% standards compliant. Sometimes you need to reread Knuth for his line-breaking algorithm.
      - godelski 9mo ago
        So you know which sort to call because there isn't a right answer for all cases. And so you can write your own because you're probably going to want to sort data in a specific way. Sort doesn't mean in numerical increasing or decreasing order, it means whatever order you want. You're sorting far more often than you're calling the sort function.
- deleted 9mo ago
  [deleted]
- sublinear 9mo ago
  > they can easily pick up most of it after a week long crash course I have to disagree and question what you mean by "optimization". It's very easy to write web code that technically accomplishes a task, but does so poorly. This is the natural consequence of having so many options available. The vast majority of web devs with less than 5 years of experience simply don't understand plain javascript well enough. It's a longstanding problem that devs will reach for the most ergonomic tools, not the best tools. Lacking sufficient experience, they can't help it. This happens in all programming languages and in all layers of software. AI slop is even worse because it tends towards the mean.
  - ontouchstart 9mo ago
    Engineering is more or less about getting familiar with the proper tools and use them to solve specific problems: add new features, debugging, refactoring and optimizing. And the tools themselves are built by other engineers and they need new features, debugging, optimization etc. It is turtles all the way down. But each layer has its own jargons, conventions and unwritten hacks. That is where experience comes in. Once you get out off a rabbit hole or pothole, you are one step closer to becoming the “domain expert”. There is no short cut.
  - johnnyanmac 9mo ago
    >The vast majority of web devs with less than 5 years of experience simply don't understand plain javascript well enough they are never tested on it, and many won't dig that deep in the day-to-day. Whose fault is it that they don't know plain javascript well enough? That's the result of shipping "content" over any other metric of proper software engineering. Funnily enough I did take a mini-course (not a week, but we're talking maybe 100 hours of work as a recreational online summer class) in plain javascript at my university. Quite the quirky language. But this was in ES3 or so, so maybe there's many more guard rails these days against the core jank that makes up JS
johnnyanmac 9mo ago
>Don't even need to interview for selective billion dollar companies like Anthropic to encounter these types of problems I'll take any interviews at this point in time. But yes, every domain has its jargon. I work tangentially to this and quickly understood this as a GPGPU problem. A relatively elementary one if you studied this space, though a time limit of 2 hours seems overly restrictive if you aren't actively studying this stuff.

Onavo 9mo ago

If you ask an EE to debug react state management code without prior exposure they won't do too well either. But on the other hand they can easily pick up most of it after a week long crash course while training a performance engineer who can optimize code for a specific architecture would take months.

ignoramous 9mo ago
> EE to debug react state management ... easily pick up most of it after a week long crash course while training a performance engineer ... would take months Isn't that mostly because as you go up the abstraction layer, tools and docs to teach yourself the tricks of trade fast are in abundance (let alone a popular layer like React)? Which inturn is likely a function of incentives and opportunities.
- fny 9mo ago
  It's because the higher up the stack you go, tools become more declarative and literate. Calling sort is far easier than understanding the algorithm for example.
  - giancarlostoro 9mo ago
    > Calling sort is far easier than understanding the algorithm for example. This was one of my gripes in college, why am I implementing something if I just need to understand what it does? I'm going to use the built-in version anyway.
    - komali2 9mo ago
      > why am I implementing something if I just need to understand what it does? So you can pass job interviews, of course!
    - robmccoll 9mo ago
      Because that's the entire point of college. It's supposed to teach you the fundamentals - how to think, how to problem solve, how to form mental models and adapt them, how things you use actually work. Knowing how different sorting functions work and what the tradeoffs are allows you to pick the best sorting function for your data and hardware. If the tools you have aren't doing the job, you can mend them or build new tools.
    - ksenzee 9mo ago
      The problem is that a computer science degree isn't the right training for most software engineering jobs.
      - giancarlostoro 9mo ago
        My degree was not specifically CS, it was a related degree, the focus was on landing jobs, but they still covered some CS concepts because some students were in fact doing a CS degree. I was more focused on show me what I need to build things. I have never had to hand-craft any algorithm in my 15 years of coding, it just makes no sense to me. Someone else figured it out, I'm contempt understanding the algorithms.
        shakna 9mo ago
        In my twenty years, I've rerolled famous algorithms "every now and then". Its almost wild to me that you never have. Sometimes you need a better sort for just one task. Sometimes you need a parser because the data was never 100% standards compliant. Sometimes you need to reread Knuth for his line-breaking algorithm.
    - godelski 9mo ago
      So you know which sort to call because there isn't a right answer for all cases. And so you can write your own because you're probably going to want to sort data in a specific way. Sort doesn't mean in numerical increasing or decreasing order, it means whatever order you want. You're sorting far more often than you're calling the sort function.
deleted 9mo ago
[deleted]
sublinear 9mo ago
> they can easily pick up most of it after a week long crash course I have to disagree and question what you mean by "optimization". It's very easy to write web code that technically accomplishes a task, but does so poorly. This is the natural consequence of having so many options available. The vast majority of web devs with less than 5 years of experience simply don't understand plain javascript well enough. It's a longstanding problem that devs will reach for the most ergonomic tools, not the best tools. Lacking sufficient experience, they can't help it. This happens in all programming languages and in all layers of software. AI slop is even worse because it tends towards the mean.
- ontouchstart 9mo ago
  Engineering is more or less about getting familiar with the proper tools and use them to solve specific problems: add new features, debugging, refactoring and optimizing. And the tools themselves are built by other engineers and they need new features, debugging, optimization etc. It is turtles all the way down. But each layer has its own jargons, conventions and unwritten hacks. That is where experience comes in. Once you get out off a rabbit hole or pothole, you are one step closer to becoming the “domain expert”. There is no short cut.
- johnnyanmac 9mo ago
  >The vast majority of web devs with less than 5 years of experience simply don't understand plain javascript well enough they are never tested on it, and many won't dig that deep in the day-to-day. Whose fault is it that they don't know plain javascript well enough? That's the result of shipping "content" over any other metric of proper software engineering. Funnily enough I did take a mini-course (not a week, but we're talking maybe 100 hours of work as a recreational online summer class) in plain javascript at my university. Quite the quirky language. But this was in ES3 or so, so maybe there's many more guard rails these days against the core jank that makes up JS

johnnyanmac 9mo ago

>Don't even need to interview for selective billion dollar companies like Anthropic to encounter these types of problems I'll take any interviews at this point in time. But yes, every domain has its jargon. I work tangentially to this and quickly understood this as a GPGPU problem. A relatively elementary one if you studied this space, though a time limit of 2 hours seems overly restrictive if you aren't actively studying this stuff.