For example, I don't have the slightest clue what the answer is to probably half of these and a lot of my job is to write javascript that gets run millions to billions of times a day. The "code questions", by contrast, were all ridiculously easy.

So, would it really matter if you are hiring someone who doesn't remember the difference between .call and .apply off the top of their head?

As Colonel Frank Slade says in Scent of a Woman when asked by his nephew why he always gets his job title wrong- "Because it's not important for me to get it right."

No, but it does mean that you don't know about deferred script execution and possibly do not have a lot of experience in optimising page performance.

Hardly the end of the world, but if you're looking for a senior developer you might really want that skillset.

Perhaps, but as with any question like this, it's a foolish interviewer who draws such a broad conclusion from such a narrow data point. For example, as it happens I do know what <script defer> does, but that includes the fact that it can't be used reliably before IE10, which is why I've never actually used it on any production site. Not having encountered that particular functionality would therefore have made absolutely no difference to any project I have ever worked on, nor had any relevance to any senior people I was hiring to work on them with me.

That might have been something that senior devs only did 5-10 years ago, rather than something senior devs do now, though if that's the case one might wonder exactly what we mean when we say "senior."

But it didn't seem too obscure to me. Deferring execution is a known technique, so I would have probably guessed it right or switched it up with async.

I don't know if the "Google effect" (http://en.wikipedia.org/wiki/Google_effect) is real but I sure as mittens have to google for syntax all the time. maybe not Google, man pages work or Python has help(csv.reader) or whatever.

I was stuck in many even though I write JavaScript everyday.

Today, I probably couldn't tell you with bet-my-life-on-it confidence how to do those things in any language I know. There are a lot more languages, about half a dozen of which I currently use in professional work several times per week, but the five-second documentation search to check the right syntax* is completely auto-pilot behaviour now.

This was quite a disturbing realisation the first time I noticed it, but I've since concluded that with modern on-line help systems, general awareness of what tools will be available and what kinds of tricky issues to look out for is far more practically useful than being able to reliably recite specific details for specific contexts five seconds faster than a search would have told me.

*In the case of JavaScript, please allow five seconds for the initial search, followed by another thirty seconds checking sites like MDN or caniuse to see what is actually likely to happen in real browsers and whether some mundane functionality amazingly still needs a polyfill or other library-based alternative to work sufficiently portably. :-)

I don't see anything here that seems absurdly trivia-esque. The coding questions were easy but I think coupled with the JS and even jQuery questions they do a good job of covering quite a lot of content without falling back to brainteasers (which have their own share of problems, as any HN reader probably has read about a hundred times). Again, I couldn't answer all of them myself as I rarely work in JavaScript, but they all seem like things that one should know if one is working exclusively in JavaScript.

This is the important clause.

Imagine looking for a backend developer. A candidate with twenty years of experience shows up. Looking at his resume, you see the chronological buildup of terms: HTML, XHTML/DHTML, JS, JQuery, Prototype, mootools, YUI, Ember, Knockout.js, Angular, Om.

"Well, this is an impressive resume, but we're really looking for someone with more experience on the back end."

And then you cut the interview short, because you need to finish up that letter to Congress about the talent shortage.

I don't know if there's an everyone-wins answer here, but this sort of thing is why devs go into management.

I'm operating under the assumption here that the candidate has already been working professionally as a front-end developer. Do you really think it's unreasonable to expect someone who's professionally doing exclusively front-end development for a minimum of 40 hours a week to do at least somewhat well on these questions?

I didn't mean to imply that one should completely rule out people who've worked in other domains. But if a full-time exclusively front-end developer is applying for a front-end position, I do not find the idea of asking questions about front-end development to be unreasonable.

For what it's worth, in your example, if I needed someone to work through some very hairy distributed computing problems and someone with 20 years of experience applied who had never once in their entire career worked with distributed computing, yes, I'm going to take that into account. Why shouldn't I? No, that doesn't mean I'm going to immediately rule them out, and I certainly don't think there's a talent shortage, but if someone else applies with 20 years of experience in distributed computing, I'm going to lean towards them initially.

But I think I'd probably have trouble hiring, and I'd start to think there's a talent shortage.

