The Most Challenging Interview Question
in [JavaScript]
|
From: David Mark on 8 May 2010 16:39 Dmitry A. Soshnikov wrote: > 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. > The common cries against repetition are ill-founded. There are new readers every day and they don't typically read past messages, so repetition is required. It may bore regulars, but it's not for their benefit. Just skip posts that bore you. ;)
From: David Mark on 8 May 2010 16:47 Garrett Smith wrote: > David Mark wrote: >> 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. >>> > > To clarify, I did not mean "Nope I haven't," I meant it as negative > acknowledgment of that answer in an interview. > >>> 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. >> > > That is only relevant when the interviewer is a jQuery core developer. I'm not talking about interviewers. For that matter, I generally don't talk to interviewers at all. > > [...] > >>>> >>> 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. > > Most use jQuery these days; so it's pretty hard to both avoid. No it isn't. I work as a consultant. I suppose some of my initial meetings are interview-like, but they certainly aren't asking me about my opinion of jQuery (more like my opinion of whatever they fouled up with jQuery or Dojo or whatever and how long it will take to put it right). > > [...] > >>>> "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. >> > > > The problem with the question: "What does result alert(this)?" > > is that it requires too detailed assumptions to answer correctly. > > The alert method accepts a string and displays that in a dialog box to > the user with a button that, when activated, closes it. > > What `alert` does when supplied with a value that is not a string value > is not specified. Observations may show that implementations perform a > conversion, however undocumented, to get a string value from that value. > How that string value is obtained is not documented. > > The behavior of the alert method is not specified in any standard. > Implementations may vary. If the focus is on string conversion of the > `this` value, then use that, e.g. > > var selfString = String(this); > alert(selfString); > > - is acceptable. > >>>> 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. > > Before the question can be answered, the expected outcome needs to be > stated clearly. I can think of a couple of forward loop solutions, one > using splice, one using concat. A reverse loop solution did not occur to > me. > 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.
From: Stefan Weiss on 8 May 2010 17:30 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. -- stefan
From: David Mark on 8 May 2010 18:42 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. > > Sure enough. Apparently I haven't been paying close enough attention to this discussion as I thought the original question was how to clear _all_ elements from an array, and wondered why nobody suggested:- a.length = 0; Looking again, the poster of the question mentioned something about delete/splice (both?) mutating the length of the array. Clearly, presuming a sparse result is acceptable, the delete operator can be used in a standard for loop in either direction. But if a sparse result is disallowed, then you are relegated to splice and looping in reverse would seem the simplest way to go. I suppose something like this:- var a = [...], j, i = a.length; while (i--) { j = i; while (j >= 0 && a[j] == 3) { j--; } if (j != i) { a.splice(j + 1, i - j); } i = j > 0 ? j : 0; } That's a little ugly. Could be re-factored in any number of ways. Granted, the typical JS "expert" applicant couldn't write a solution for this problem in a month, even with a debug console handy. Memorizing jQuery's latest patterns (which seem to change monthly) is pretty far removed from programming (it's closer to playing video games). Furthermore, the ability to leverage the language to perform this feat says zero about the applicant's ability to solve browser scripting problems. There are comparatively many skilled JS programmers out there. But how many of them can write reliable cross-browser applications? In other words, you can memorize where the tools are in the shed, but you still have to know what to do with them (which comes primarily from practical experience). Of course, the typical jQuery jockey can only pretend to solve such problems. Look ma, no work! :)
From: Garrett Smith on 8 May 2010 19:40
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. [...] >> >> 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. > 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. Discussing problems and asking back "have you looked at the source code" doesn't work. 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. 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. People trust things that are familiar. 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." "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. [...] > > 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |