3 ms·
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
by 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 agoIt 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 agoI 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.