3 ms·

"I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Neither have I been in a situation where big-o was relevant..." H

"I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Neither have I been in a situation where big-o was relevant..." How about in job interviews? Obviously never on the actual job, but how about interviews? They ask all sorts of crazy crap. I suspect because they've got no idea what to ask.

softawre 10y ago
There are many software engineering jobs where Big-O is relevant.
- collyw 10y ago
  And many many more where it isn't. My current work, the problem isn't the algorithms that make the thing run slowly, its because the people who wrote it don't know how to use Django efficiently. Lots of loops in the application making database calls each time (our main page is making over 1000 database calls). A bit more thought in the database design, knowing a bit more about how Django's ORM works and you could do all that work in the database in less than 10 calls and make it a lot faster. A couple of extra database indexes in the right places, and a bit of caching and it should run even faster. Thats the sort of knowledge that is relevant to (most of) our jobs, not big-o.
  - IMTDb 10y ago
    "Lots of loops making database calls each time" improved by "a bit more thought in the design" and "a bit of caching" sounds an awful lot like Big O analysis, and algorithmic optimisation even if it is on top on Django ORM.
    - lucasnemeth 10y ago
      Sometimes only. big O cuts all the constants and they are really important in actual software development. A lot of actual work involve improving the speed from a 10N to a 2N, it is a big difference for the costumer, but they are all O(N).
    - vonmoltke 10y ago
      That's not Big O. Big O is asymptotic complexity. Caching, loop optimization, and the like are irrelevant noise to that calculus.
    - collyw 10y ago
      Its not really. Its the same algorithmic complexity (the exception being adding appropriate database indexes), but shifting the where the computation is done.
  - ryandrake 10y ago
    This is exactly true. Even at places where the primary money-making IP is a truly novel application of some algorithm, 99.5% of the code are "supporting actors": an API onto that algorithm, plumbing up through layers of middleware, bindings to other languages/frameworks, integration code to shim it through some legacy system, a CRUD interface, etc. My guess is that Google's search code is actually just tiny island of real computer science surrounded by a vast ocean of plumbing, frameworks and middleware, and that when you're hired there, chances are you're not going to be working on that island.
eksemplar 10y ago
I live in Denmark, so the short answer is that I don't. Big-o came up in an interview once, but it was mainly along the lines of being asked if I knew what it was and me answering with a yes. I've spent a semester doing all sorts of silly algorithms, including * sort, so it's not like I couldn't handle them if it was ever required. The thing is, time to market and code consistency will almost always leave you using the standard libraries which came with your environment. There are obviously a few jobs where it's relevant, but I'm into things like architecture, digitizations and business development, so I'll never work one of those jobs, and neither will 95% of you.

softawre 10y ago

There are many software engineering jobs where Big-O is relevant.

collyw 10y ago
And many many more where it isn't. My current work, the problem isn't the algorithms that make the thing run slowly, its because the people who wrote it don't know how to use Django efficiently. Lots of loops in the application making database calls each time (our main page is making over 1000 database calls). A bit more thought in the database design, knowing a bit more about how Django's ORM works and you could do all that work in the database in less than 10 calls and make it a lot faster. A couple of extra database indexes in the right places, and a bit of caching and it should run even faster. Thats the sort of knowledge that is relevant to (most of) our jobs, not big-o.
- IMTDb 10y ago
  "Lots of loops making database calls each time" improved by "a bit more thought in the design" and "a bit of caching" sounds an awful lot like Big O analysis, and algorithmic optimisation even if it is on top on Django ORM.
  - lucasnemeth 10y ago
    Sometimes only. big O cuts all the constants and they are really important in actual software development. A lot of actual work involve improving the speed from a 10N to a 2N, it is a big difference for the costumer, but they are all O(N).
  - vonmoltke 10y ago
    That's not Big O. Big O is asymptotic complexity. Caching, loop optimization, and the like are irrelevant noise to that calculus.
  - collyw 10y ago
    Its not really. Its the same algorithmic complexity (the exception being adding appropriate database indexes), but shifting the where the computation is done.
- ryandrake 10y ago
  This is exactly true. Even at places where the primary money-making IP is a truly novel application of some algorithm, 99.5% of the code are "supporting actors": an API onto that algorithm, plumbing up through layers of middleware, bindings to other languages/frameworks, integration code to shim it through some legacy system, a CRUD interface, etc. My guess is that Google's search code is actually just tiny island of real computer science surrounded by a vast ocean of plumbing, frameworks and middleware, and that when you're hired there, chances are you're not going to be working on that island.

eksemplar 10y ago

I live in Denmark, so the short answer is that I don't. Big-o came up in an interview once, but it was mainly along the lines of being asked if I knew what it was and me answering with a yes. I've spent a semester doing all sorts of silly algorithms, including * sort, so it's not like I couldn't handle them if it was ever required. The thing is, time to market and code consistency will almost always leave you using the standard libraries which came with your environment. There are obviously a few jobs where it's relevant, but I'm into things like architecture, digitizations and business development, so I'll never work one of those jobs, and neither will 95% of you.