8 ms·

I don't think this kind of questioning is useful. Does it really matter if the dev knows all the strange intricacies of javascript, or does it matter if they ca

by RyanZAG 13y ago

I don't think this kind of questioning is useful. Does it really matter if the dev knows all the strange intricacies of javascript, or does it matter if they can actually put together a well engineered application? I can easily see a more big-picture oriented dev who only uses the bare minimum javascript features fail this test yet create very well engineered code. I can also easily see a dev who likes to study manuals doing well on this test and then making code so difficult to understand he can't even fix it himself.

lunarcave 13y ago
Not necessarily. While I may agree that a good candidate can be put off if the line of questioning was only about quirky parts, I noticed that the questions actually help judge a candidate's js proficiency. A large part of this interview was based on testing the candidate on essential parts of the language like contexts, prototypes, etc.
erikpukinskis 13y ago
That's my reaction too, but it's hard to know if OP is actually overzealous or I'm just not good enough for them. This line stood out to me: > it's important that anyone you hire has a comprehensive knowledge of apply and call To other Javascript developers: is this really true? I do use call every now and then, but it's pretty rare. Maybe that kind of stuff is more important if you're trying to functionally isolate components with richer interfaces between them? I tend to keep a pretty polluted namespace, so maybe that's where I'm going wrong. That said, I have a "I could learn that but I have stuff to ship" mindset about Javascript. That has its ups and downs. Maybe I should work on that a bit more.
- bulatb 13y ago
  You should know that they exist and what they do. You can do a lot of things with higher-order functions just by making closures, but `apply` and `call` will give you flexibility and power there's no other way to get. For one thing, they're your ticket to manipulating `this`. The worst part is keeping them straight. My mnemonic is that `call` is just a function call, so arguments go in as normal. `apply` is the other one, so arguments go in as an array. (Maybe "A" for array, or something.)
  - berodam 13y ago
    My usual mnemonic is "call list" and "apply array"
- hcho 13y ago
  Yes. I have 10 people working on a code base. It's been more than a year since we started. Your hunch is correct, keeping a neat namespace is the job.
- timdown 13y ago
  I'm not convinced. I think not knowing that apply() and call() exist would lead to unnecessarily clunky code, but even after over a decade of using them occasionally I still sometimes have to look up which is which. My use of them tends to end up deep in library code rather than everyday functions.
  - davedx 13y ago
    This is a crucial point. apply and call tend to be more useful for libraries than application level code, in my experience. Even in the "front end development" subfield of web development, there are divisions. Do you want someone to produce lots of modular libraries that are reusable throughout your company/application suite, or perhaps to build a UI framework? Then knowledge of these parts of JavaScript will be very useful. Do you want someone to build a rich internet application in Meteor? Then knowledge of positioning, layouts, templates, UI effects and how to tie them into the Meteor framework is much more valuable. Where I work we do a lot of 2D animations, so it's great if the people who work here know all about CSS transitions, requestAnimationFrame, and so on.
- menriquez 13y ago
  "That said, I have a "I could learn that but I have stuff to ship" mindset about Javascript" amen bro...amen.
- warfangle 13y ago
  Knowing call and apply demonstrates a knowledge of how context, arguments, and function calls work. It's like demonstrating pointer knowledge in C. Absolute must for a non-junior candidate (and even then, depending on what you're hiring a front-end developer for).
