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.
This is interesting.<p>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.<p>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.
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).<p>"At this point, if the candidate is doing really well, I'll ask them to implement currying arguments."<p>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).<p>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 <i>or</i> a whiteboard. A strong candidate should fire off responses to those questions just as fast as you can ask them.<p>Spacify: "Split on empty, join with spaces." Done.<p>String.spacify: "Attach that function to String.prototype and call the split/join on `this`." Done.<p>And so on. It does serve as a way to test if they can actually <i>write</i> 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.<p>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.<p>Am I alone in that?
<i>Ideally the candidate has a really full GitHub 'resume', and we can just go back through their open source projects together. </i><p>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)<p>Combining the rest, I can consider this almost a Javascript tutorial for experienced programmer. Bravo on the neat, concise writing.
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.)
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 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.<p>A correct solution would be:<p>function spacify(input) {
return input.replace(/([^ ])/g, '$1 ');
}
The greatest thing about this article is actually the link at the bottom: <a href="http://bonsaiden.github.io/JavaScript-Garden/" rel="nofollow">http://bonsaiden.github.io/JavaScript-Garden/</a> Great resource.
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.
Seems strange that the interviewer would be so pedantic while showcasing their own lack of understanding... for example:<p>"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."<p>First of all, JavaScript... just... no. Stop.<p>Secondly, hey, you don't need a fixed width or height, you just use:<p><pre><code> position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
</code></pre>
I would really challenge the writer and anyone else interviewing for any position to consider that maybe they don't know everything.
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.<p>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.<p>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.<p>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.<p>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).<p>How does this differ from something like TalentBin that scrapes together peoples various social profiles and aggregates them into a single "report/summary"?<p>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.
"proxies its string argument to console.log()" - Think it's delegation rather than proxy. A proxy would have the same interface as the target.
The most important skill in a programmer is his search ability.<p>I don't know anything, but I know where everything is.<p>And I know how to search for it.
in light of the spirit of your post, i would like to point out:<p>- segway: a personal human transporter
- segueway: a transition from one topic to another