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

Programmers can’t write algorithms without help

queworx.com

Post reply on HN
Print view View original

81–90 of 105 posts

Re: Programmers can’t write algorithms without help

#81

Post by rhinoceraptor »

Tehchops wrote: post #3
starbugs wrote: post #2

> Programmers can’t write algorithms without help And that might be a good thing. How often does a normal software engineer have to write bubble sort from scratch in his daily life? If someone from my team came to me telling me he had to sort an array and wrote bubble sort from scratch, then I'd probably not be very happy with that unless there is a really good reason to spend that time on it rather than using an exi…

Purely anecdotally: I've seen online discourse that suggests that the complex nature of the modern web requires FE devs be able to keep at least a couple efficient data-structure traversal tools in their toolbox. Anyone with more experience could probably chime in.

In my experience, most front end performance problems are just unoptimized assets, or huge JS bundles. After that, there's issues where you're doing a lot of unnecessary rendering, for example in a React app, a Redux mapStateToProps function that isn't memoizing an array map, which is causing the whole subtree to re-render on every state update. The only time I even needed algorithmic complexity was implementing a drag and drop control, for a list that could have several hundred thousand elements, and my naive implementation was n^2.

Re: Programmers can’t write algorithms without help

#82

Post by commandlinefan »

stunt wrote: post #4

String length in Python is maybe too much exaggeration unless someone hasn’t wrote Python for a long time. But, algorithms? Sure! Nobody remembers them for ever. Often you at least need to read how the algorithm works before implementing it. Obviously for most devs it is faster to just search for a sample implementation or a pseudocode.

> Nobody remembers them for ever

Actually I always thought the opposite - if you started programming in the 80’s (maybe early 90’s), you had to write sort algorithms and you had to study them in college, so you’re going to be bound to remember them at least well enough to come up with the “base case” (i.e. bubble sort). I do assume that younger programmers, especially self-taught types, probably haven’t come across these to if they did, it was one lecture, once, ten years ago, memorized and forgotten because they never applied it again.

Re: Programmers can’t write algorithms without help

#83

Post by commandlinefan »

mark-r wrote: post #52
kps wrote: post #9

Shouldn't be a surprise; the person who wrote the algorithm without help took more than 15 minutes, and got a paper or a PhD out of it.

The first time I heard the problem of detecting a circular link in a linked list, I figured out the tortoise/hare solution in probably 15 minutes without having heard it before, so it's not impossible.

You should have written a paper.

Re: Programmers can’t write algorithms without help

#84

Post by jcranmer »

commandlinefan wrote: post #78
Eleopteryx wrote: post #76

Earlier quoted context omitted.

>Yes, they're incompetent. So you feel confident in asserting that, at the time that the person made that tweet, the quality of the Python code that they shipped was poor, or it took an inordinate amount of time to produce? All because they had to look up len()?

Actually, yeah. That one jumped out at me, too: that’s kind of like saying “I know how to drive a car, but I always have to look up which one is the gas pedal and which one is the brake”. If you’ve done _anything_ in Python, the length function is ingrained in your brain, so if you honestly don’t remember it, you just haven’t written any Python (or it’s been more than 10 years).

I routinely use several languages, and am constantly forgetting which ones use .size() and which ones .len(). It's not worth committing to memory because, if I get it wrong, the compiler will tell me "what is this function of which you speak?", and I will simply turn around and use the other one, at which point it starts compiling again, wasting me at most a minute of my time.

Furthermore, I should point out that it's not out of the imagination that someone wouldn't use len() all that heavily. Python has functional operators that let you do map/reduce-style operations on lists, strings, dicts, etc. that don't require you to use length all that much. My most recent python script only uses len() in two places for more robust error reporting.

Re: Programmers can’t write algorithms without help

#85

Post by Gunax »

sithlord wrote: post #36
Gunax wrote: post #31

Earlier quoted context omitted.

So everyone knows that the interview isn't perfectly realistic--it's a simulation. Consider that when athletes are scouted, they are usually not asked to play in a full game of their sport. But instead certain stats like 'how fast can he run 100m' and 'how high can he jump' are used. Sure, in a real game you will never run 100m in a straight line on asphalt--but the speed at which one runs 100m in a straight line is…

That's not a very good example. Athletes are being watched for 4-8 years before they are ever drafted. Colleges are watching all the high school games, and Pros are watching all the college games.

Perhaps--but it's the analogy I came up with while writing this comment. If you can replace it with a better one, go ahead.

Sometimes analogies are not really meant to be perfect, but just simpler methods of communicating information.

Re: Programmers can’t write algorithms without help

#86

Post by commandlinefan »

jcranmer wrote: post #84
commandlinefan wrote: post #78

Earlier quoted context omitted.

Actually, yeah. That one jumped out at me, too: that’s kind of like saying “I know how to drive a car, but I always have to look up which one is the gas pedal and which one is the brake”. If you’ve done _anything_ in Python, the length function is ingrained in your brain, so if you honestly don’t remember it, you just haven’t written any Python (or it’s been more than 10 years).