What we're doing, as an industry, is eating our own seed corn. We're eager to front-run on experience and knowledge, but unwilling to sit around and let them cook. And, frankly, this is somewhat justified, as devs aren't famous for sticking around.

What we should be doing is satisficing rather than optimizing.

If you (and now I mean you you, not the indefinite) were going to work exclusively on the front-end, I highly doubt you'd know the answer to these. Hypothetical: you're fired today, I hire you tomorrow to work on my front-end stuff. Is the first thing you do to start looking up JS trivia?

No! Hell no! Because you're a responsible person. You'd work on...what needs working on. Oh, this page is loading slowly, time to learn how to use Chrome's profiler. Hmm, this div is behaving oddly, time to refresh on CSS.

And yeah, you'd get bitten by something on this list. But...so what? There's always something like that, no matter your experience level, and if you do happen to be that mythical person who's absolutely mastered a stack, surprise! We're switching (back) to Backbone tomorrow.

Would any of this make you unsuitable for the position? I don't think so.

Back to the example, yes, if you've got a hairy distributed systems problem, and someone applies with 20 years of experience in distributed systems, yes, you hire them. But if and when they call and say, "Well, Google offered me more millions than you offered me hundreds of thousands, so..." and you're left with candidates with 20 years of experience divided between COBOL, webmastering, AJAX, Rails work, and open-source contributions to Julia and Battle for Wesnoth...then yeah, sorry you didn't get the unicorn, but that second guy will be just fine. Get the distributed-systems guy in as a consultant for a week or two if you have to. If he really is that good, you might not need to hire anyone at all!

This whole thing is a result of developers overvaluing intelligence and being scared of not being the expert on something, employers buying it that programmers are superpeople, and then acting like it's a betrayal of trust when they don't know every small detail of every technology they've ever used, and both parties' refusal to think about what they need, rather than what they want. The tell-tale sign is that "hiring is hard," but there are still technology companies around. Sure, if you're hiring better ("top 1%") people rather than good ("good") people. And developers are just as bad: not everyone can be paid above average.

What’s more important than their answers to these questions is how they got there. Have they vertically centered an element so many times it seems second nature? Did they find it in an unsubstantiated StackOverflow post? Did they write a C program to lay it all out using spans?

The bigger computer science questions are what you need answers to and I’d love to see some front end questions which address these, not minute trivia that will likely change down the road.

Usually I was using this list as a topic and of course I also don't know the answers of every question, but I pick the questions that are relevant to the company's tech stack.

I could answer pretty much all of them in under a minute of Googling. Which tells me a) that I don't actually need to know the answers to them in real life, and therefore that the questions measure dumb ephemera; and b) that the questions are more a test of random chance ("oh yeah, I ran across that once" makes you more impressed by me?) than they are of developer skill.

The "trivia" term is well used here.

I usually like more doing simple live coding that implies real life things such as either building a simple html/js page to do some ajax and manipulate some objects, or debugging something broken.

For example, bad questions:

* How is responsive design different from adaptive design? - there's no formal definition of either. While it might prompt a discussion, it will probably just make the interviewee feel nervous, when you should be trying to get them to relax.

* Why is it called a Ternary expression, what does the word "Ternary" indicate? That's an etymology question. It might be interesting, but it gives no indication as to whether the person is a good developer or not.

* Explain how this works in JavaScript If you can do that effectively, you should probably be presenting and writing books on JavaScript.

Good questions are about opening up a conversation with the person. Why do they want to be a front end developer in your company? What would they be like to work with? Are they looking to specialise in a particular area of front end development, do design + coding, or front end with back end?

* If you could master one technology this year, what would it be? - I read that question last time I saw this link, and have used it a couple of times. It's nice because it tells you where someone wants to be. Think about how you'd react to answers like PHP, NodeCopter or SVG.

* What excites or interests you about coding? - it's open ended. If the interview can only say "I dunno", that tells you they're either not very communicative or not very interested in front end development.

* What tools do you use to test your code's performance? - I have worked with fantastic front end developers who were able to twist CSS and JS into doing anything, but the performance of their code was awful. They opened it in a browser, if it worked, they signed it off and left it for somebody else to speed it up. Depending on the role, that might be perfect, or you might be looking for the exact opposite. Either way, it's a good way of having that conversation with a prospective developer about what their opinion is.

