M
Michael Haufe (\TNO\)
I'd point out, politely I hope, that you wrote the question without
enough proof-reading
True enough.
Not in the normal sense you are thinking, no.
Not directly accessible.
True enough.
Not in the normal sense you are thinking, no.
Not directly accessible.
M
Michael Haufe (\TNO\)
Fair criticism, I should have proof read.
M
Mel Smith
Interview question:
What's the difference between a Duck ?
What's the difference between a Duck ?
D
David Mark
Ry said:Version 2: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 ]
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, {} ]
--
Strike #3. Get out of my office.
Seriously, instead of pretending IE does not exist, why not pretend the
same of things like __proto__?
G
Garrett Smith
Nope.
Technical questions and comments are usually threatening to a jQuery
developer who has not looked at the source code.
Not hired.
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.
[...]
Testing unspecified host method string conversion seems unreasonable;
nothing can be guaranteed to be expected.
What result is wanted?
var a = [3,1,2,3,4,3,4,5,3];
removeThrees(a);
a
=> ?
Technical questions and comments are usually threatening to a jQuery
developer who has not looked at the source code.
Not hired.
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.
[...]
Testing unspecified host method string conversion seems unreasonable;
nothing can be guaranteed to be expected.
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
=> ?
D
David Mark
Garrett said:
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.
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 upfor me.
I think the point was that, without context, you don't know what - this
- is.
As Richard mentioned, it doesn't matter if you loop backwards.
R
Ry Nohryb
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, {} ]
D
Dmitry A. Soshnikov
Ah, yeah, I just understood it in the alternative view which you
mentioned. But yes, your interpretation fits also for the topic's title.
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.
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.
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',
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.
This approach can be used of course -- to find out which level of job
can be charged for this employee.
Yes, it depends on the levels: professional, educational, and
psychological type.
Yes, indeed.
Yes, that exactly I meant.
Dmitry.
D
Dmitry A. Soshnikov
If would be a good answer though, if you answered so. Then I can check
that you before the talking about this `this` value, clarify some other
deep question.
But at the same time, I mention that you didn't get the _main_ point of
the question, but started to talk first about some irrelevant thing.
I.e. it could seem that you didn't understand the question about exactly
`this`, but talking about some `alert` about which an employer isn't
asking. So, be careful, your (even fair and good attempts to show that
you _additionally_ knows also something other) can be treated in
different way that you thought.
Nevertheless, in general -- yes, as a short addition it will be good to
mention _clarifying_ stuff.
And I was interested of course about whether an employee knows `this`
value topic. And term "context" meant not even execution contexts, but
"all possible situations related with `this` value".
I've heard even answers such as: "Hum... what.. ? [object Window]..".
Such employee nevertheless can be also a good practical programmer.
Another talk, if an employee starts his speech from the e.g. "`this`
value determines on entering the context and depends on...". That's it
-- this is another relative knowledge level.
Yes, exactly this I meant. Such small practical examples can help to
test also some theoretically-piratical aspects.
No matter what will you use, the issue is to remove all 3. It can be:
[1,2,4,4,5] or
[,1,2,,4,,4,5,]
Dmitry.
M
Mel Smith
What's the difference between a Duck ?
Sorry, the answer is:
"One of its legs is both the same."
(and note the correct usage of "its" )
You guys 'quack me up' !
but enough already
-Mel
Sorry, the answer is:
"One of its legs is both the same."
(and note the correct usage of "its" )
You guys 'quack me up' !
but enough already
-Mel
J
John G Harris
<snip>
It turns out you're interviewing Douglas Crockford. He gives you a two
hour lecture on how constructors are evil, evil, evil.
John
G
Garrett Smith
To clarify, I did not mean "Nope I haven't," I meant it as negative
acknowledgment of that answer in an interview.
That is only relevant when the interviewer is a jQuery core developer.
[...]
Most use jQuery these days; so it's pretty hard to both avoid.
[...]
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.
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.
Where supported:
[3,1,2,3,4,3,4,5,3].filter(function(i){
return i !== 3;
})
If, given the aforementioned array with the removeThrees function below:
var a = [3,1,2,3,4,3,4,5,3];
removeThrees(a);
a now has elements: [1, 2, 4, 4, 5].
function removeThrees(array) {
var b = a.slice(),
j = 0,
i = j,
el;
for(; i < b.length; i++) {
el = b;
if(el !== 3) {
a[j++] = el;
}
}
a.length = j;
return a;
}
I can't see how using `splice` in a forwards loop would be a problem at
all. I find that approach to be easy to understand and I use it in my
own code.
acknowledgment of that answer in an interview.
That is only relevant when the interviewer is a jQuery core developer.
[...]
Most use jQuery these days; so it's pretty hard to both avoid.
[...]
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.
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.
Where supported:
[3,1,2,3,4,3,4,5,3].filter(function(i){
return i !== 3;
})
If, given the aforementioned array with the removeThrees function below:
var a = [3,1,2,3,4,3,4,5,3];
removeThrees(a);
a now has elements: [1, 2, 4, 4, 5].
function removeThrees(array) {
var b = a.slice(),
j = 0,
i = j,
el;
for(; i < b.length; i++) {
el = b;
if(el !== 3) {
a[j++] = el;
}
}
a.length = j;
return a;
}
I can't see how using `splice` in a forwards loop would be a problem at
all. I find that approach to be easy to understand and I use it in my
own code.
D
Dmitry A. Soshnikov
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.
You still talk about irrelevant thing; meanwhile Mark has understood it
correctly. I repeat, it is doubtful what is better -- to mention such
long detailed but irrelevant explanation of "alert" or not. An employer
can listen to this reply, make some marks (e.g. "didn't get the main
goal of the question right away" or "a good clarification addition
before the answering the main goal of the question; possible, he likes
to debate -- and no matter about what" -- it depends on an interviewer
and an employer).
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.
Yes, repeat, such small questions just allow to test how will an
employee solve the issue, analyzing he's solution.
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
Dmitry.
D
David Mark
Dmitry said:
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.
D
David Mark
Garrett said:
I'm not talking about interviewers. For that matter, I generally don't
talk to interviewers at all.
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).
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.
D
David Mark
Stefan said:
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!
G
Garrett Smith
Dmitry said:
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.
[...]
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.
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.
D
David Mark
Garrett said:
But I wasn't talking to the "interviewer". IIRC, I was commenting on
Jorge's answer.
It appears something has gone horribly wrong with the quoting.
VK posted good advice? Must be the end of the world.
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.
Actually, it sounds like a good answer to me (unless the firm is so
deluded as to be looking for a blanket jQuery recommendation).
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.
I'm very familiar with jQuery and I wouldn't trust it to mow my lawn.
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.
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.
C
Chris F.A. Johnson
Until around the beginning of the 19th century, "it's" was
the usual form.
G
Garrett Smith
David said:
Huh. Now I'm confused, but whatever...
Dmitry wrote ^^^^^^^^^^^^^^^^^^^^^
Garrett wrote ^^^^^^^^^^^^^^^^^^^^^
David wrote ^^^^^^^^^^^^^^^^^^^^^It appears something has gone horribly wrong with the quoting.
Slighly, but not horribly wrong.
[...]
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.
Send the interviewer packing?
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.
[...]
Also people don't always think or act the same when they're nervous,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
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.
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.