3 ms·

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,

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.
Silhouette 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 I've been writing code for web sites since the web was a new thing, and I don't remember ever writing code that used the arguments pseudo-array in JavaScript. I'm sure I've probably used plenty of tools that relied on arguments for their implementations, but not reinventing wheels and all that. I tend to think these kinds of questions are almost as flawed as brain teasers if you're trying to hire someone who's actually any good at programming. A long time ago, when I first started programming professionally and only used one main language, I was quite the language lawyer and new all kinds of arcane tricks. Today, I often look up how to find the length of a string/array/list/vector because I'm not sure whether it's x.length, x.size(), len(x), or any of another half-dozen variations that are used in different programming languages I know. I usually do get it right, but experience tells me it's faster to check anyway than to wait for a Lint tool to run or a compilation to fail if not. Knowing the concepts in each language is important, so you know what to look up. If a JS developer doesn't understand what "this" means or how prototypes work, and by extension they don't have some awareness of why you'd need to use "call" or "apply", they might struggle. But we have IDEs and search engines and automatic style checking tools and all that good stuff today, and there are more important things to remember than details I really can and do look up in seconds when I need them from time to time. The way I see it, asking an obviously experienced developer how many little details of a specific language they can remember is rather like asking them to take a typing speed test. In theory, the result might tell you something about how fast they can get work done, but in practice you're unlikely to learn anything very useful because the result won't be strongly correlated with writing good code that gets the job done well.

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.

Silhouette 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 I've been writing code for web sites since the web was a new thing, and I don't remember ever writing code that used the arguments pseudo-array in JavaScript. I'm sure I've probably used plenty of tools that relied on arguments for their implementations, but not reinventing wheels and all that. I tend to think these kinds of questions are almost as flawed as brain teasers if you're trying to hire someone who's actually any good at programming. A long time ago, when I first started programming professionally and only used one main language, I was quite the language lawyer and new all kinds of arcane tricks. Today, I often look up how to find the length of a string/array/list/vector because I'm not sure whether it's x.length, x.size(), len(x), or any of another half-dozen variations that are used in different programming languages I know. I usually do get it right, but experience tells me it's faster to check anyway than to wait for a Lint tool to run or a compilation to fail if not. Knowing the concepts in each language is important, so you know what to look up. If a JS developer doesn't understand what "this" means or how prototypes work, and by extension they don't have some awareness of why you'd need to use "call" or "apply", they might struggle. But we have IDEs and search engines and automatic style checking tools and all that good stuff today, and there are more important things to remember than details I really can and do look up in seconds when I need them from time to time. The way I see it, asking an obviously experienced developer how many little details of a specific language they can remember is rather like asking them to take a typing speed test. In theory, the result might tell you something about how fast they can get work done, but in practice you're unlikely to learn anything very useful because the result won't be strongly correlated with writing good code that gets the job done well.