If I hire someone as an experienced frontend dev, I want them to be able to explain how stuff works to other people - especially to non-frontend developers, and junior developers. I want them to be able to train others up. So yes, I want them to be able to present on JavaScript. If their answer to the question tells me they're good enough at explaining things that they could write a book on the subject? Fantastic! Put that in plus column.

I'd be really interested in learning if the amount of technical debt that we don't ever have to pay off is rising (because product lifetimes are shorter, performance is going up, and libraries reduce the total code you write).

But the biggest issue is the disagreement with the body of knowledge that everyone should have. Even in the body of knowledge, there's disagreements about what bits of knowledge go to which categories (Is it nice-to-know, or need-to-know?)

It's really no wonder you see such a broad range of candidate skills and knowledge. The sub-fields of the programming field can't even decide what everyone ought to know at various levels of experience!

Unless you're writing all your code from scratch and not using any frameworks / util libs (which you should) you won't need them very often.

Right, jQuery does it for you. You usually don't need to do it yourself unless you're contributing to jQuery (or another lib/framework that needs them).

I might ask someone about call and apply but wouldn't be overly concerned if they didn't remember the exact syntax or mixed them up. I've done the same myself. I wouldn't expect someone to remember every little nuanced part of a language, especially if it's not something they use frequently.

That being said, I think it's a great list to work from. I would expect you can arrive at a fairly good understanding of a candidate's abilities based on how they answer the questions rather than if they can answer them all.

A good developer might not remember the answer to half of these at any given time, but if they at least knew the answer at one point then that should be enough to give a decent answer to most of these questions. E.g. 'They are two ways of calling a method, one involves passing the parameter list as an array, the other involves passing the parameters as positional arguments.'

Similarly, I don't remember offhand exactly how to fix a FUOC, all the nuances of the javascript 'this' keyword, or all the rules for resolving CSS specificity, but I could still probably answer all of those questions well enough to pass an interview. Unless the interviewer is super OCD, just saying something like, "There is an angular setting that can prevent most cases of FUOC, and if that doesn't work then you can manually hide the element until the page loads" should be good enough.

Simply getting the names mixed up and needing to look them up is one thing, but if the unfamiliarity stems from a general unfamiliarity with those methods and their respective use cases, then it would be a red flag for a "senior dev" sort of position.

    f.apply(this, arrayOfArgs); // Array

    f.call(this, arg1, arg2, arg3); // Columns

:)

I want a take home assignment with a due date. That's all. What else do you need?

For those of us that realize the best hiring strategy is to find people that cover the weaknesses of the rest of the team, these are pretty terrible questions to ask. A few of them might work well for the initial phone screen, but beyond that they're useless.

Though this posting has a lot of suggested questions, it's missing this: What should the interviewer be looking for in the answers?

In my experience interviewing candidates (not usually for dev roles), the "correct" answer isn't the only good answer. Sometimes "I don't know, but this is how I would find out" is just as valid -- and usually more telling.

I know the answers to 90% of these questions and I am not a frontend specialist, I'm just a guy who had to do frontend for two years because that's the role that was needed. If I were making hiring decisions, I would want a frontend specialist to be better at it than I am. If a sr level candidate isn't breezing through this, something is wrong, or he builds very different applications than I do.

Well, at least it would give a hint whether the candidate ever touched meta-programming. All the other question are mostly about writing correct code, this was the only one about writing less code.

But the point of having a list of questions is that you dont expect a candidate to know all of them. You should make that clear up front so that a candidate does not feel flustered if they dont know something.

If you make a test and you expect someone to answer everything then your test has to either be way too hard or way too easy. Remember in school those tests that were really hard and the highest 'uncurved' grade was a 60%? Those are awesome tests.

Why are they awesome? Because it opens up the range of a candidate to see where they are at in their career and development.

I would give anyone using it a tip of advice :

Use this list not as a TOC or a check list. Use it to remind yourself what you could actually talk with the person that is applying for a job.

I usually start with the questions and present them not as a real question, but as a more of a "topic of conversation". Like for example :

Question => Transformed into topic

"Which version control systems are you familiar with?" => "Have you used VCS on your previous job? Which VCS is your favourite?"

