The Most Challenging Interview Question
in [JavaScript]
|
From: Garrett Smith on 8 May 2010 01:20 Dmitry A. Soshnikov wrote: > On May 7, 3:07 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> > wrote: >> On May 7, 11:45 am, Ry Nohryb wrote: >> >> >> >>> On May 7, 10:17 am, David Mark wrote: >>>> Ry Nohryb wrote: >>>>> On May 7, 9:27 am, Garrett Smith wrote: >> <snip> >>>>>> What is your most challenging interview question? >>>>>> Mine: >>>>>> "What do you think of jQuery?" >>>>> A: It's a library that attempts to provide a better browser API. >>>> Attempted and failed (miserably). Have you looked at their API? Nope. Technical questions and comments are usually threatening to a jQuery developer who has not looked at the source code. >>>> It's not just the innards that stink with that thing, the crust >>>> is garbage too. Or was that supposed to be a disingenuous answer? Not hired. >>> It's the truth, and a very diplomatic way of putting it, imo. >> It is a question that is going to need a very diplomatic answer in >> that context. I would probably go for something along the lines of; >> it is pretty much what you would expect given the relative >> understanding of javascript and browser scripting experience of its >> designer(s). That is fully open to interpretation (including a >> positive interpretation), but if pursued invites the justification >> that would prevent the answer sounding bigoted. >> > > Is this thread the discussion of jQuery library or I missed something? > Or is it about "The Most Challenging Interview Question"? > Not about jQuery. jQuery is unsuitable for professional development. But you can't say that in an interview, and especially not to someone who likes jQuery. [...] > > "What does result alert(this)?" > > without mentioning the context of the question -- let the candidate > will explain all this himself. > Testing unspecified host method string conversion seems unreasonable; nothing can be guaranteed to be expected. > Or, more practical: > > "Let there is an array. How to remove all elements with value 3 from > it?" > > this question allows to check whether the candidate knows that > "length" is being modified every time when he will be splicing/ > deleting items, and therefore direct for-loop isn't fit. > Sure, splice modifies length. Is that not what you want? What result is wanted? var a = [3,1,2,3,4,3,4,5,3]; removeThrees(a); a => ? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 8 May 2010 02:10 Garrett Smith wrote: > Dmitry A. Soshnikov wrote: >> On May 7, 3:07 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> >> wrote: >>> On May 7, 11:45 am, Ry Nohryb wrote: >>> >>> >>> >>>> On May 7, 10:17 am, David Mark wrote: >>>>> Ry Nohryb wrote: >>>>>> On May 7, 9:27 am, Garrett Smith wrote: >>> <snip> >>>>>>> What is your most challenging interview question? >>>>>>> Mine: >>>>>>> "What do you think of jQuery?" >>>>>> A: It's a library that attempts to provide a better browser API. >>>>> Attempted and failed (miserably). Have you looked at their API? > > Nope. > > Technical questions and comments are usually threatening to a jQuery > developer who has not looked at the source code. Even worse, they would seem to be threatening to the developers who _write_ the source code. Deep down, they know they are running on guesswork and hate to have doubts brought to the surface. You notice how none of the jQuery-ites ever come in here to debate its technical merits (well, Resig tried once anyway). Or Dojo, or any of the other "majors" that routinely filleted here. It's like they lose all of their "power" in front of informed audiences. But visit Ajaxian and they are made out to be God-like. History will sort it out eventually I'm sure. :) > >>>>> It's not just the innards that stink with that thing, the crust >>>>> is garbage too. Or was that supposed to be a disingenuous answer? > > Not hired. > >>>> It's the truth, and a very diplomatic way of putting it, imo. >>> It is a question that is going to need a very diplomatic answer in >>> that context. I would probably go for something along the lines of; >>> it is pretty much what you would expect given the relative >>> understanding of javascript and browser scripting experience of its >>> designer(s). That is fully open to interpretation (including a >>> positive interpretation), but if pursued invites the justification >>> that would prevent the answer sounding bigoted. >>> >> >> Is this thread the discussion of jQuery library or I missed something? >> Or is it about "The Most Challenging Interview Question"? >> > > Not about jQuery. jQuery is unsuitable for professional development. But > you can't say that in an interview, and especially not to someone who > likes jQuery. Which is why I would never attend such an interview. I just wait until the neophytes screw everything to hell and then make ten times the money to clean up after them. ;) jQuery saves money alright. Saves it up for me. :) > > [...] > >> >> "What does result alert(this)?" >> >> without mentioning the context of the question -- let the candidate >> will explain all this himself. >> > > Testing unspecified host method string conversion seems unreasonable; > nothing can be guaranteed to be expected. I think the point was that, without context, you don't know what - this - is. > >> Or, more practical: >> >> "Let there is an array. How to remove all elements with value 3 from >> it?" >> >> this question allows to check whether the candidate knows that >> "length" is being modified every time when he will be splicing/ >> deleting items, and therefore direct for-loop isn't fit. >> > Sure, splice modifies length. Is that not what you want? > As Richard mentioned, it doesn't matter if you loop backwards.
From: Swifty on 8 May 2010 02:56 On Fri, 7 May 2010 22:50:08 -0600, "Mel Smith" <med_cutout_syntel(a)aol.com> wrote: >What's the difference between a Duck ? See: http://www.swiftys.org.uk/wiz?1461 -- Steve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk
From: Ry Nohryb on 8 May 2010 03:53 On May 8, 6:56 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > Strike #3. Get out of my office. :) > > Seriously, instead of pretending IE does not exist, why not pretend the > same of things like __proto__? Version 4: Explorer-compliant: no NFEs, nor usage of __proto__. var subClase; var clase= (function (instances, values, clase) { clase.getPrivate= function () { return values[instances.indexOf(this)] }; subClase= function (private) { instances.push(this); values.push(private) }; return (subClase.prototype= clase) })([], [], {}); var a= new subClase(33); var b= new subClase({}); [a.hasOwnProperty("getPrivate"), b.hasOwnProperty("getPrivate")] --> [ false, false ] [a.getPrivate(), b.getPrivate()] --> [ 33, {} ] -- Jorge.
From: Dmitry A. Soshnikov on 8 May 2010 09:21
On 07.05.2010 17:30, Richard Cornford wrote: > On May 7, 1:27 pm, Dmitry A. Soshnikov wrote: [...] > >> Or is it about "The Most Challenging Interview Question"? > > That is the subject, but it is not entirely clear whether the > intention is the discussion of the most challenging question that one > may ask a potential employee/colleague while interviewing them, or the > question one may find most challenging when being interviewed. My > initial interpretation favoured the latter, but closer inspection > suggests that the subject may be more ambiguous than I had first > assumed. > Ah, yeah, I just understood it in the alternative view which you mentioned. But yes, your interpretation fits also for the topic's title. >> (just want to warn irrelevant discussion on 10 pages in the >> 100-th time repeating all the same about jQuery). >> >> If you going to make interview and test the candidates for work, >> you should do this depending on your current project(s) (if the >> project is big and isn't being changed in a time -- year or two). > > So you are interpreting this as the most challenging question to ask a > potential employee/colleague while interviewing them. > Yes, I did. But the only thing I wanted to mention is that there is no sense to transform the topic about interview questions to the again-and-again discussion of the jQuery. >> Of course there is a sense to test the basic (but deep) knowledge >> of the technology as well. > > It is unrealistic to expect deep technical knowledge from most > candidates for javascript related web development jobs. When I was > interviewed by my current employers the job I applied for was > advertised as requiring a "javascript expert" (realistically, as that > is exactly what was needed), and I was given a 'technical test' that > was so rudimentary (cantered around really basic cross-browser DOM > interaction questions) that I thought that anyone who did not get 100% > on that test had no business applying for a javascript/browser > scripting job in the first place, let alone presenting themselves as a > "javascript expert". It turned out that one of the (main) reasons that > I was offered the job was that I was the only candidate interviewed > who had achieved better than 50% on that, so called, technical test > (where the contrast between those scores and my 100% suggested that > finding more candidates to interview would not be a worthwhile > exercise). That is; the vast majority of people applying for jobs > starting "javascript expert" as a requirement are not even capable of > getting the basics right. > I see. And actually the problem of a (some) knowledge is that it relatively-acceptable with some relative levels. When you've just started to learn JS (more-less) deeply -- did you recognize _completely_ the level of your knowledge at the moment? For this should be some "model", a "standard" -- to compare your relative knowledge with this (also a relative, but the absolute in particular case) "standard". The good "model" in this case of course can be a specification. But we also shouldn't forget that technical specifications are exactly technical specifications (ideally, just a set of concrete algorithms how and why to do something) for implementers. From this viewpoint an abstraction level of the spec is lower and user of the JS itself aren't obliged to know it. So that "javascript expert" position is just a relatively acceptable for your employers. And being on some relative level of the knowledge, they cannot (or maybe don't want to) to dig deeper. Fairly, if some "dig out" some deeper knowledge (examined the specification), this position -- a "javascript expert" is being appeared as a novice/middle level. So, don't be worry about that. In every technology there are always novice/middle/expert levels programmers. And with every of this level _depending on required and at the same time acceptable level of the knowledge_ can be a position with the same title -- "javascript expert". Of course, quantity of the real experts (which I recognize as deep theoretical knowledge + the big practical experience) not so many; a few -- in every technology. > I wonder how this comes about. Is it really widespread misperception > of their own abilities on the parts of the applicants; an unfounded > overconfidence? Depends (psychologically) on concrete human type. Also depends on what I've described above -- acceptable (for himself) level of the knowledge. Some just try, other -- not. Or could it be a general attitude of 'trying it on', > and these individuals do appreciate that they don't really qualify but > are willing to try to bluff their way through the interview. Yep, can be also. The methods of achiving the result can vary. Myabe some just learned on such "tries". Personally, I try always _not to try_ (not to guess), but to beat for sure -- i.e if don't know -- do not talk in statement forms _or_ -- talk in questionable form, asking and collecting the knowledge. Of course, if some knowledge region isn't examined well and can be some inventions -- exactly _intuitive tries based on previous experience_ can be the main progress engine and here that "tries to guess" are welcome. > Then it > could be that this is a manifestation of a general contempt for the > employers; that when they say "javascript expert" they don't really > know what they need but had to write something. > >> Don't forget that questions are depended on the type of the >> position. If this is position of some theoretical analytic >> than of course there is a sense to ask some deep theoretical >> question. If the position is mostly practical and you still >> want to test some more-less deep knowledge, then can be >> questions related on features of the technology. > > Given what I wrote above, while gauging the range of technical > understanding possessed by a candidate for this second class of job > will be useful, I think it would also be valuable to attempt to find > out how they react to being presented with boundaries of their > knowledge. This approach can be used of course -- to find out which level of job can be charged for this employee. > Will they recognise their mistakes when shown, will they > attempt to bluff, are they interested in the 'correct' answer; in > learning from it. Yes, it depends on the levels: professional, educational, and psychological type. > That is, is this an individual who can/will use the > "mostly practical" position to learn enough to move towards the > "theoretical analytic" position? > Yes, indeed. >> The simplest but allowing to test whether the candidate >> understands what he's taking about e.g. >> >> "What does result alert(this)?" >> >> without mentioning the context of the question -- let the >> candidate will explain all this himself. >> >> Or, more practical: >> >> "Let there is an array. How to remove all elements with >> value 3 from it?" >> >> this question allows to check whether the candidate knows >> that "length" is being modified every time when he will be >> splicing/deleting items, and therefore direct for-loop >> isn't fit. > > I assume that "direct for-loop" means an incrementing index, as a for > loop with a decrementing index doesn't see the issue. Yes, that exactly I meant. Dmitry. |