onion2k 13y ago
If you're interviewing to find someone to build a new application, sure, big picture is more important. However, if you're interviewing at Twitter, chances are someone else is doing that. These questions are are for candidates who'll be building features defined by other people, and to that end, they are the sort of things you want to know about.
grey-area 13y ago
When it got to the variadic arguments one I had the same thought - it's important to know that it is possible, but less important to know the syntax for that in a particular language as you will I use it very rarely, and it can easily be looked up. There is a danger with this sort of questioning that it veers into esoteric corners of the language which are not a test of ability at the job, but a test of ability at language quizzes. The context questions I had more sympathy with, as it is a potential pitfall for js developers, but there are other ways to mitigate this, like not stripping object functions of their context in the first place (not sure why you would do that here?) - this kind of stuff is often handled by libraries, particularly the native shim. Thankfully he does move on to problem solving later on, which strikes me as far more useful - an open-ended question will reveal lots about the candidate.
nairteashop 13y ago
I actually liked the questions because if you spend enough time writing web apps, I feel you will run into all of these situations, e.g. manipulating arguments, losing the "this" context, catching the wrong click event, etc. (You will however not run into puzzles, fibonacci heaps, or whatever else is unfortunately asked far too often IMO in front-end dev interviews.) As a parallel, when I interview developers for a Java position, I ask them to list some methods in java.lang.Object off the top of their head. A few have objected to this, calling the question arcane, something they could look up in 5 mins, etc, which are all true, but the thing is if you've written enough Java, you would definitely have run into at least equals(), hashCode(), and toString(), and likely wait() and notify() as well. This one simple question has been a surprisingly good proxy to the developer's general level of proficiency and experience with Java.
- hrktb 13y ago
  I tend to agree on a theoretical level. At the same time, this approach assumes your candidate is currently working on the language you use in the interview. I think it's not rare to have people working on different stacks depending on the projects, and they can be expert in front-end dev for instance, but have been diving into BE APIs for weeks when you interview them. Some can be coding in any language they know in seconds at will, others will need a lot more time to switch context. It's a valid approach I think, but not without it's pitfalls.
  - wavefunction 13y ago
    If they're a front-end developer and they don't know at least JavaScript, CSS and HTML, they shouldn't really be calling themselves a front-end dev.
    - hrktb 13y ago
      Of course. I was more thinking about the "hey, code me this now !" aspect
- fhd2 13y ago
  Not sure about the Java question actually. I'm pretty certain every Java programmer can answer this. Whether they can understand what you mean and recall it in a stressful interview situation is what you seem to be assessing here. Not sure if that's what you're after. This question seems to be targeted at weeding out people who never had to do with Java. Have you tried asking for code samples? We always do, if someone has nothing relevant to show, we give them a simple task to solve at their leisure. Has been quite useful both for weeding out non-programmers as well as for getting a rough idea of someone's skill level.
fhd2 13y ago
I tend to use a similar style of interviewing, but I'm not doing it to get right or wrong answers. I'm doing it to get a dialog going, to figure out if I can actually talk about programming with the candidate. If that works out, I really don't care if they don't know or forgot some detail. As long as their level of knowledge roughly matches their claimed experience, that is. People tend to be stressed in interviews, especially when faced with unfamiliar (if simple) problems, so I prefer to look through code they wrote on their own to get an idea of their skill, then verify in the interview that they understand their own code. I suppose big tech companies don't have time for that.
meowface 13y ago
If you need someone who is experienced with Javascript, then I think those are reasonable questions to ask.

by RyanZAG 13y ago

lunarcave 13y ago

Not necessarily. While I may agree that a good candidate can be put off if the line of questioning was only about quirky parts, I noticed that the questions actually help judge a candidate's js proficiency. A large part of this interview was based on testing the candidate on essential parts of the language like contexts, prototypes, etc.

erikpukinskis 13y ago

That's my reaction too, but it's hard to know if OP is actually overzealous or I'm just not good enough for them. This line stood out to me: > it's important that anyone you hire has a comprehensive knowledge of apply and call To other Javascript developers: is this really true? I do use call every now and then, but it's pretty rare. Maybe that kind of stuff is more important if you're trying to functionally isolate components with richer interfaces between them? I tend to keep a pretty polluted namespace, so maybe that's where I'm going wrong. That said, I have a "I could learn that but I have stuff to ship" mindset about Javascript. That has its ups and downs. Maybe I should work on that a bit more.

bulatb 13y ago
You should know that they exist and what they do. You can do a lot of things with higher-order functions just by making closures, but `apply` and `call` will give you flexibility and power there's no other way to get. For one thing, they're your ticket to manipulating `this`. The worst part is keeping them straight. My mnemonic is that `call` is just a function call, so arguments go in as normal. `apply` is the other one, so arguments go in as an array. (Maybe "A" for array, or something.)
- berodam 13y ago
  My usual mnemonic is "call list" and "apply array"
