Happened to me on a different topic, felt bad for way too long ; in hindsight I'm pretty sure I dodged a bullet.
The simple "big-o" number doesn't account for whether you need to pass terabytes over the bus for every operation - and on actual computers moving around terabytes, I know, shockingly, this affects performance.
And if you have a dual epyc board with 1,024 threads, being able to parallelize a solution and design things for cache optimization, this isn't meaningless.
It's a weak classifier - if you really think I'm going to be doing a lexical sort in like O(n^3) like some kind of clown, I don't know what you're hiring here.
Found out later he scored me "2/5".
Alright, cool.
obviously all of this stuff matters in the end 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!
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
So excuse me for thinking that's what they're looking for and answering accordingly.
I literally only wanted to work there to team build, then snipe engineers and spin off into my own thing. So whatever.