"Name 3 ways to decrease page load (perceived or actual load time)." => "Have you ever tried to improve google page speed index or your page speed at all?"

Next I will ask in a similar ways questions about HTML, CSS and so on. I could go deeper if I see a person is interested in what we are talking about.

Anyway I've been interviewing more than 10 persons with this list in front of me. I highly recommend it as a base of your interview.

As an interviewer: "Tell me what you've done in your career. We'd like to give you money to do those things for us."

That's all I really want or need for either side of the table.

Of course, if you are in a big company this is too much time and work (Recently had 6 interviews at big corps, not a single line of code written for a junior position)

How is this even possible for people that already have a job? Are they supposed to take two days vacation or do it in the weekend?

I really don't know because I was only an intern, but I guess they took vacation days (law mandates minimum 20/year). But I also recall a discussion here on HN on this topic, where applicants (at a different company) were in invited to work on a weekend.

2 days is probably overkill for US-companies, but a bit of pair-programming on real problems seems a lot better than "Let's see if you memorized this trivia fact you'll never need in your job"

There may be more to the story, but in the absence of other information, "fired for using Notepad to write code" strikes me as being more on the arbitrary and capricious end of the scale than the rational and justified end.

It's a lot like firing a carpenter for using a screwdriver instead of a power drill with a screwdriver bit.

Employers need to be very careful about the termination process; employees can claim compensation for unjustified or constructive dismissal. The employee might be glaringly at fault, but if the employer does not follow process (or even fails to document that) then a ruling can go against them.

Claims are very common here; there are various law outfits which just specialise in this area (e.g. the 0800 SACKED toll free number).

Decades of union-busting lobbying has resulted in "at-will" employment being the default in many states that formerly had better employee protections. Contracts are now uncommon, and contracts that do not heavily favor the employer are rare. This was sold as making it easier to hire and fire employees, but my observations suggest that it has not made it easier to hire.

Working in much of the U.S., aside from a few specific states, is toiling under the Sword of Damocles. My worst-case anecdote was being laid off with 3 days of notice with no severance. In theory, that should have triggered a federal penalty, since the entire office facility was laid off, but the company did some sort of legal sidestep to avoid that, which amounted to "You're not being laid off; we're just not giving you any work or paying you." When I found a new job 2 weeks later, the company demanded a resignation letter in order to release my security clearance responsibility to the new company. I refused, but I still had to write a note for their records explaining how layoffs work.

I'm continually surprised at people who come from Europe or Commonwealth countries to work in the US. Perhaps they just don't know?

Also, why would I leave my job where I'm not on probation for a new job where I am on probation?

That aside, Notepad is bad because every single other text editor is probably better. Syntax highlighting, macros, plugins, ftp, language based autocomplete, etc. You can build projects directly from a lot of them with a couple of keystrokes.

> Are there any problems with serving pages as application/xhtml+xml?

I've never had to or considered serving pages as application/xhtml+xml, there's no reason for me to know the answer to this question and I've been working on the front end for ages. If I ever had reason to serve a page application/xhtml+xml I would thoroughly research it. Although I would say the JS questions look decent.

I think VML's response is valid here, it's to check for experience and if you were engaged enough with the happenings of the web at the time.

