The Most Challenging Interview Question

[Garrett Smith]

Hi Everybody,

What is your most challenging interview question?

Mine:
"What do you think of jQuery?"

 

[Ry Nohryb]

Hi Everybody,

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.

 

[David Mark]

Hi Everybody,

What is your most challenging interview question?

Mine:
"What do you think of jQuery?"

A. I try not to.

If I still went to job interviews (thank God I'm past that at this
stage), I'd dread the "What's your favorite JS library" standard. Uh,
mine? I don't think that would work with a typical HR type. They'd
probably Google it and say "aw, UR just jealous coz..."

 

[David Mark]

A: It's a library that attempts to provide a better browser API.

Attempted and failed (miserably). Have you looked at their API? 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?

 

[Ry Nohryb]

Attempted and failed (miserably).  Have you looked at their API?  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?

It's the truth, and a very diplomatic way of putting it, imo.

 

[Richard Cornford]

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.

Richard.

 

[Dmitry A. Soshnikov]

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"?

(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). Of course there
is a sense to test the basic (but deep) knowledge of the technology as
well.

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. 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 can propose a very deep theoretical question which will fail the
candidate -- but what the sense if we need a good practical
programmer? So, all this depends.

Of course, question on philosophy (such as yours -- about jQuery) can
be also.

Dmitry.

 

[Michael Haufe (\TNO\)]

Hi Everybody,

What is your most challenging interview question?

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:

function Foo(a){
...
var _foo = a
...
}

how would you use prototypical inheritance so that the following is
possible:

var obj1 = new Foo("one"),
obj2 = new Foo("two");

obj1.thing() //"one"
obj2.thing() //"two"

 

[Michael Haufe (\TNO\)]

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:

function Foo(a){
    ...
    var _foo = a
    ...

}

how would you use prototypical inheritance so that the following is
possible:

var obj1 = new Foo("one"),
    obj2 = new Foo("two");

obj1.thing() //"one"
obj2.thing() //"two"

An addendum for those playing at home and want to try: the "thing()"
method should be declared only once.

 

[Richard Cornford]

Is this thread the discussion of jQuery library or I missed
something?

It isn't a discussion of JQuery, though that may happen. In principle
the question would be just unpleasant if its subject were
Prototype.js, Dojo, ExtJS, etc, etc.

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.

(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.

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 wonder how this comes about. Is it really widespread misperception
of their own abilities on the parts of the applicants; an unfounded
overconfidence? 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. 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. Will they recognise their mistakes when shown, will they
attempt to bluff, are they interested in the 'correct' answer; in
learning from it. That is, is this an individual who can/will use the
"mostly practical" position to learn enough to move towards the
"theoretical analytic" position?

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.

I can propose a very deep theoretical question which will fail the
candidate -- but what the sense if we need a good practical
programmer?

To find out how the candidate responds to having limitations in their
knowledge exposed.

So, all this depends.

Of course, question on philosophy (such as yours -- about
jQuery) can be also.

The question wasn't mine, rather I proposed one possible approach to
(not) answering it.

Richard.

 

[John G Harris]

Q: How would you implement a constructor that inherits a method from
it's prototype that has access to it's instance private variables?

<snip>

I'd point out, politely I hope, that you wrote the question without
enough proof-reading

Although a constructor can inherit a method from it's [sic] prototype
there isn't much point in its doing so, and there's no way a
constructor's method can access an instance's data before that data has
been created. Also, I'd ask what you mean by 'private'.

John

 

[Ry Nohryb]

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:

function Foo(a){
    ...
    var _foo = a
    ...

}

how would you use prototypical inheritance so that the following is
possible:

var obj1 = new Foo("one"),
    obj2 = new Foo("two");

obj1.thing() //"one"
obj2.thing() //"two"

I'll bite...

var clase= (function claseBuilder () {
var instances= [];
var getters= [];
var clase= {};

clase.getPrivate= function () {
return getters[instances.indexOf(this)]();
};

clase.pushGetter= function (instance, getter) {
instances.push(instance);
getters.push(getter);
};

return clase;
})();

function subclase (private) {
o= {};
o.__proto__= clase;
clase.pushGetter(o, function () { return private });
return o;
}

var a= subclase(33);
var b= subclase(27);

[a.hasOwnProperty("getPrivate"), a.hasOwnProperty("getPrivate")]
--> [ false, false ]
[a.getPrivate(), b.getPrivate()]
--> [ 33, 27 ]

 

[nick]

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.

Sorry, Michael, but this is like the 20th time I've seen this mistake
on cljs in the last 24 hours or so... figured it was time to say
something.

 

[VK]

Hi Everybody,

What is your most challenging interview question?

Mine:
"What do you think of jQuery?"

IMO it is challenging for c.l.j. only - in the aspect to say about
jQuery the most nasty things in the most nasty way to fully satisfy
some regulars and "regulars" pseudo-ethical needs yet do not touch
occasionally in any shall perform way the preferred coding and
structuring habits of neither one of them. ) :-|

