A visual introduction to big O notation

It has a meaning already - and that is the sets of function which satisfy the condition. So O(n^2) is a subset of O(n^3)

Any everything is O(BB(n))

> It has a meaning already

Natural language tends to work like that, many words take on different meaning in different context, and the dictionary often needs to add alternate definitions as language evolves.

If you come to a software engineering interview and take the mathematical meaning and answer O(n^3), you won't get the job. You need to know the linga franca of the trade, not just the textbooks.

I know this can be frustrating, I just wouldn't really recommend staking your ground on this mountain.

The other mistake, is to assume the interviewer doesn't know better, and you do, and try to explain their mistake. A lot of them know very well, you simply didn't understand correctly the ask because you got confused with the context of the problem statement, and it shows you didn't adapt to the working environment successfully.

And if you think that's bad, wait till you talk to product ;)

And to add to my other comment, I don't think it came to mean that out of stupidity either.

As far as I know, and correct me if I'm wrong, there isn't a mathematical term for an approximate tight upper bound that's based off vague criteria of "fast enough".

In practice, people needed a way to say something like, let's not waste time getting all precise here, what's the approximate close-ish tight bound that's obvious, alright, that will work, let's use it.

Big Thetha implies proving the lower bound, and generally specifying the exact upper bound. So it was a worse term to use to describe the above, I think people settled on BigO, because you end up with some upper bound, and not necessarily the tightest one, but you lend on a tight-enough upper bound that it serves your practical purpose of choosing an algorithm to use in your application.

And so it became BigO, all for a lack of a better word, and eventually that became common parlance in those circles.

> there isn't a mathematical term for an approximate tight upper bound that's based off vague criteria of "fast enough"

In every mathematical writing they come up with definitions to precisely describe this kind of things - that’s what the big oh/theta aim to do - formalize what we mean by “bounded by in long term growth”.

You’re describing a situation of poor communication - not a fault for using the precise definition of Big oh.

I don’t think it’s really possible to give a precise mathematical definition of "good enough for my use case."

In practical software engineering, what is generally cared about is having a reasonable worst case upper bound. They don’t necessarily need the absolutely tightest bound, so you don’t need to spend extra effort chasing that. At the same time, they want to avoid bounds that are so loose they don’t give meaningful information.

That means the "upper bound" being asked for isn’t just about pure math. It requires applying practical judgment to the context we’re working in and the concerns we’re trying to address.

So yes, I’m asking for BigO, but with some flexibility. If you can provide the tightest bound, that’s great. If you can provide a tight enough bound that isn’t misleadingly loose, that also works.

A mathematician might cringe at words like "tight enough" and that’s fair. There’s no rigorous definition for it. But in the practical world where engineers are solving problems and users are paying for solutions, sometimes we need to rely on best judgment to land on a definition that serves the use case.

Because that's the prevalent need, BigO almost always implies the above in those context.

You know the correct definition of BigO, which is great. Where things fell short was recognizing how industry jargon often stretches textbook terms. The skill is being able to adapt, realize when people are talking about a related but different concept, and engage on that level. The strongest candidates handle both the theory and the communication.

So I'd ding the candidate for poor communication.

You're not engaging with the content of my comment and larping as my hiring manager - dinged for poor communication.

> I don’t think it’s really possible to give a precise mathematical definition

Have you studied math in an academic setting? The book “Art of Computer Programming” is all about formal definitions for understanding performance behavior.

> They don’t necessarily need the absolutely tightest bound,

Which is why I mention that big oh represents sets. But you dismissed that.