> but big-o comes before all of those other things
If you're attempting to quantify algorithmic scalability with big-o, without those in mind, you'll often be wrong. There was a great post here a few years ago going into this, and how memory access "complexity" is what usually matters, and what dominantly shapes the scalability curve. It had nice examples showing how the expected big-o scalability curves were often completely wrong, outside of toys.
If you're not trying to quantify algorithmic scalability with big-o, then have fun coming up with a fun collection of symbols to put next to your code, and petting your spherical cow!
algorithmic complexity is 100% absolutely orthogonal to the stuff you've mentioned
what you're describing is something different than big-o, in the sense that is commonly understood, and what your interviewer almost certainly intended
I understand what you're describing and talking about but it's not big-o
I would guess that you haven't had any kind of formal cs education? no shade but like there are some important topics covered in those curriculums
I have. I understand big-o, I understand that it’s just algorithmic complexity. I understand big-o is not a performance scaling model, because algorithms run on real hardware. That's fine. Some people enjoy petting spherical cows, and some people work with the nuances of reality. That's also fine.
If you're attempting to quantify algorithmic scalability with big-o, without those in mind, you'll often be wrong. There was a great post here a few years ago going into this, and how memory access "complexity" is what usually matters, and what dominantly shapes the scalability curve. It had nice examples showing how the expected big-o scalability curves were often completely wrong, outside of toys.
If you're not trying to quantify algorithmic scalability with big-o, then have fun coming up with a fun collection of symbols to put next to your code, and petting your spherical cow!