3 ms·

the most amazing thing is that apparently javascript developers do not ever, ever think about any algorithms like the way a C++ programmer would. I was shocked

the most amazing thing is that apparently javascript developers do not ever, ever think about any algorithms like the way a C++ programmer would. I was shocked that when the write-up explicitly calls for "the most efficient code possible" nobody cares that the example program starts off making two extraneous copies of data that might never need to be read. (why lowercase the characters inside when you can fail early working outside in.) Can you imagine if the task were "write the most efficient code possible to check if an array of strings of integers such as "3423", "34356", etc, is sorted (treating the strings as base-ten numbers, "3423" representing 3423 and so on), ignoring any strings that include non-numerical characters" started out by making two copies of the whole damn array. That's what's happening here, it's kind of shocking that this is what javascript developers accept as the "most efficient possible" without anyone having the slightest issue.) I'm shocked. Even the definition of efficient offered for "Write the most efficient function you can" is > If you’re experienced, you should know that “efficient” in production code means three things: > Runs fast. > Doesn’t take up more memory than it needs to. > Is stable and easy to maintain. This is an absolutely shocking definition, given the example code offered. It really does show that javascript programmers do not in any sense consider algorithms the way Go or C++ programmers would. (I conclude this after reading the comments here and also the article.) Especially given the above definitions. I mean, on a two megabyte input file the "most efficient function that you can" would start by copying the whole two megabytes...twice. Rather than working from the outside in, so it can reject the input and ignore the inside characters as fast as possible. Shocking! What I'm really shocked about isn't that that's what the solution was - fine, no problem. But rather, that nobody comes close to thinking about most-efficient the way other types of programmers would think about it - and this includes the comment in the story which takes exception to the offered solution. It doesn't do it either. This post and this thread was a real eye-opener for me.

p4wnc6 10y ago
The shocking thing for me isn't so much that certain sections of the programming community don't natively think this way (I'm not convinced that I want them to ... someone whose primary value add in life is site design, for example, should dedicate way fewer brain cycles to this kind of algorithm efficiency and just relegate it to something they will profile and fix empirically should the need arise) ... but rather that interviewers of any kind, anywhere, actually care whether a candidate, who is writing code in a totally alien physical and mental situation (the interview), would write "efficient" code during an interview at all. Yes, maybe some small allowance for some discussion about basic time complexity, but nothing more. If you very clearly articulate an O(n^2) algorithm during an interview, that's excellent -- even if there is an O(log n) solution that we'd all prefer. You can always learn on the job and improve through self-study, etc., but the basic task of clear articulation is much more important. Obviously, no one who comes up with the O(log n) answer is going to be marked off for it, but neither should the O(n^2) person be. Instead, interviewers should just admit that focusing on efficient code in the setting of an interview is utter nonsense. You cannot learn from that whether or not the person is going to be effective at writing efficient code for you in the completely and totally different situation of coming to work every day in a regular work environment. No matter what you think, you simply cannot. So the better thing would be to just admit that the results of timed interview trivia cannot tell you anything at all about how effectively someone will write efficient code in a real-life situation, and just get on with it.
- logfromblammo 10y ago
  It is entirely unnecessary to copy the string, to stack or heap. Rather than stripping whitespace, you check for whitespace when incrementing/decrementing the index. Rather than setting everything to lowercase, use a culturally-appropriate character comparator that ignores case differences. Just stick a Turkish dotless-i character in the unit tests somewhere, at the end of "I’m a lasagna hog; go hang a salamı." and see what happens.
  - p4wnc6 10y ago
    I agree, and feel it's also irrelevant for what this could possibly tell me about a candidate as far as interview questions go. You're totally right, it just doesn't mean that someone doing these wrong things in the interview setting gives you really any bits of info at all about whether they would be good or bad in a real job setting. Absolutely none. Great programmers who would never do such unnecessary things when programming in a real situation may nonetheless think of them and do them when in an interview situation, since the kinds of situations are so incompatibly different. I guess if they did this in a take-home assignment, then it might be evidence of something. In an in-person coding interview though, it's just not useful at all for forming opinions about the candidate. I've even seen veteran programmers with greatly successful open source projects, lots of experience, good education, high level of intellectual independence and curiosity, excellent writing skill, etc. etc., give highly inefficient implementations of FizzBuzz during an in-person interview. These interviews are just not at all related to the way human beings actually write code and work in real life, and so they just cannot tell you much.

p4wnc6 10y ago

The shocking thing for me isn't so much that certain sections of the programming community don't natively think this way (I'm not convinced that I want them to ... someone whose primary value add in life is site design, for example, should dedicate way fewer brain cycles to this kind of algorithm efficiency and just relegate it to something they will profile and fix empirically should the need arise) ... but rather that interviewers of any kind, anywhere, actually care whether a candidate, who is writing code in a totally alien physical and mental situation (the interview), would write "efficient" code during an interview at all. Yes, maybe some small allowance for some discussion about basic time complexity, but nothing more. If you very clearly articulate an O(n^2) algorithm during an interview, that's excellent -- even if there is an O(log n) solution that we'd all prefer. You can always learn on the job and improve through self-study, etc., but the basic task of clear articulation is much more important. Obviously, no one who comes up with the O(log n) answer is going to be marked off for it, but neither should the O(n^2) person be. Instead, interviewers should just admit that focusing on efficient code in the setting of an interview is utter nonsense. You cannot learn from that whether or not the person is going to be effective at writing efficient code for you in the completely and totally different situation of coming to work every day in a regular work environment. No matter what you think, you simply cannot. So the better thing would be to just admit that the results of timed interview trivia cannot tell you anything at all about how effectively someone will write efficient code in a real-life situation, and just get on with it.

logfromblammo 10y ago
It is entirely unnecessary to copy the string, to stack or heap. Rather than stripping whitespace, you check for whitespace when incrementing/decrementing the index. Rather than setting everything to lowercase, use a culturally-appropriate character comparator that ignores case differences. Just stick a Turkish dotless-i character in the unit tests somewhere, at the end of "I’m a lasagna hog; go hang a salamı." and see what happens.
- p4wnc6 10y ago
  I agree, and feel it's also irrelevant for what this could possibly tell me about a candidate as far as interview questions go. You're totally right, it just doesn't mean that someone doing these wrong things in the interview setting gives you really any bits of info at all about whether they would be good or bad in a real job setting. Absolutely none. Great programmers who would never do such unnecessary things when programming in a real situation may nonetheless think of them and do them when in an interview situation, since the kinds of situations are so incompatibly different. I guess if they did this in a take-home assignment, then it might be evidence of something. In an in-person coding interview though, it's just not useful at all for forming opinions about the candidate. I've even seen veteran programmers with greatly successful open source projects, lots of experience, good education, high level of intellectual independence and curiosity, excellent writing skill, etc. etc., give highly inefficient implementations of FizzBuzz during an in-person interview. These interviews are just not at all related to the way human beings actually write code and work in real life, and so they just cannot tell you much.