Hacker News new | ask | show | jobs
by steven777400 4567 days ago
We were hiring a non-senior full-stack developer recently and I noticed there were no "frontend" questions on the list, so I added what I thought would be a question that any developer with frontend experience could answer, and would also pave the way for some more interested discussions for an advanced candidate. The question was something to the effect of "In JavaScript, what is the value of 'this' in a method?"

I would have accepted an answer as simple as "The value of 'this' depends on how the method is called" or even "The value of 'this' confuses me because it's often not what I expect."

It was a disaster. We may as well not have asked the question at all. Nobody seemed to even be aware of anything about it.

13 comments

> It was a disaster. We may as well not have asked the question at all. Nobody seemed to even be aware of anything about it.

You have it backwards. It would have been a disaster if you didn't ask the question and hired someone who doesn't know basic JS fundamentals.

I've been doing Javascript for a few years and recently answered a few StackOverflow questions. One was regarding "this".If anyone wants to hire my ass feel free to contact me. One of my techniques for learning has been by going on interviews and flopping, then going back and learning all the interview question material on my own time. Wash and repeat.I've been doing this bullshit since the first day I started teaching myself. It all began with an interview that required knowledge of strictly HTML & CSS. Suffice to say after I tried to mimic an unordered list with 12 div blocks I didn't get the gig. Things are better now. I promise! Where am I? Whats this padded wall doing here? !!!!
If you're looking, we are still hiring for a third position (we've been on a bit of a binge lately with hiring). http://agency.governmentjobs.com/washington/default.cfm?acti...
Thanks. I'll fill it all out in the next 24 hours
I found this heartening. I've recently transitioned from Mechanical Engineering to Web Dev and am beginning to interview. Just had my first interview, and I feel like everything discussed made me better.
I literally make an ass out of myself half the time. Feel free to join in. You're not alone.
This is a great, great idea. Thank you for the tip.
It only works if you have a shit ton of humility. The problem is there is really no other way I've found to acclimate oneself with the assumptions and culture of the discipline in a manner that is real-world and cuts through the small talk/cruft .

Your welcome btw...have fun :/

To the people who wish they could answer that question with confidence, I recommend getting this book:

http://www.amazon.com/Effective-JavaScript-Specific-Software...

Just got it and I feel like it clarified so many things about Javascript that I didn't have down cold as a self-taught pragmatist.

I felt Effective Javascript was pretty on par with The Good Parts, and even better in some aspects.
I concur. I recently finished Effective JavaScript, and found it to be an excellent and insightful read.
I'll 4th this recommendation thread for those still on the fence. This and also Secrets of the Javascript Ninja.
I hate HN. Instead of watching action flicks on flights I now read books picked up from HN threads. I've got Platinum Medallion this year and I'm still behind my reading queue.
Agreed. I cannot recommend that book enough. It's a natural extension of The Good Parts and should be considered required reading (in the same way that Effective Java is for Java developers).
I always include something around `this` behaviour in my interviews if the position is Javascript related. You cannot possibly have a decent experience in JS without have been bit by this.

And I'm always amazed by the amount of developers that just do not understand how it works, and bind every possible methods.

Anyone who claims to know JS and doesn't have "this" down cold is either a disaster waiting to happen, or a disaster in progress.
Sorry, but the semantics of "this" in JavaScript are crazy — and I think that's being generous. There are a few common use cases that trip people up, e.g., situations where "this" becomes bound to another object like the global window object, and I'd expect an experienced JavaScript programmer to know those.

It depends on what you mean by "down cold," obviously, but if your standard is "either they have the semantics of the 'this' keyword down cold or they're incompetent" then virtually all JavaScript programmers I know (including myself) are incompetent.

Now, hold on there. These "anyone who" statements chafe me; like the junior dev who exclaimed "anyone who doesn't write unit tests shouldn't call themselves an engineer" in a meeting filled with people 15 years his senior who had collectively shipped far, far more successful software than him, without writing tests.

Several years ago, I led two different front-end web teams at a large, well-known company. I wrote a lot of JavaScript then. In fact, I wrote the core JS framework for one of the apps. I probably understood "this" at that time. I couldn't begin to tell you now, because I've been working on hit iOS games since - probably without knowing a lot of the nuances of Obj-C at times! There was no disaster back then - we shipped high-quality sites on time. There would be no disaster now, because if I went back to JS I'd crack a book.

The most important skills I bring to any project are a lot higher-level than the details of a particular language. I haven't made my career on one language or platform, but dozens of them. For the details, I work with reference material handy. After a month, I probably have a good grasp of whatever I'm working with. A year after that project, I probably don't, but I could bring it back easily.

That's cool. But don't write JS if you don't know what this does, because it will bite you.
Or just avoid using `this` unless you're sure about what it does in a particular context.
Or just learn what 'this' means because, seriously, you're a programmer and it's not that hard to figure out.
It's only upon reflecting upon "this" recently that I realized that it is (effectively) a global (thread-local) variable set by the X.Y() syntax. (I mean, I understood to be the case, but I just didn't realize the impliciations for understanding "this".)

The ECMAScript committe are taking steps to make "this" more useful, but the current semantic is so insane that I don't it's particularly surprising that people who aren't language lawyers don't understand it.

(*) Given that Javascript uses a single-threaded model.

Likewise, I ask it also. When someone has spent the last 3 years as a "JavaScript developer" and doesn't have a basic grasp of context in JS, them it's a red flag.
From the top of my head, from someone who currently seeks work as a full stack (Rails) developer:

I would ask if you by "method" mean function defined on an object. If so, this refers to the method's object. If not, this can take on 5 values. In the global scope it is the global object; in a constructor it is the newly created object; in a function (not defined on an object - and also goes for functions defined within methods defined on objects) it is the global object; in a method (defined on object) it is the object, and finally it can be set explicitly with functions like call and apply.

How did I do? (Serious question. I think my answer is good, but I also struggle with a serious form of imposter syndrome.)

I did mean "function defined on an object". Your answer would have been way ahead of everyone else because no one else had an answer. :)

I would also add, though, that function definition is not the critical aspect to define this. The value of this primarily varies based on how the function is called, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Not quite right. :-) JavaScript is not truly OO. You can have a prototype method called from a callback and find that 'this' will not necessarily be the value of the object it was prototyped onto.

It's really tricky, and I often have to .bind functions after I've noticed they're not working.

I've been in this position also. Same question. I also added what the difference between setTimeout() and setInterval() is, and example usages of both. It's incredible that a question where the primary answer is right there in the function names causes such confusion on people that are supposedly "front end engineers with years of experience".

Off course, disaster is an understatement. All three questions where the demise of 100% of our interviewees. We ended up hiring a sql programmer and teaching him what he needed to know.

Heh. The second question makes me feel a lot better about my JS knowledge. I could probably answer what 'this' is when given some code (eg are we inside a class? or a jquery event handler?) but would be hard pressed to discuss it in the abstract... whereas setTimeout and setInterval have specific differences to point to.
I'm curious, should answering this question be expected of a non-senior dev? This kind of knowledge is acquired by running into broken code - that is, by chance. I'd think someone with a couple years experience only could conceivably not, for example, have called a method directly and had this refer to a global object instead. Until then one might just assume Javascript's this works like this in other languages. In fact, that's what I did until your post just made me look it up (though I only code for side projects, not professionally).

I'm also surprised to hear that people learn jQuery and omit Javascript. Personally I resisted using jQuery because I didn't understand what was happening nor would you read the code easily. Plus, it was actually extra work because if you knew another language you could pick up Javascript easily. With only jQuery you are pretty much limited to what's already made for you.

If anyone wants to look at one of my sites, I'd be curious how I stand as a developer.

http://www.sudokuisland.com/

!!!!

This kind of knowledge is acquired by reading 'Javascript the Good Parts'. It goes without saying that someone who considers themselves a good frontend engineer has read this book.

edit: I am a frontend tech lead (not even in SV!!) and my most junior engineer will answer the question correctly. I can't even fathom how one could contribute to a non-toy app without knowing this.

People tend to remember things that they do, not what they read, much less from what they hear in lecture. The odds that I'm right is high because nobody was able to answer the question satisfactorily.
I had to do a short javascript project at work and the differences between the various function invocations was one of the first things I learned. That and how to deal with the disastrous scoping issues.
This kind of knowledge is super basic, so yes, I'd expect anyone interviewing for a front-end position to know the meaning of 'this.'
The answer the interviewer was looking for seems to expect knowledge of how 'this' is different in Javascript versus other languages, and how things can go wrong. That is different from simply knowing that 'this' refers to an object.

Since this is for a junior position, conceivably an applicant could be a recent CS grad with no formal JS training, and hacked some projects on a side or job. And thus never by happenstance run into this issue, even if he read it somewhere sometime.

As someone that is self-taught via books, websites and finding stuff out on Stackoverflow, etc. I feel like everyone should know this. I hear all languages have their quirks, but this is emphasized so much in JS that if you don't have at least a passing familiarity with it I'd wonder how learned the language. However, most people are way smarter than me and maybe they're learning through reading code and just building. In this case, sure, maybe they've never run into the issue.
To be clearer, I wasn't just referring to the fact that 'this' refers to an object, but the complexity inherent in the term in JS.

You can run into this problem by doing something as basic as using it in a click handler if you don't know that it's there.

Yes, interviewing developers for front-end positions has been a nightmare for me too. I interviewed about 40 developers to fill 3 new positions. Yikes. "This is how its done in JQuery" is not a acceptable answer! I expect atleast some basic knowledge of DOM manipulation without using a library.
I wonder how many front-end people out there currently believe that JavaScript is jQuery and don't have a solid grasp of the language, instead focusing on use of a single library.
From my interviews over the last few months, apparently it is a large number of developers. I've had interviewers check that when I say javascript I don't mean jQuery.
Can I ask where (location) was this?

I have trouble understanding how someone would call himself a JS developer and not knowing it.

I'm not at all a JS developer (even though lately I've been knees deep in nodeJS code) and most of my experience is away from the browser, but even I knew this. I was responsible for hiring at a previous company and I did see some people passing as Senior SQL developers without knowing how to do a join correctly, but I always passed it as a local thing (culture here is as long as you graduated you don't need to learn anything new) but not in other more competitive places.

A state government agency about 2 hours south of Seattle, WA. What happens is that Microsoft, Amazon, etc can offer 50 to 100 percent higher salaries and more interesting problems than we can, so most of the really skilled devs go there (I don't blame them). So out pickings are almost always slim.
On the one hand, that makes me want to decry the state of the world and of our profession. On the other, it's kind of heartening to know that that's the state of the competition (so to speak) when I want to change jobs.
For those curious, here's a great summary of key JS concepts to know: http://stackoverflow.com/a/2629004/1538708
I don't even write JS much and I know 'this' is a trap question.
It's not a trap. It's just required knowledge.

Saying you're a Javascript developer without understanding the behaviour of `this`, is like saying you're a C developer without understanding what a pointer is.

You can get by without knowing how 'this' works, if you use CoffeeScript and change -> to => when @ doesn't work the way you thought it would the first time :)