"big o" usually refers to algorithmic complexity, which is something entirely orthogonal to all of the dimensions you mentioned

obviously all of this stuff matters in the end but big-o comes before all of those other things

▲

nomel 3 days ago | parent [-]

> 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!

▲

kiitos 2 days ago | parent [-]

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

	▲	nomel a day ago \| parent [-]
		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.