How to win the coding interview
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 &quot;the most efficient code possible&quot; 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.)<p>Can you imagine if the task were &quot;write the most efficient code possible to check if an array of strings of integers such as &quot;3423&quot;, &quot;34356&quot;, etc, is sorted (treating the strings as base-ten numbers, &quot;3423&quot; representing 3423 and so on), ignoring any strings that include non-numerical characters&quot; started out by making two copies of the whole damn array.  That&#x27;s what&#x27;s happening here, it&#x27;s kind of shocking that this is what javascript developers accept as the &quot;most efficient possible&quot; without anyone having the slightest issue.)<p>I&#x27;m shocked.  Even the definition of efficient offered for &quot;Write the most efficient function you can&quot; is<p>&gt; If you’re experienced, you should know that “efficient” in production code means three things:<p>&gt; Runs fast.<p>&gt; Doesn’t take up more memory than it needs to.<p>&gt; Is stable and easy to maintain.<p>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.<p>I mean, on a two megabyte input file the &quot;most efficient function that you can&quot; 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!<p>What I&#x27;m really shocked about isn&#x27;t that that&#x27;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&#x27;t do it either.  This post and this thread was a real eye-opener for me.