[kristopolous]

This was the same interview where some guy was asking me about "big-o" - like the thing that you teach 19 year olds and I was saying that parallelization matters, i/o matters, quantization matters, whether you can run it on the GPU, these all matter.

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.

[kiitos]

"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]

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

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

[kristopolous]

But none of that is the point. This was at a well funded company looking for a high scalability engineer.

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.

[kiitos]

looks like both you and they dodged bullets in this outcome, so all worked out in the end

[nomel]

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.