Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Big O Notation – Using not-boring math to measure code’s efficiency

interviewcake.com

Post reply on HN
Print view View original

51–60 of 100 posts

Re: Big O Notation – Using not-boring math to measure code’s efficiency

#51

Post by spraak »

xenihn wrote: post #49
spraak wrote: post #31

Earlier quoted context omitted.

I wish the usage of FAANG would die. Firstly it exlcudes obvious others like Uber, Microsoft, etc. Secondly, and purely aesthetically, it sounds silly. I hereby propose we call such companies the Big N, and I'm definitely open to other ideas.

Do Uber and Microsoft pay as much as Facebook/Apple/Google/Netflix/Amazon? The acronym exists for a reason. I think Amazon only makes the list because of how well their stock performs, but it still deserves to be on there because of that. The only large company I can think of that matches or even exceeds the offers those companies give out is (surprisingly) Snap. If we go smaller, Airbnb and Pinterest are up there to…

It's wildly misused if the reason that it exists is pay. Even the parent to my comment is talking about interview process; I doubt that varies much from any of the "FANG" companies vs. Microsoft, Uber, etc.

Re: Big O Notation – Using not-boring math to measure code’s efficiency

#52

Post by spraak »

JudgeWapner wrote: post #43
spraak wrote: post #31

Earlier quoted context omitted.

I wish the usage of FAANG would die. Firstly it exlcudes obvious others like Uber, Microsoft, etc. Secondly, and purely aesthetically, it sounds silly. I hereby propose we call such companies the Big N, and I'm definitely open to other ideas.

More generally, why do we have such a fetish for acronyms in general? Is it some kind of insider feeling to know a "code" for a thing?

An insider feeling is a strong likelihood

Re: Big O Notation – Using not-boring math to measure code’s efficiency

#53

Post by nothrabannosir »

JudgeWapner wrote: post #43
spraak wrote: post #31

Earlier quoted context omitted.

I wish the usage of FAANG would die. Firstly it exlcudes obvious others like Uber, Microsoft, etc. Secondly, and purely aesthetically, it sounds silly. I hereby propose we call such companies the Big N, and I'm definitely open to other ideas.

More generally, why do we have such a fetish for acronyms in general? Is it some kind of insider feeling to know a "code" for a thing?

Pattern recognition and aversion to repetitive behaviour on a micro level. Ironically oblivious to the repetition on a macro level that is most of our entire lives, but that’s another story :)

Re: Big O Notation – Using not-boring math to measure code’s efficiency

#54

Post by xthestreams »

dpzmick wrote: post #41
MichaelBurge wrote: post #7

def print_first_item(items): print items[0] This function runs in O(1) time (or "constant time") relative to its input. If this were C where the only types are fixed-size, that might be true. But in Python it seems like items[0] could display as 10 gigabytes of JSON. And if stdout is piped to a process that isn't consuming its input, it might never terminate naturally. Also, since Python has arbitrarily large integer…

in C, it items[0] could segfault, the fault could be caught by a signal handler which does some unbounded amount of work, then populates the appropriate memory location and returns... More realistically, the page of memory that items[0] is sitting on could be swapped to disk, requiring the OS to do some big operation. trying to write a piece of code with the big-O you are looking for generally has a huge number of ca…

I think you (and others) are misunderstanding the purpose of the big-O notation. It is used to discuss about algorithms, not about their implementation.

Re: Big O Notation – Using not-boring math to measure code’s efficiency

#56

Post by adrianN »

mgradowski wrote: post #50
MichaelBurge wrote: post #7

def print_first_item(items): print items[0] This function runs in O(1) time (or "constant time") relative to its input. If this were C where the only types are fixed-size, that might be true. But in Python it seems like items[0] could display as 10 gigabytes of JSON. And if stdout is piped to a process that isn't consuming its input, it might never terminate naturally. Also, since Python has arbitrarily large integer…

Similarly, if you were to write a O(n) Python program displaying the Fibbonacci sequence, it would not run in O(n) time but it would still take O(n) operations. It only makes sense to treat time complexity literally, if operations take fixed amount of time (int addition in Python doesn't).

Int addition never takes constant time unless your ints are bounded by a constant. Which is why serious people use bit complexity, or otherwise take into account the word size of their machines. Very serious people also take into account the number of memory accesses and the amount of memory used, as you can't address arbitrarily large amounts of memory in constant time either.

Re: Big O Notation – Using not-boring math to measure code’s efficiency

#57

Post by abalone »

hello_moto wrote: post #38
abalone wrote: post #21

Earlier quoted context omitted.

To be clear I think it’s good to test CS fundamentals even if you don’t use them every day. It’s a good screen for aptitude. I’m just concerned that taken to the extreme it mistakes excessive pattern recognition prep for true comprehension and aptitude. Especially if it’s “whoever puts the optimal solution on the board fastest wins.” I do think it would do you some good to read up on core CS and algorithms though. I…

> I’m just concerned that taken to the extreme it mistakes excessive pattern recognition prep for true comprehension and aptitude. Especially if it’s “whoever puts the optimal solution on the board fastest wins.” I agree with you on this. They do have taken this to the extreme because the questions are getting harder and harder. This is hard tbh because if you're an employer whom used to be able to filter candidates…

Improvement doesn't mean making it harder. SAT questions don't get harder every year (ideally). They're just different. It takes effort to come up with something different and novel though. Most places don't.

Maybe that's what the industry needs.. its own SAT. Heck man, that would make interviewing a lot better. You take one brutal test over a few hours, get your score, and then apply to multiple companies. You don't have to do dozens of whiteboard code interviews. Job postings specify score ranges. There's different score components (algos vs system design, like math vs verbal).

I guess there are startups like triplebyte trying to do that, but they're not as independent as the SAT. They make money off hires.

Re: Big O Notation – Using not-boring math to measure code’s efficiency

#58

Post by iandanforth »

Question: At what point in a career do you expect someone to have gone from "I know Big O" to "I know how this data structure is laid out in memory on this OS?"

My experience says really good engineers know the latter, but I'd like to hear if this holds for others.

Re: Big O Notation – Using not-boring math to measure code’s efficiency

#59

Post by abalone »

weq wrote: post #46
abalone wrote: post #13

I've noticed there are SO many of these "coding interview prep" courses lately. Like, obviously it's a hot job market, but there's just so many and of a certain vibe that it seems like some are selling a dream. There's a common narrative too, that it's all about algorithm question prep and it's a "game" you can win. One youtuber who recently landed a ~$275K TC gig said it's not about being "intelligent" it's about pr…

I have found pair-programming with a dev on a current problem you have in your codebase to be the best litmus test. If u want to give "quiz" interviews, u will get employee's good doing them. Like those CS grads in my class who copied eachothers take-home assignments yet still passed because they were good at memoizing. Furthermore, this is the first training session for your future employee - you are inducting them…

> I have found pair-programming with a dev on a current problem you have in your codebase to be the best litmus test.

This has its drawbacks too. You're biasing towards familiarity with your code base's specific tech stack. Good engineers can learn new tech stacks in days/weeks, so that's not that important to screen for.

Plus "everyday" code is a lot of plumbing and busywork, so it's not as good a screen for intelligence. Algos at least cut to the "hard stuff".

> Like those CS grads in my class who... passed because they were good at memoizing.

Getting good at memoizing would be a perfectly fine reason to pass a dynamic programming class. :-)

Post reply on HN