I routinely use several languages, and am constantly forgetting which ones use .size() and which ones .len(). It's not worth committing to memory because, if I get it wrong, the compiler will tell me "what is this function of which you speak?", and I will simply turn around and use the other one, at which point it starts compiling again, wasting me at most a minute of my time. Furthermore, I should point out that it'…

Well... try not to take this personally, but... that means that you're not really an expert in Python, which is what (I assume) the interviewer in the linked post was looking for. You're capable in several languages, and may be an expert in one or more of them, but if they're looking for Python expertise, asking you how to find the length of a string is a good way to get a feel for how much time you're going to need to get to where you can really be trusted to produce mission-critical Python software (which may not be a deal breaker, if you're good at a lot of other things).

Re: Programmers can’t write algorithms without help

#87

Post by Gunax »

cinnamonheart wrote: post #38
Gunax wrote: post #26

Earlier quoted context omitted.

I've been a developer for almost 2 years (I know not that long) but I have never even heard of bubble sort. Looking it up, it is O(n^2). Is there a reason this is a common interview question? It doesn't seem like a sort one would ever really use, or at least it has very obscure uses. I always thought merge/quick sorts accounted for 99.9% of use cases and only ever really learned about those.

The logic of bubble sort is so simple that just the description is enough for an implementation. It's a common interview question for the same reason Fizzbuzz is used -- any programmer worth their salt should be able to just write it down. Insertion and selection sort are also O(N^2), but sorts like merge and quick will use them to sort small sublists in their recursive cases because they are fast when input is small…

I see. I would hope one would give a description of what bubble sort is during the question.

It's definitely easy to implement, it just had me worried because I had never heard of it!

Re: Programmers can’t write algorithms without help

#88

Post by Gunax »

tzs wrote: post #67
Gunax wrote: post #26

Earlier quoted context omitted.

I've been a developer for almost 2 years (I know not that long) but I have never even heard of bubble sort. Looking it up, it is O(n^2). Is there a reason this is a common interview question? It doesn't seem like a sort one would ever really use, or at least it has very obscure uses. I always thought merge/quick sorts accounted for 99.9% of use cases and only ever really learned about those.

Keep in mind that big-O notation describes how something behaves as the problem size goes up. Something O(n^2) will be slower than something that is O(n log(n)) for large enough n. For smaller n, it is quite possible that an O(n^2) algorithm can beat an O(n log(n)) one. If you have an application that only has to sort small lists, but has to sort a lot of them, it is quite possible that an O(n^2) sort like bubble, in…

I understand. In a sense merge/quick are 'galactic algorithms' at the size.

It's more just that I am concerned I would be cornered trying to remember what 'bubble sort' is. It's not difficult to write the algorithm per se--just hard to remember what 'bubble sort' means.

Re: Programmers can’t write algorithms without help

#89

Post by Gunax »

vonmoltke wrote: post #74
Gunax wrote: post #31

Earlier quoted context omitted.

So everyone knows that the interview isn't perfectly realistic--it's a simulation. Consider that when athletes are scouted, they are usually not asked to play in a full game of their sport. But instead certain stats like 'how fast can he run 100m' and 'how high can he jump' are used. Sure, in a real game you will never run 100m in a straight line on asphalt--but the speed at which one runs 100m in a straight line is…

> Consider that when athletes are scouted, they are usually not asked to play in a full game of their sport. But instead certain stats like 'how fast can he run 100m' and 'how high can he jump' are used. Teams rarely sign players based solely on measures like this, and those that do frequently regret it. Additionally, the nature of contracts in professional sports are very different from regular employment. Players a…

I know. It's just an analogy. You can replace it with a better one if you want.

The general point I am making is: these are not trying to measure actual job tasks, but instead measuring something that (they hope) is closely related to, or correlated with one's ability to perform the job. The idea is that if one can do these sorts of problems, one can probably do the actual job at hand.

Re: Programmers can’t write algorithms without help

#90

Post by jimbokun »

rhinoceraptor wrote: post #81
Tehchops wrote: post #3

Earlier quoted context omitted.

Purely anecdotally: I've seen online discourse that suggests that the complex nature of the modern web requires FE devs be able to keep at least a couple efficient data-structure traversal tools in their toolbox. Anyone with more experience could probably chime in.

In my experience, most front end performance problems are just unoptimized assets, or huge JS bundles. After that, there's issues where you're doing a lot of unnecessary rendering, for example in a React app, a Redux mapStateToProps function that isn't memoizing an array map, which is causing the whole subtree to re-render on every state update. The only time I even needed algorithmic complexity was implementing a dr…

> that isn't memoizing an array map

"memoizing" is a pretty computer-sciencey word, so not implementing a data structure exactly, but still requires knowledge beyond "plug these APIs together."

> The only time I even needed algorithmic complexity was implementing a drag and drop control, for a list that could have several hundred thousand elements, and my naive implementation was n^2.

And if you didn't have an intuition for algorithmic complexity, how long would it have taken you to figure out the problem? And how many times have you instinctively avoided having an explosion in algorithmic complexity, by intuitively picking a suitable data structure or algorithm?

Post reply on HN