The Most Challenging Interview Question
in [JavaScript]
|
From: David Mark on 8 May 2010 20:00 Garrett Smith wrote: > Dmitry A. Soshnikov wrote: >> On 08.05.2010 23:56, Garrett Smith wrote: >>> David Mark wrote: >>>> Garrett Smith wrote: >> >> [...] >> >>>>>>>>>> A: It's a library that attempts to provide a better browser API. >>>>>>>>> Attempted and failed (miserably). Have you looked at their API? >>>>> Nope. >>>>> >>> >>> To clarify, I did not mean "Nope I haven't," I meant it as negative >>> acknowledgment of that answer in an interview. >>> >> >> And why is this a crime to examine any library's (including jQuery) >> code? I don't see that this is a negative acknowledgment on an interview. >> > > Apparently you misunderstood what I wrote. Let me clarify. > > Asking the interviewer: "Have you looked at their API?" can come off as > a threat, especially when the interviewer is already happily using it. But I wasn't talking to the "interviewer". IIRC, I was commenting on Jorge's answer. > > [...] > >>> >>> var selfString = String(this); >>> alert(selfString); >>> >>> - is acceptable. >>> >> >> You still talk about irrelevant thing; > > The question that expects undocumented behavior. It is unfair to present > such test question. > > meanwhile Mark has understood it > > Somebody seeing things from your POV does not make you right; we're > talking about behavior that is provably true of false. It appears something has gone horribly wrong with the quoting. :( > >> So, I think it is good to make some _small_ clarification (such as: >> "you understand that alert's result is can be host-environment >> specific, so I think we're just talking about exactly `this` value, >> right? OK. " And after that -- detailed explanation about the _major_ >> goal, but not about irrelevant "alert" and more -- in detailed >> non-needed view). >> >> Don't forget that a job interview isn't just a technical knowledge >> test. Ideally, you should test and understand as much about an >> employee as possible, including his personal qualities, how he finds >> solutions for suggested issue, whether he can to see the major problem >> and to place priorities accordingly. >> > Well yeah, questions like the one I presented should be answered require > great care. VK mentioned subtly mentioning concerns and bugs in a > non-judgemental way. That's good advice, still requires care. VK posted good advice? Must be the end of the world. :) > > Discussing problems and asking back "have you looked at the source code" > doesn't work. Not when talking exclusively to HR, no. But I've landed numerous contracts over the years by pointing out that bad tools were making the firm's job much harder than it had to be. And it is a good way to weed out clueless organizations that you probably don't want to work for in the first place. > > Segue to a real problem, such as a sidestep "Oh, so what are you going > to be using it for? Do you have an example?" > > Doesn't work. Actually, it sounds like a good answer to me (unless the firm is so deluded as to be looking for a blanket jQuery recommendation). > > Either like jQuery or be really really good at hiding the fact. > > Someone who is oblivious to the drawbacks of using jQuery won't be > interested in hearing those in an interview. It can leave an impression > that the interviewee is a argumentative or will want to change things to > some strange and unconventional way, rather than using something more > familiar. Or, as some of the Dojo bozos accused me of: "not a team player". :) It's odd that those I work with tend to enjoy the experience, while those I contradict on mailing lists tend to hiss and moan (and speculate about what it must be like to work with me--see Matt Kruse). It goes to show that mailing lists and the like are not representative of the "real world", despite the many references to it. > > People trust things that are familiar. I'm very familiar with jQuery and I wouldn't trust it to mow my lawn. :) > > Someone used to a "standard" jQuery solution might consider "pure > javascript" as "wasting time" trying to "writing everything from > scratch" and would still have to worry about making it work in "all > browsers." Yes, there are lots of those types out there (see any JS-related thread on StackOverflow). Some can be educated and some cannot. The best bet is to identify those who cannot and send them packing. Then you can teach the remaining developers without fanboy-like interference. > > "What's your favorite library?" or "What do you think of jQuery" are > questions that, for one who understands the langauge, require good > psychological tact, regardless of what the interviewer really intended. Or just avoid such interviews for jobs that indicate the need for a "jQuery Ninja". You sure as hell can't educate the interviewer as they only know what they've heard from the resident "experts". > > [...] > >> >> By the way, the example with an array and mentioning splice isn't >> good, because splice will work. What I meant is removing e.g. child >> nodes from some node and cashing length property for optimization with >> direct (incremental) iteration. But, that's just an abstract small >> example ;) >> > > Also people don't always think or act the same when they're nervous, > compared to when they would when comfortably enjoying the best way to > solve a problem. A job interview shouldn't make you nervous. In most cases, there's nothing to lose. I always looked at them as if I was interviewing the company about whether I wanted to work there (not the other way around). I do remember one from way back that was related to .NET development where they told me over the phone that I would need to take a typing test. Yes, I confirmed after an awkward pause, as in WPM. That's typical of how disconnected the HR gate is from the IT department. It's usually best to know somebody on the inside, else all you have is HR to "impress" (in this case with secretarial skills). Suffice to say, I crossed that particular firm off my list to interview. I mean, even if I typed 180 WPM, what sort of salary could that possibly translate to? Clearly they were looking for typists, not programmers.
From: Chris F.A. Johnson on 8 May 2010 20:26 On 2010-05-07, nick wrote: > On May 7, 8:54?am, "Michael Haufe (\"TNO\")" ><t...(a)thenewobjective.com> wrote: > >> Q: How would you implement a constructor that inherits a method from >> it's prototype that has access to it's instance private variables? In >> other words if I had: > > Argh! "Its" ... "its" ... "its." > > It's a declension. Not possessive, not a contraction. Like "his" or > "her," it needs no apostrophe. Until around the beginning of the 19th century, "it's" was the usual form. -- Chris F.A. Johnson, <http://cfajohnson.com> Author: Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
From: Garrett Smith on 8 May 2010 21:10 David Mark wrote: > Garrett Smith wrote: >> Dmitry A. Soshnikov wrote: >>> On 08.05.2010 23:56, Garrett Smith wrote: >>>> David Mark wrote: >>>>> Garrett Smith wrote: >>> [...] >>> >>>>>>>>>>> A: It's a library that attempts to provide a better browser API. >>>>>>>>>> Attempted and failed (miserably). Have you looked at their API? >>>>>> Nope. >>>>>> >>>> To clarify, I did not mean "Nope I haven't," I meant it as negative >>>> acknowledgment of that answer in an interview. >>>> >>> And why is this a crime to examine any library's (including jQuery) >>> code? I don't see that this is a negative acknowledgment on an interview. >>> >> Apparently you misunderstood what I wrote. Let me clarify. >> >> Asking the interviewer: "Have you looked at their API?" can come off as >> a threat, especially when the interviewer is already happily using it. > > But I wasn't talking to the "interviewer". IIRC, I was commenting on > Jorge's answer. > Huh. Now I'm confused, but whatever... >> [...] >> >>>> var selfString = String(this); >>>> alert(selfString); >>>> >>>> - is acceptable. >>>> >>> You still talk about irrelevant thing; >> The question that expects undocumented behavior. It is unfair to present >> such test question. >> >> meanwhile Mark has understood it Dmitry wrote ^^^^^^^^^^^^^^^^^^^^^ >> >> Somebody seeing things from your POV does not make you right; we're >> talking about behavior that is provably true of false. > Garrett wrote ^^^^^^^^^^^^^^^^^^^^^ > It appears something has gone horribly wrong with the quoting. :( > David wrote ^^^^^^^^^^^^^^^^^^^^^ Slighly, but not horribly wrong. [...] >> Discussing problems and asking back "have you looked at the source code" >> doesn't work. > > Not when talking exclusively to HR, no. But I've landed numerous > contracts over the years by pointing out that bad tools were making the > firm's job much harder than it had to be. And it is a good way to weed > out clueless organizations that you probably don't want to work for in > the first place. > >> Segue to a real problem, such as a sidestep "Oh, so what are you going >> to be using it for? Do you have an example?" >> >> Doesn't work. > > Actually, it sounds like a good answer to me (unless the firm is so > deluded as to be looking for a blanket jQuery recommendation). > I thought so. I was a big believer in that one. I used it a number of times. Does not work. The response result usually does not include a real problem, but instead follows along how the interviewer anticipated carrying out the interview in the first place, and if discussion of jQuery is on the agenda, then that is what is going to go down. I did I get a real problem, twice. Once, the problem was actually with Dojo query selector and the response was: "We have these forms on the page and they all have id="form". After hearing things like that from everyone I spoke to there, it was clear that none of the developers were unwilling to recognize their mistakes. Who wants to work at a place like that? The second time, the interviewer presentd a problem for which he believed the only correct answer was jQuery. He interrupted me to tell me that my answer was wrong, before I got to finish it. The guy was completely rude and the other interviewers noticed it, too. >> Someone used to a "standard" jQuery solution might consider "pure >> javascript" as "wasting time" trying to "writing everything from >> scratch" and would still have to worry about making it work in "all >> browsers." > > Yes, there are lots of those types out there (see any JS-related thread > on StackOverflow). Some can be educated and some cannot. The best bet > is to identify those who cannot and send them packing. Then you can > teach the remaining developers without fanboy-like interference. > Send the interviewer packing? >> "What's your favorite library?" or "What do you think of jQuery" are >> questions that, for one who understands the langauge, require good >> psychological tact, regardless of what the interviewer really intended. > > Or just avoid such interviews for jobs that indicate the need for a > "jQuery Ninja". You sure as hell can't educate the interviewer as they > only know what they've heard from the resident "experts". > Like it or not, these things are industry standard. jQuery and Mootools, in particular, seem to elicit a devotion that is part of the social. >> [...] >> >>> By the way, the example with an array and mentioning splice isn't >>> good, because splice will work. What I meant is removing e.g. child >>> nodes from some node and cashing length property for optimization with >>> direct (incremental) iteration. But, that's just an abstract small >>> example ;) >>> >> Also people don't always think or act the same when they're nervous, >> compared to when they would when comfortably enjoying the best way to >> solve a problem. > > A job interview shouldn't make you nervous. In most cases, there's > nothing to lose. I always looked at them as if I was interviewing the > company about whether I wanted to work there (not the other way around). > Nervousness is fine, so long as the interviewer is aware of it and handles it well. It's OK to admit that you're nervous and can usually help because the interviewer will see that the person as having human characteristics, and not some weird guy acting funny. > I do remember one from way back that was related to .NET development > where they told me over the phone that I would need to take a typing > test. Yes, I confirmed after an awkward pause, as in WPM. That's > typical of how disconnected the HR gate is from the IT department. It's > usually best to know somebody on the inside, else all you have is HR to > "impress" (in this case with secretarial skills). Suffice to say, I > crossed that particular firm off my list to interview. I mean, even if > I typed 180 WPM, what sort of salary could that possibly translate to? > Clearly they were looking for typists, not programmers. That's odd. My strangest interview question ever: "You've shown us some DHTML examples. Do you have any examples of javascript?" At that point, it became very clear that the interviewer had absolutely no clue of anything I had been discussing with him. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 8 May 2010 21:15 David Mark wrote: > Stefan Weiss wrote: >> On 08/05/10 22:47, David Mark wrote: >>>>>> Dmitry A. Soshnikov wrote: >>>>>>> "Let there is an array. How to remove all elements with value 3 from >>>>>>> it?" >>> Using delete, a reverse loop is clearly the way to go. I haven't >>> thought about other solutions as I've lost interest at this point. >> I assume you meant splice - if you use delete, the loop direction >> doesn't matter. >> >> > [...] > I suppose something like this:- > [...] > That's a little ugly. Could be re-factored in any number of ways. > How about a forward loop using splice? function removeThrees(a) { for(var i = 0; i < a.length; i++) { if(a[i] === 3) { a.splice(i,1); } } return a; } [...] -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 8 May 2010 21:22
Garrett Smith wrote: > David Mark wrote: >> Garrett Smith wrote: >>> Dmitry A. Soshnikov wrote: >>>> On 08.05.2010 23:56, Garrett Smith wrote: >>>>> David Mark wrote: >>>>>> Garrett Smith wrote: >>>> [...] > > Like it or not, these things are industry standard. jQuery and Mootools, > in particular, seem to elicit a devotion that is part of the social. s/social/meme -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |