Big-O notation explained by a self-taught programmer
justin.abrah.ms
Big-O notation explained by a self-taught programmer
1–10 of 58 posts
Re: Big-O notation explained by a self-taught programmer
#2Extensively incorrect.
Re: Big-O notation explained by a self-taught programmer
#3My company always works a "Big-O" question into interview questions. It's funny how we ask about the complexity of the algorithm and maybe 50% of applicants even know what Big-O notation is.
It doesn't seem to impact hiring decisions though. We haven't turned anyone down because they miss that question.
I think it's because anyone who has programmed for a year or so professionally already understands the concept of inefficient algorithms. They don't need to measure it mathematically, just learn how to optimize.
Re: Big-O notation explained by a self-taught programmer
#4After seeing a lot of peers being mislead by big O I think most of big O articles on the web, for the sake of clarity or simplicity omits to express one thing
if we admits functions * square_big_o O(n²) * linear_big_o O(n)
then the statement
time(squarre_big_o(x)) > time(linear_big_0(x))
is not necessary true for every value of x
because the actual complexity could be
* 1000+1000*N
* 2+N²
without this in mind, you got peer who tell you that this thing is faster because the algorithm is O(n) versus O(n²), though we're talking about a function that will always have n < 10, but yesterday night they read an article about big O and now they have to throw a "let's think about the big O" remarks for every single problem we meet
Re: Big-O notation explained by a self-taught programmer
#5My company always works a "Big-O" question into interview questions. It's funny how we ask about the complexity of the algorithm and maybe 50% of applicants even know what Big-O notation is. It doesn't seem to impact hiring decisions though. We haven't turned anyone down because they miss that question. I think it's because anyone who has programmed for a year or so professionally already understands the concept of i…
I can't agree more, when interviewing I always ask this kind of questions of "theoretical knowledge" not to have the actual answer, but to see how candidates reacts when they don't know. Because if the guy not only admits he does not know directly and is eager to know what it is briefly, then you know that giving your team and environment is favorable to learning, the guy will soon be able to catch up, and it's certainly the same guy that one day will bring in the team's "tips and tricks" channel an article or an insight that will make the team's knowledge grow too.
Re: Big-O notation explained by a self-taught programmer
#6After seeing a lot of peers being mislead by big O I think most of big O articles on the web, for the sake of clarity or simplicity omits to express one thing if we admits functions * square_big_o O(n²) * linear_big_o O(n) then the statement time(squarre_big_o(x)) > time(linear_big_0(x)) is not necessary true for every value of x because the actual complexity could be * 1000+1000*N * 2+N² in which case most of the ti…
Except if one knows what the definition of big O is, there is nothing to be misled by. What big O tells you is what is the function bounded by after a constant lower bound on the input.
One always want to do performance testing to see whether it comes into play even when it comes to more practical applications such as in code.
Re: Big-O notation explained by a self-taught programmer
#7Don't you want to know if your recipe takes 10 minutes or 10 hours to cook?
Re: Big-O notation explained by a self-taught programmer
#8Don't you want to know if your recipe takes 10 minutes or 10 hours to cook?
Sometimes. Sometimes you just need to throw things in the oven until the first one browns up.
I recently had a problem where I needed an adjacency matrix of shortest paths. It was a choice between dijkstra and floyd-warshall. My dijkstra implementation kicked the pants off of floyd warshall for this application by an order of magnitude, which you wouldn't really expect. And the big-O complexity was the same for both algorithms, it's just that for the graph structure, the operation count for dijkstra was much lower. It was the first one to brown up.
Re: Big-O notation explained by a self-taught programmer
#9My company always works a "Big-O" question into interview questions. It's funny how we ask about the complexity of the algorithm and maybe 50% of applicants even know what Big-O notation is. It doesn't seem to impact hiring decisions though. We haven't turned anyone down because they miss that question. I think it's because anyone who has programmed for a year or so professionally already understands the concept of i…
I can't agree more, when interviewing I always ask this kind of questions of "theoretical knowledge" not to have the actual answer, but to see how candidates reacts when they don't know. Because if the guy not only admits he does not know directly and is eager to know what it is briefly, then you know that giving your team and environment is favorable to learning, the guy will soon be able to catch up, and it's certa…
How can anyone applying for a programming job not know Big-O notation? That's CS101. I don't care if you're self-taught, it's audacious to even call yourself a programmer if you don't know the very basics of algorithms and data structures.
If I were interviewing a candidate, and it was revealed he didn’t know Big-O notation, my next questions would be about data structures, because now I’m suspecting he wouldn’t even know how to implement the simplest of structures. What next, simple pointer arithmetic, is he unable to even walk an array?
We are no longer talking about a programmer then.
Not knowing these things, I usually chalk it up to either laziness, or lack of interest in understanding how things work.
Either way, that’s not someone I’d want on my team. Programmers should be enthusiastic about fundamentals. Good programmers have a “hacker” mentality, a need to know and understand inner workings, a craving to dig deep. I’d say this mentality is what you want from anyone in STEM.
Re: Big-O notation explained by a self-taught programmer
#10Earlier quoted context omitted.
I can't agree more, when interviewing I always ask this kind of questions of "theoretical knowledge" not to have the actual answer, but to see how candidates reacts when they don't know. Because if the guy not only admits he does not know directly and is eager to know what it is briefly, then you know that giving your team and environment is favorable to learning, the guy will soon be able to catch up, and it's certa…
How can anyone applying for a programming job not know Big-O notation? That's CS101. I don't care if you're self-taught, it's audacious to even call yourself a programmer if you don't know the very basics of algorithms and data structures. If I were interviewing a candidate, and it was revealed he didn’t know Big-O notation, my next questions would be about data structures, because now I’m suspecting he wouldn’t even…
I started off disagreeing with your statement but as I read further, I became a believer. In fact, "gotcha" and other trick questions are the worst, but understanding CS fundamentals shows that you were paying attention in class and are probably interested (if not passionate) about CS.
If not, there are hundreds of other openings that the candidate can apply to.