hcho 13y ago
Yes. I have 10 people working on a code base. It's been more than a year since we started. Your hunch is correct, keeping a neat namespace is the job.
timdown 13y ago
I'm not convinced. I think not knowing that apply() and call() exist would lead to unnecessarily clunky code, but even after over a decade of using them occasionally I still sometimes have to look up which is which. My use of them tends to end up deep in library code rather than everyday functions.
- davedx 13y ago
  This is a crucial point. apply and call tend to be more useful for libraries than application level code, in my experience. Even in the "front end development" subfield of web development, there are divisions. Do you want someone to produce lots of modular libraries that are reusable throughout your company/application suite, or perhaps to build a UI framework? Then knowledge of these parts of JavaScript will be very useful. Do you want someone to build a rich internet application in Meteor? Then knowledge of positioning, layouts, templates, UI effects and how to tie them into the Meteor framework is much more valuable. Where I work we do a lot of 2D animations, so it's great if the people who work here know all about CSS transitions, requestAnimationFrame, and so on.
menriquez 13y ago
"That said, I have a "I could learn that but I have stuff to ship" mindset about Javascript" amen bro...amen.
warfangle 13y ago
Knowing call and apply demonstrates a knowledge of how context, arguments, and function calls work. It's like demonstrating pointer knowledge in C. Absolute must for a non-junior candidate (and even then, depending on what you're hiring a front-end developer for).

onion2k 13y ago

If you're interviewing to find someone to build a new application, sure, big picture is more important. However, if you're interviewing at Twitter, chances are someone else is doing that. These questions are are for candidates who'll be building features defined by other people, and to that end, they are the sort of things you want to know about.

grey-area 13y ago

When it got to the variadic arguments one I had the same thought - it's important to know that it is possible, but less important to know the syntax for that in a particular language as you will I use it very rarely, and it can easily be looked up. There is a danger with this sort of questioning that it veers into esoteric corners of the language which are not a test of ability at the job, but a test of ability at language quizzes. The context questions I had more sympathy with, as it is a potential pitfall for js developers, but there are other ways to mitigate this, like not stripping object functions of their context in the first place (not sure why you would do that here?) - this kind of stuff is often handled by libraries, particularly the native shim. Thankfully he does move on to problem solving later on, which strikes me as far more useful - an open-ended question will reveal lots about the candidate.

nairteashop 13y ago

I actually liked the questions because if you spend enough time writing web apps, I feel you will run into all of these situations, e.g. manipulating arguments, losing the "this" context, catching the wrong click event, etc. (You will however not run into puzzles, fibonacci heaps, or whatever else is unfortunately asked far too often IMO in front-end dev interviews.) As a parallel, when I interview developers for a Java position, I ask them to list some methods in java.lang.Object off the top of their head. A few have objected to this, calling the question arcane, something they could look up in 5 mins, etc, which are all true, but the thing is if you've written enough Java, you would definitely have run into at least equals(), hashCode(), and toString(), and likely wait() and notify() as well. This one simple question has been a surprisingly good proxy to the developer's general level of proficiency and experience with Java.

hrktb 13y ago
I tend to agree on a theoretical level. At the same time, this approach assumes your candidate is currently working on the language you use in the interview. I think it's not rare to have people working on different stacks depending on the projects, and they can be expert in front-end dev for instance, but have been diving into BE APIs for weeks when you interview them. Some can be coding in any language they know in seconds at will, others will need a lot more time to switch context. It's a valid approach I think, but not without it's pitfalls.
- wavefunction 13y ago
  If they're a front-end developer and they don't know at least JavaScript, CSS and HTML, they shouldn't really be calling themselves a front-end dev.
  - hrktb 13y ago
    Of course. I was more thinking about the "hey, code me this now !" aspect
fhd2 13y ago
Not sure about the Java question actually. I'm pretty certain every Java programmer can answer this. Whether they can understand what you mean and recall it in a stressful interview situation is what you seem to be assessing here. Not sure if that's what you're after. This question seems to be targeted at weeding out people who never had to do with Java. Have you tried asking for code samples? We always do, if someone has nothing relevant to show, we give them a simple task to solve at their leisure. Has been quite useful both for weeding out non-programmers as well as for getting a rough idea of someone's skill level.

fhd2 13y ago

I tend to use a similar style of interviewing, but I'm not doing it to get right or wrong answers. I'm doing it to get a dialog going, to figure out if I can actually talk about programming with the candidate. If that works out, I really don't care if they don't know or forgot some detail. As long as their level of knowledge roughly matches their claimed experience, that is. People tend to be stressed in interviews, especially when faced with unfamiliar (if simple) problems, so I prefer to look through code they wrote on their own to get an idea of their skill, then verify in the interview that they understand their own code. I suppose big tech companies don't have time for that.

meowface 13y ago

If you need someone who is experienced with Javascript, then I think those are reasonable questions to ask.