Background (not a 100% accurate, I'm writing from my admittedly poor memory):

XHTML and later XHTML2.0 were being pushed a while ago (early 2000s) as the next HTML language (succeeding HTML 4). At some point the community split and people from Mozilla, Apple and Google (I think) formed WHATWG to pursue a different (and faster) direction which is where HTML5 was formed, then later adopted back by the W3C.

One of the issues at the time when people pushed for wide XHTML adoption was that most people served pages as text/html which was basically wrong.

Serving pages as application/xhtml+xml triggered the XML parser instead of the HTML parser which is the "proper" way to parse XHTML.

The problem some people ran into was that the XML parser is way less lenient than the HTML parser. You _have_ to close your tags, you _have_ to escape entities, and if you had a single mistake anywhere in your markup the browser would render an error page instead of working around it.

There were also issues with in-lining JavaScript and having to wrap it in a CDATA block to stop the XML parser from attempting to parse it.

This was a headache for sites with user generated content and people in general seemed to not like the idea of having to clean their markup for what some perceived as very little gain.

Anyway, long story short, HTML5 won, XHTML didn't.

Preface with I'm not a front end guy, but I get the impression this was a major discussion topic around a decade ago. So this specific question is a resume tester, you claim 15 yrs experience on the resume, lets talk about a major gossip or controversial topic from 10 yrs ago that is pretty much irrelevant or uncontroversial today so someone with only 5 "real" years experience would have no opinion about the topic.

Also give the candidate a little BS, and evaluate the response. In programmer land if you ask a candidate what the first line '#!/usr/bin/perl' means in a CGI script and if the candidate keeps cool then thats good, but if the candidate responds like the intro scene of the movie Bladerunner then its probably not so great of a candidate regardless of anything else.

On the other hand, asking theback-end programmer what is a shebang line is totally legit in my opinion, nothing BS about it.

Plus if you are secure in your abilities you should be able to say "no, I'm not quite sure why that could be bad" without feeling like the world is ending. We all have stuff to learn.

It allows the candidate to be far more relaxed and puts him in a situation a lot more akin to the work that he will be doing for your company.

Implement function foo which takes an integer size, and returns an array of that size where each element in that array is a function that returns the index of that function in the array. Testcase: 42 === foo(1000)[42]()

There are 3 different correct solutions. Discuss which solution is better, worse... etc (if they get there)

(could probably be worded better, I'm not an english major)

That said, I'm not thinking of a 3rd solution. Closures(best?), a global(worse), what else?

Edit: As Daiz points out, the bind I was thinking of doesn't even have to even be to a global. But we still have seen only two solutions: variations of binding and closures. What's the third? Inquiring minds want to know!

  - bind
  - function creator outside of the loop called from within
  - create an anon function on each loop iteration that acts like the function creator in #2

The last one creates anon functions needlessly, but is very compact to write.

  function foo(s) {
    a = Array(s);
    for (var i = 0; i < s; i++) {
      a[i] = eval('(function () { return ' + i + '})');
    }
    return a;
  }

Edit: A good Google seems to suggest using JSON.stringify and JSON.parse to copy the value.

Edit 2: But even that doesn't seem to work :(

Edit 3: Got it, using a generator function. Which makes sense. I guess I'm not an expert yet! :)

  function foo(s) {
    function generator(i) {
      return function () {
        return i;
      };
    }

    var r = new Array(s);
    
    for (var i = 0; i < s; i++) {
      r[i] = generator(i);
    }
    
    return r;
  }

  console.log(foo(1000)[42]());

  function foo(s) {
    function generator(i) {
      return i;
    }

    var r = new Array(s);
    
    for (var i = 0; i < s; i++) {
      r[i] = generator.bind(window, i);
    }
    
    return r;
  }

  console.log(foo(1000)[42]());

  function foo(count) {
     var ret = []
     for (var i=0; i < count; i++) {
        ret [i] = function i() { return this.indexOf(i) }
     }
     return ret;
  }

  var count = 1000000;
  var arr = foo(count);
  for (var i = 0; i < count; i++)
    arr[i]();

    var foo = function (arr, i) {
      if (typeof arr === 'number') { 
        arr = new Array(arr);
        foo(arr, arr.length - 1);
        return arr;
      }
      if (i === -1) {
        return;
      }
      arr[i] = function () {
        return i;
      }
      foo(arr, i - 1);
    };

    function foo(n) {
        var result = [];
        for (var i = 0; i < n; i++)
            (function(j) { result.push(function() { return j; }); })(i);
        return result;
    }

    // new Array(n) could just be [] in all examples
    //
    // using Array.prototype.map
    // sadly you can't do new Array(n).map
    // because it doesn't iterate over undefined functions
    function foo(n) {
      for (var ret = new Array(n), i = 0; i < n; ++i) {
        ret[i] = i;
      }
      return ret.map(function(_,n) { return function() { return n; }; });
    }

    // using Function.prototype.bind in a couple ways
    function foo(n) {
      function num() { return +this; }
      for (var ret = new Array(n), i = 0; i < n; ++i) {
        ret[i] = num.bind(i);
      }
      return ret;
    }

    function foo(n) {
      function num(a) { return a; }
      for (var ret = new Array(n), i = 0; i < n; ++i) {
        ret[i] = num.bind(null, i); // could bind this to pretty much whatever here
      }
      return ret;
    }

  function foo(a){
    return Array.apply(0, new Array(a)).map(function(_, b){
      return Number.bind(null, b)
    });
  }

  foo = (n) -> (-> i) for i in [0..n]

Here's one way:

    foo = (n) -> ((a) -> a).bind(null, i) for i in [0...n]

    foo = (n) -> (-> +@).bind i for i in [0...n]

How is `bind` still using a closure? `bind` just allows users to alter a function's execution context. However, the implementation varies according to the JS engine. Some of them may use a closure internally as a part of the process, but I don't think V8 does.

    var foo = function (len) {
      return Array(len)
        .join(0)
        .split(0)
        .map(function (e, i) {
          return function () {
            return i;
          };
        });
    };

> Have you played around with the new CSS Flexbox or Grid specs?

Flexbox is well past the point where you should be "playing around" with it. It's time to straight-up learn it, if not start using it in production. It's ready. And if that leads you to the question of "well what about crappy old versions of IE?", well there's another interview question for you.

Only one question about preprocessors—and a vague one at that? Not even a mention of things like Grunt and Gulp, pattern libraries, style guides, or even the terminal?

This stuff is integral, not optional, these days.

I interviewed a lot of people last year for a senior front-end position that we never ended up hiring for. We made a few offers that fell through but for the rest, I would have ended up teaching them how to do the bulk of the job had we hired them.

Is that really a bad of thing? If they're good programers and quick to pickup new technologies wouldn't you be better off getting them, training them, and when they succeed making sure you're compensating them enough to keep them onboard?

If what you wanted was someone completely versed in all your technologies and systems to just pickup and do the task, I'd say get a contractor who has the skills you need.

So what is the other interview question?

I really haven't dove into flex box because I am stuck supporting IE 9 on both of my projects. If I were to try and implement it on one of these projects it would be a wasted effort when 90% of my users are still using IE 9 on their corporate Dells.

How do you learn and develop new skills if your stuck supporting older browsers?

The question would be "how do you handle browsers that don't support flexbox?"

My answer would be to use Modernizr to detect lack of flexbox support and write some fallback styles.

If you're supporting an extremely higher than average percentage of users on IE 9, then it's worth basing decisions on this fact. Globally IE 9 accounts for 2.13% of usage and that number isn't going up.

There's no way to really learn this stuff other than to just start doing it. Just write fallback styles to support crappier browsers and remember that pixel-perfect designs across browsers was never a realistic goal.

I dont think that is 100% true quite yet. IE9 for example is still quite popular, not to mention the bugs in modern browsers.

http://philipwalton.com/articles/normalizing-cross-browser-f...

Here's the simple answer for supporting old IE: http://dowebsitesneedtolookexactlythesameineverybrowser.com/

But to be more precise, graceful degradation is the answer. I'm building an interface that needs to last for several years, and IE9 is circling the drain. I can't justify making too many decisions around browsers that will be gone soon at the expense of the experience in all the browsers that fully support modern properties now.

IE 8 and 9 will get a degraded experience, but the content will all still be there, and it will look pretty good. But it won't look exactly the same.

But people should be more worried about how it looks on a mobile device, at least 50% of our clients traffic are from mobile devices now a days...

While I agree with your point, most companies I've worked for in the last few years or so are light years from using build systems and preprocessors. Case in point is my current employer. I've struggled for the last year to convince them to use SASS and Gulp to speed stuff up. At every turn, I've been discouraged to implement them.

1st: A company asks those questions because they don’t know better. Someone is good at remembering stuff and does so. He gets the job.

2nd: A company asks those questions because they don’t know better. Someone is a good developer but fails at these questions – with no specific reason. He doesn’t get the job.

    var add = function (x, y) {
      return (
        y !== undefined ?
          x + y :
          function (z) { return x + z; }
      );
    };

    var duplicate = function (a) {
      return a.concat(a);
    };

But it's a good list of things frontend developers should know, nevertheless.

(I'd probably answer with HTAs - handy, compact way to distribute small JS-based tools/apps if you work in a Windows-based office and can eat the IE9 restrictions)

I think you meant: "i'm a lasagna hog"