var ar = [];
ar1.map(function() { ar.push(arguments[0]); }
ar2.map(function() { ar.push(arguments[0]); }
However, under pressure it's so much different than responding to a comment. This is for sure a great question to ask. var ar = [];
ar1.map(function() { ar.push(arguments[0]); }
ar2.map(function() { ar.push(arguments[0]); }
However, under pressure it's so much different than responding to a comment. This is for sure a great question to ask.The correct answer would be to loop while neither list is empty and always put the smaller element into the new array and remove it from the original list.
Then you iterate over each of the lists individually (one of them will already be empty) and copy over the remaining elements at the end.
Edit: See http://stackoverflow.com/questions/5958169/how-to-merge-two-... for some solutions (in one of the answers there, they made the same mistake.)
By the way, I don't think that group includes you: I'm quite sure you'd be able to pass it in an interview context. You'd probably be paying more attention to the details of the question in an interview and I usually give sample input/output to reduce the chance of a candidate accidentally overlooking a word in the question.
I mean, I've gotten 3rd grade arithmetic wrong in my own HN comments before! ;)
I think people are assuming that I force the candidate to do this in C or something and munge about with next pointers and sentinel nodes. They're free to do so if they'd like, but usually they have a pretty high degree of control over what language they use and in this problem, what data structure it starts in (including arrays). As mentioned upthread, that means the problem literally reduces to something like loops, iteration, conditionals, collections. These abstractions are fundamental enough that again, any reasonable definition of coding includes them. Physics PhDs writing simulations occasionally have to deal with more than one particle (or whatever), and if they have no clue how to "do X for every Y", they won't get very far.
This isn't just hypothetical for me: I've interviewed PhDs (including non-CS ones), and pretty much all of them blew past this first filter. I've worked with people whose only prior programming experience was during their math PhD, and they generally were pretty great at programming (and pretty horrible at engineering). The latter is easy to teach (this guy became one of my best engineers) but the former is much more fundamental, much harder to teach, and generally something you want at time of hire.
Since you say that you will have CS degree "soon", I'll assume you are fairly new to programming. Making mistakes is something that you will do for your whole career. A mistake does not make you one kind of programmer over another. Even many mistakes does not. It just means more practice.
Having the courage to post code off the top of your head in a world-wide forum, means you can have the courage to transcend where you are now. Keep trying to improve -- whatever it takes, and don't unnecessarily limit yourself.