Presuming the purpose of any job interview being to get the job and
not to make a loud public statement about one's personal preferences -
presuming that the challenge gets much easier.
Learn company's profile. Visit their website and study the used
internal coding. Study the version vector using the Wayback Machine
( http://www.archive.org/web/web.php ). Whatever is abandoned or
changed - it happened for a reason. Even if that reason was a CFO's
wife occasional complain that "these thingies are looking kinda yaky,
darling..." - it is a hell of important reason to not promote those
"thingies" right at the moment. At the hot bloody summer of 1998 the
customer company's CEO was a fan of IE4 and CFO was a fan of NN4. The
challenge was to please both while talking about browsers with both
sitting in front of you. That was a challenge. This is just a light
mind gim.
a) Mention your concerns (w/o any explicit judgment) about $()
function compatibility between jQuery and Prototype.js (
http://docs.jquery.com/Using_jQuery_with_Other_Libraries )
This way you show that you are neither a jQuery fan nor a jQuery
hater, but a open-minded professional. Remember that no one want a
rwar fanatic on board.
b) Mention some most recent jQuery bug for a recent version of 2nd
wave browsers (Safari, Chrome, Opera): http://dev.jquery.com/timeline/
This way you show your timely response to the browser market dynamics.

Relax and wait for the next question.

 

[Ry Nohryb]

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:

function Foo(a){
    ...
    var _foo = a
    ...

how would you use prototypical inheritance so that the following is
possible:

var obj1 = new Foo("one"),
    obj2 = new Foo("two");

obj1.thing() //"one"
obj2.thing() //"two"

I'll bite...

var clase= (function claseBuilder () {
  var instances= [];
  var getters= [];
  var clase= {};

  clase.getPrivate= function () {
    return getters[instances.indexOf(this)]();
  };

  clase.pushGetter= function (instance, getter) {
    instances.push(instance);
    getters.push(getter);
  };

  return clase;

})();

function subclase (private) {
  o= {};
  o.__proto__= clase;
  clase.pushGetter(o, function () { return private });
  return o;

}

var a= subclase(33);
var b= subclase(27);

[a.hasOwnProperty("getPrivate"), a.hasOwnProperty("getPrivate")]
--> [ false, false ]
[a.getPrivate(), b.getPrivate()]
--> [ 33, 27 ]

Version 2:

var subClase;
var clase= (function claseBuilder (instances, getters, clase) {
clase.getPrivate= function () {
return getters[instances.indexOf(this)]();
};
subClase= function subClaseBuilder (private, o) {
(o= {}).__proto__= clase;
instances.push(o);
getters.push(function () { return private });
return o;
};
return clase;
})([], [], {});


var a= subClase(33);
var b= subClase(27);


[a.hasOwnProperty("getPrivate"), b.hasOwnProperty("getPrivate")]
--> [ false, false ]
[a.getPrivate(), b.getPrivate()]
--> [ 33, 27 ]

 

[Ry Nohryb]

I'll bite...

var clase= (function claseBuilder () {
  var instances= [];
  var getters= [];
  var clase= {};

  clase.getPrivate= function () {
    return getters[instances.indexOf(this)]();
  };

  clase.pushGetter= function (instance, getter) {
    instances.push(instance);
    getters.push(getter);
  };

  return clase;

function subclase (private) {
  o= {};
  o.__proto__= clase;
  clase.pushGetter(o, function () { return private });
  return o;

var a= subclase(33);
var b= subclase(27);

[a.hasOwnProperty("getPrivate"), a.hasOwnProperty("getPrivate")]
--> [ false, false ]
[a.getPrivate(), b.getPrivate()]
--> [ 33, 27 ]

Version 2:

var subClase;
var clase= (function claseBuilder (instances, getters, clase) {
  clase.getPrivate= function () {
    return getters[instances.indexOf(this)]();
  };
  subClase= function subClaseBuilder (private, o) {
    (o= {}).__proto__= clase;
    instances.push(o);
    getters.push(function () { return private });
    return o;
  };
  return clase;

})([], [], {});

var a= subClase(33);
var b= subClase(27);

[a.hasOwnProperty("getPrivate"), b.hasOwnProperty("getPrivate")]
--> [ false, false ]
[a.getPrivate(), b.getPrivate()]
--> [ 33, 27 ]

Version 3:

This one, however, duplicates the private values, which is not a Good
Idea™, i.e. if private were a 150MB string... BAD.

var subClase;
var clase= (function claseBuilder (instances, values, clase) {
clase.getPrivate= function () {
return values[instances.indexOf(this)];
};
subClase= function subClaseBuilder (private, o) {
(o= {}).__proto__= clase;
instances.push(o);
values.push(private);
return o;
};
return clase;
})([], [], {});


var a= subClase(33);
var b= subClase({});


[a.hasOwnProperty("getPrivate"), b.hasOwnProperty("getPrivate")]
--> [ false, false ]
[a.getPrivate(), b.getPrivate()]
--> [ 33, {} ]

 

[VK]

On May 7, 2:54 pm, "Michael Haufe (\"TNO\")"
Hi Everybody,
What is your most challenging interview question?
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:
function Foo(a){
    ...
    var _foo = a
    ...
}
how would you use prototypical inheritance so that the following is
possible:
var obj1 = new Foo("one"),
    obj2 = new Foo("two");
obj1.thing() //"one"
obj2.thing() //"two"
I'll bite...
var clase= (function claseBuilder () {
  var instances= [];
  var getters= [];
  var clase= {};
  clase.getPrivate= function () {
    return getters[instances.indexOf(this)]();
  };
  clase.pushGetter= function (instance, getter) {
    instances.push(instance);
    getters.push(getter);
  };
  return clase;
})();
function subclase (private) {
  o= {};
  o.__proto__= clase;
  clase.pushGetter(o, function () { return private });
  return o;
}
var a= subclase(33);
var b= subclase(27);
[a.hasOwnProperty("getPrivate"), a.hasOwnProperty("getPrivate")]
--> [ false, false ]
[a.getPrivate(), b.getPrivate()]
--> [ 33, 27 ]

Version 2:

var subClase;
var clase= (function claseBuilder (instances, getters, clase) {
  clase.getPrivate= function () {
    return getters[instances.indexOf(this)]();
  };
  subClase= function subClaseBuilder (private, o) {
    (o= {}).__proto__= clase;
    instances.push(o);
    getters.push(function () { return private });
    return o;
  };
  return clase;

})([], [], {});

var a= subClase(33);
var b= subClase(27);

[a.hasOwnProperty("getPrivate"), b.hasOwnProperty("getPrivate")]
--> [ false, false ]
[a.getPrivate(), b.getPrivate()]
--> [ 33, 27 ]

Version 3:

This one, however, duplicates the private values, which is not a Good
Idea™, i.e. if private were a 150MB string... BAD.

var subClase;
var clase= (function claseBuilder (instances, values, clase) {
  clase.getPrivate= function () {
    return values[instances.indexOf(this)];
  };
  subClase= function subClaseBuilder (private, o) {
    (o= {}).__proto__= clase;
    instances.push(o);
    values.push(private);
    return o;
  };
  return clase;

})([], [], {});

var a= subClase(33);
var b= subClase({});

[a.hasOwnProperty("getPrivate"), b.hasOwnProperty("getPrivate")]
--> [ false, false ]
[a.getPrivate(), b.getPrivate()]
--> [ 33, {} ]

Holly Mother of Lord, can you just decide if you need static or
impersonated methods and where?! Really, it is a design time human
decision - not a runtime engine problem of any kind. :-|

C++'ers and Java'ers used to treat the memory as an endless sh**, but
JavaScript provides and expects more nice and professional treatment,
moreover it requires almost zero efforts.
With the Cornford-Crockford scope management (a.k.a. CC scope
management, the name order is alphabetical) you are making right now
the crucial question for each method is: "I do not care about the
previous call state for this method for this class instance or do I?".
In the first case it is static in VBA sense. 99% of your methods
should be static in the mentioned sense. The opposite indicates a
wrong programming paradigm. Otherwise it may be crucial to know the
previous onExit state of the method for that particular instance or
even the whole instance state at the moment onExit from that method
(impersonated method). It is very memory costly and it must be used
only when you really need it - not everywhere as a common programming
paradigm.

 

[Scott Sauyet]

Argh! "Its" ... "its" ... "its."

It's a declension. Not possessive, not a contraction. Like "his" or
"her," it needs no apostrophe.

This mistake has it's opponents but really its no big deal.

 

[nick]

This mistake has it's opponents but really its no big deal.  

Ooh, that was dirty.

 

[Thomas 'PointedEars' Lahn]

An addendum for those playing at home and want to try: the "thing()"
method should be declared only once.

If you are saying that there are trick questions in job interviews, I agree.

If instead you are implying that there is a solution to the problem as
stated (spelling errors notwithstanding), you should post your solution so
that one can assess whether the problem is properly stated and your solution
makes sense.


PointedEars