It depends on the job though. I do Java backend transaction processing so our team always needs to understand a basic understanding of runtime (and memory usage) when we code. It's mostly basic things like why something is 'faster' then O(n2). Sometimes to reduce runtime, we cache, but then we have to consider the size of the cache, etc
That being said, for front-end web dev, I don't think I've ever had to ever think about it.
Yes, I think the key point is that after some good or bad experiences, most developers will have an implicit knowledge that helps deciding on how to program something and when something’s very slow to find out why.
That said, I’ve probably used it a lot of times. But I never wrote down or talked explicitly about O().
And by the way, I was a java Backend developer for most of my time and just recently started in the frontend as well.
I ask this to senior devs pretty frequently, about how often they use Big O. They respond like you. I asked because I still struggle with learning it.
I think about that time I build a reporting tool in python, and it took 50 seconds to compile the report. I was still learning, and the thing worked so :shrug:.
Now that I 'sort' of understand Big O- if I had to refactor that code, I'm more likely to think about performance and when to use specific loops/nested loops.
I still won't be able to go, "AH - that's a O(n log n)" or whatever. But that background understanding does change how I will approach the problem.
I once was asked to reduce the execution time of a MySQL procedure. That query could take between 2 to 3 minutes to execute using a recursion-ish call that could, at worst, make it an O(n^3). My solution was to change the data structure, which was very strange, to a JSON one and use the Generated Column feature, we could reduce to an O(n^2) for the procedure and the time was at the 10ms. The only drawback was a little increase in insertion time.
I don't think people say "hey look, this triple-loop through all the dataset is an O(n^3)", you just know something is wrong and go up to a better solution right away.
Last but not least, knowing the kind of task you want to do with the data, how it will be managed, grow and access can help you select the proper type of data structure, may it be a set, a queue, a stack, a linked list, etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for this article, those are good and easy examples!
Still, because you mentioned it, I wonder if I would just walk out the room if sometimes someone asks me about big O notation in a job interview.
Not because I don’t understand it, but because I’ve never needed it a single time in the last 20 years.
true :)
It depends on the job though. I do Java backend transaction processing so our team always needs to understand a basic understanding of runtime (and memory usage) when we code. It's mostly basic things like why something is 'faster' then O(n2). Sometimes to reduce runtime, we cache, but then we have to consider the size of the cache, etc
That being said, for front-end web dev, I don't think I've ever had to ever think about it.
Yes, I think the key point is that after some good or bad experiences, most developers will have an implicit knowledge that helps deciding on how to program something and when something’s very slow to find out why.
That said, I’ve probably used it a lot of times. But I never wrote down or talked explicitly about O().
And by the way, I was a java Backend developer for most of my time and just recently started in the frontend as well.
I ask this to senior devs pretty frequently, about how often they use Big O. They respond like you. I asked because I still struggle with learning it.
I think about that time I build a reporting tool in python, and it took 50 seconds to compile the report. I was still learning, and the thing worked so :shrug:.
Now that I 'sort' of understand Big O- if I had to refactor that code, I'm more likely to think about performance and when to use specific loops/nested loops.
I still won't be able to go, "AH - that's a O(n log n)" or whatever. But that background understanding does change how I will approach the problem.
I once was asked to reduce the execution time of a MySQL procedure. That query could take between 2 to 3 minutes to execute using a recursion-ish call that could, at worst, make it an O(n^3). My solution was to change the data structure, which was very strange, to a JSON one and use the Generated Column feature, we could reduce to an O(n^2) for the procedure and the time was at the 10ms. The only drawback was a little increase in insertion time.
I don't think people say "hey look, this triple-loop through all the dataset is an O(n^3)", you just know something is wrong and go up to a better solution right away.
Last but not least, knowing the kind of task you want to do with the data, how it will be managed, grow and access can help you select the proper type of data structure, may it be a set, a queue, a stack, a linked list, etc.