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.
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.
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.
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.
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.
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.)
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).
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.
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.
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.
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.
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.
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.
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.
These are things that I understand when pointed out to me, but off the top of my head, with no google, I'd have to think for a second. They are things that I implement most every day. For instance, the position fixed/absolute thing... I work with things like that pretty much every day, but usually it takes me 10 minutes of fiddling, or 50 seconds of googling if I've had to do it before, unless I get lucky and it just reveals itself as obvious.
Oh well, I suppose that's why I live in the sticks and freelance instead of working for Twitter or Stripe :D I mean, this stuff seems esoteric to me, even though I work with it every day... it's neat to know that there are a lot of folks who have this stuff wired well enough to do it with no reference material.
My thoughts the same. Frontend dev is too forgiving as an interactive playground that I tend to iterate on the solution by getting some feedback from feeling things out rather than straight up knowledge.
I agree, these question assume some kind of drill approach with the language syntax. I would think, this drill only is learned at a university/college level, and if you start programming from a different angle, these questions are hard to answer.
The problem with interview questions like this is that it looks for code-monkeys. I'd maybe have questions like this if I were hiring an expert consultant to crank out some short-term JavaScript for me, but for filling a slot on the team....probably not....as there's really about 10 other things I'm more interested in (assuming they have the necessary technical chops, which I feel these questions don't really answer).
"At this point, if the candidate is doing really well, I'll ask them to implement currying arguments."
Why? If they've already proven enough tech knowledge to do the job, why continue to ask more questions that might/might not use to server your hiring decision? (It sounds like you'd continue a different direction if they couldn't implement with currying).
EDIT: I'd probably not be really hiring a short-term consultant like this either, though, now that I think about it.
This interview could go much faster if it didn't use a laptop or a whiteboard. A strong candidate should fire off responses to those questions just as fast as you can ask them.
Spacify: "Split on empty, join with spaces." Done.
String.spacify: "Attach that function to String.prototype and call the split/join on `this`." Done.
And so on. It does serve as a way to test if they can actually write code, but my guess is that there's not that big a difference between talking through the code you'd write and actually writing it.
I'd be very comfortable with going through this verbally, but I'd be horrified to get an interview like this where they expect me to type code and talk to them while doing it. I'd honestly much rather have a whiteboard than a laptop—at least I'm used to writing with a pen while someone judges me. The laptop would just take away that comfort and make sure my brain turns off.
The split on empty thing seems silly to me. It's a hack. If you weren't familiar with the specific javascript implementation, you might expect split to return ['hello world']. It's a nice hack, but it's a hack. It's something you can do if you offhand know about that quirk of split.
I would think an advantage to using split/join is that you aren't concatenating a lot of immutable strings together (although if this only happens one time and for a short string, it may not matter.)
Edit: Not tested myself. I had a suspicion about it and "confirmed" it via an older post that is perhaps outdated now. Updated this comment to sound less authoritative ("I would think").
One thing I've learned from jsPerf is that this sort of micro-tuning tends to be particularly fruitless in JavaScript. Even if a tweak increases speed consistently across the target browsers, there's no telling which will optimize what cases in the next few versions.
Basic things like caching DOM lookups are always good, but not so much the little things.
The join() hack used to be significantly faster for many/long strings a couple years ago, but I wouldn't be surprised if things have changed since then. I'd be interested to see your results.
I think it's better to use the laptop because that is the "language" I should be mostly comfortable with to be a good candidate, unfortunately I am not half as good with expressing what I would do. I would be also pretty nervous which obviously won't help. Instead typing could make feel more secure.
No. Not at all. You could even have a conversation broaching some of these topics in a more casual way and tell if the candidate knows what he's talking about in a lot of cases. Heck, even answers about function arguments could be answered satisfactorily enough if the candidate knew about the "arguments" object.
Ideally the candidate has a really full GitHub 'resume', and we can just go back through their open source projects together.
Note not everyone is a Github user. Some brilliant Python projects that I use are still hosting on Bitbucket and/or Google code (and of course some on sourcegeforge) so we should be careful with that. I will assume OP is making an alias rather than excluding other service providers, though it is important to keep that in mind (in particular, if you are implementing a form with a field "github profile", please provide either a drop-down menu or a general field with multiple textboxes)
Combining the rest, I can consider this almost a Javascript tutorial for experienced programmer. Bravo on the neat, concise writing.
Most programming interviews I've had over the years have asked for code samples. Github is just the first thing people think of, but companies will always in my experience ask for you to email them some code samples if you don't have a Github account.
Although there's an argument to be made that owning a many-starred project or contributing to a big OS project is also an indicator :)
I like how the article suggests letting applicants bring their own laptops (and only using the interviewer's laptop as a fallback.) Many people don't realize that is pretty hard to work on someone else's computer, especially in a stressful situation. (Different installed software, software configuration, keyboard, etc.)
I had a remote interview this morning using etherpad, and I was surprised how hard it was without emacs bindings. You'd think that because not everywhere has them (like, say, this HN comment box) it would be easy, but apparently when I'm typing code I really feel it. It really is the little things.
Agree, on my first ever interview i didn't bring my laptop and the interviewer let me use his, it was so hard because he has Windows in it and i am used to Linux, the editor was Sublime Text and i am use to my own configured Emacs, he was using a GUI tool to create the database when i am use to the command-line for such tasks, at the end that make the interview a lot harder to pass.
Last time I was involved in in-person interviewing, we told people to bring a laptop with whatever software they were most comfortable using for development. Or, we could provide a freshly-formatted Windows XP system they could install things on if they didn't have something they could bring. Worked out pretty nicely, and definitely made people more comfortable.
A lot of that stuff sounds like "my favorite list of code smells and anti-patterns". Yes, it's cool you know these things about JavaScript, and now please never use them.
I guess HTML/CSS is something that can be done by a non programming designer, so if your team is large enough to have separate back-end devs , front-end devs and designers it's more important for the developer to be able to manipulate CSS than design it from scratch.
yeah most front end devs I'm familiar with are layout first, and just have to hammer on the JS until it works. I like the front end engineer title for JS first.
I don't mean to be pedantic; well actually I do. The spacify solution is incorrect as the sample suggests that a blank space is not replaced with 2 blank spaces.
A correct solution would be:
function spacify(input) {
return input.replace(/([^ ])/g, '$1 ');
}
Yep 2 spaces was the intention, where as the original implementation yields 3 spaces. My codes failure is that it appends a blank space to the end... I guess the real take away here is that there are many ways to achieve the same outcome. Knowledge of quirks is not essential. I would think the most important first step is understanding the requirements, what sort of performance is acceptable given the intended usage, coding for maintainability and ease of usage. For example, the solution for ensuring getCount has the proper context requires knowing how getCount was implemented then taking extra steps. A better solution may be something like this:
var User = {
count : 1
};
User.getCount = function() {
return User.count;
}
I guess front end designer then? Given that a complete javascript knowledge is encyclopedic, I'd say that you have to allow for a very wide gamut of experience for this.
What about the front end web developers who can't seem to create original designs, they fight the design and artwork part as much as a layout designer fights with javascript.
This isn't so cut and dry. Plus with the javascript libraries you can get quite far without writing your own js.
If you don't know JavaScript, you're really handicapped using any form of higher-level language wrapper. Coffeescript is syntax sugar. Run into problems or library incompatibility with other components and you don't know JavaScript...well...
BTW, for the record, I've never actually known a coffeescript dev who didn't know JavaScript, too, though.
What happens when there's a problem at the interface between your favorite compiles-to-javascript language and javascript? If you don't know javascript, how are you going to debug and/or fix that? I've never used coffeescript or clojurescript, so maybe they're so thin that this never happens?
My take on questions like these are that they most of the time focus on putting the focus on some niched skillset of the interviewer and has very little to do with real life problem solving. If a company hire based on how well a person scores on some niched test, I guess they will end up with a lot of internal nitpicking among the developer on who solves some obscure array sorting algorithm the smartest way instead of focusing on getting shit out the door.
And any interview technique that involves "real world" problem solving is criticised for being too contrived.
And any interview technique that involves the candidate actually working on production code it criticised for being exploitative and effectively slavery.
Seems strange that the interviewer would be so pedantic while showcasing their own lack of understanding... for example:
"How they choose to center content inside the overlay is also revealing. Some of the candidates might choose to use CSS and absolute positioning, which is possible if the content is a fixed width and height. Otherwise may choose to use JavaScript for positioning."
First of all, JavaScript... just... no. Stop.
Secondly, hey, you don't need a fixed width or height, you just use:
What's missing in the article for me is the ratio of candidates who scored well. I've learnt that you can have some excellent developers who get excluded which half a day of training when they start can bring them up to speed.
In my experience, interviewing is a costly process and being too particular can simply mean you don't find the right candidate. Companies which have a brand reputation that attracts talent can get away with this, but smaller more unknown companies sadly can't.
I'm curious to assess if people separate front end designer / dev with front end engineer.
I just don't know too many people with a rich design / artwork talent as well as heavy javascript programmer mind. Maybe I just don't know enough people.
I suppose when you have a massive web app, you call your people front end enginers because there are twenty of them and they don't have to create an entire UI, they have been able to focus on specific issues and manipulating the DOM.
It seems as if the "github resume" is becoming more commonplace. I am married with a 2yo son. I currently do not have time to contribute to open source projects, and my company does not use git for versioning its codebase. Will having an empty github account effect me adversely these days?
Note: these questions aren't related to the article, but at sourcing.io who's blog is writing content.
I'm trying to figure out how sourcing.io gets it's developers. As a techie, there was no obvious way for me to put up a profile or anything. There's an explanation that it uses the companies team's social networks, so maybe the employees have to share all their specific account profiles with the company (see below on more on this).
How does this differ from something like TalentBin that scrapes together peoples various social profiles and aggregates them into a single "report/summary"?
Also, do employees really give up their social graph to their employer? I keep mine pretty tightly locked away. I've built it, maintained it. I might or might not be with the company in six months (They might lay me off. I might get a better job.) Occasionally, I've dug into mine to find someone when one of those emails is sent around mentioning a hiring bonus for a certain position. Or when I need to hire someone directly. But I still don't openly share mine.
Lots of these comments are the reason I read HN. I love an educated discussion, especially as a response to an article with breathes pretentions like this one.
It doesn't get easier. I was taught C++ in college without terms like "encapsulation". It was just "hey, you can make one of the variables in your object hold another object, isn't that cool?". Took me almost ten years to sit down an learn modern OOP jargon, just in time for OOP to start falling out of favor.
