Front End Developer – Interview Questions

[steakejjs]

This looks like a giant list of trivia that has almost no bearing on the day-to-day effectiveness of the candidate.

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?

[dkrich]

I was thinking the same thing. I've built manys a website in pretty much every front-end language imaginable and I would struggle to answer many of these. Yet I feel little shame in saying that I believe myself to be a very competent programmer. What is the significance of having memorized a bunch of arbitrary terms? If you don't know what the difference is between <script> and <script defer> that doesn't mean you aren't a competent developer. It means you've never needed to know that to this point to successfully build a web app to meet a business need. If I'm hiring somebody I'm much more interested in whether they can actually build shit in a smart way when asked to do so, and with minimal guidance. We live in an age with ample internet access and a plethora of on-demand information resources. Why must we pretend that we don't?

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."

[nilkn]

I'm not sure I agree, actually. There were definitely several questions here I couldn't answer, but I definitely feel as if I should be able to answer them if I were going to work exclusively on the front-end (I'm primarily a back-end developer and have been for most of my career).

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.

[thatmiddleway]

Completely disagree. While some of the questions had me look to the internet, most I was able to answer. I think that the more time you spend in the DOM, the more you run into these things and they become part of your knowledge set. Working on the same application day in, day out may not enforce this kind of knowledge, while having to create, work on and maintain a variety of applications will enforce knowledge retention. I'd argue that it's the difference between someone who works on a single product and a contractor who has to work on something new every hour/day/week.

[jypepin]

Same. I do a lot of live coding interviews, mostly front-end because this is my role, and I found those questions either way too easy, or just useless.

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.

[blowski]

There are some good questions, on there, but as you say, a lot of them read like "Front End Developer Trivial Pursuit".

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.

[cozuya]

Call and apply are core concepts to writing good javascript. I would not hire someone (at least for any sort of senior role) that could not tell you exactly how both of them work. Many of the other things on this page are certainly "trivia" that could be addressed by google when they come up, but not those.

[tericho]

I started as a back-end developer (well, a software developer) and have made my way towards the client over the years. With my background in engineering (eg. learning how things work) I can confidently answer most of the questions. But I can see how modern "front-end developers" would have trouble with a LOT of them since today it's more about getting things to work than how or why.

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.

[Alex3917]

> 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?

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.

[_greim_]

> doesn't remember the difference between .call and .apply

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.

[EC1]

Any company that asks me a series of mundane questions in a conference room is not who I want to work for. It implies senior management has automated the engineers out of the job and are left with a "template".

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

[ojbyrne]

The primary purpose of the "giant list of trivia" method of interviewing is to give you cover to only hire people who have "cultural fit" - i.e. look the same, speak the same, and act the same as the people interviewing.

[MRSallee]

> 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?

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.

[thejacenxpress]

Completely agree. I saw some red flags while going through this. The buzzfizz problem I've heard many a time over is a fun exercise problem but not a good interview question. Also many of the questions seem unrelated to todays standards. The HTML questions ask "difference between quirks and standards mode". Last time I used quirks was with IE6. Also "what are the limitations of XHTML". Don't honestly think I've ever used XHTML in my 4 years as a developer.

[drinchev]

I know this repo. I've used it a lot of times while interviewing front-end developers.

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.

[forrestthewoods]

As an interviewee: "This is what I've in my career. If you'd like to give me money then I can do those things for you."

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.

[cozuya]

Without asking technical questions, how would an interviewer weed out the people who say the former but can't actually back it up? Because if the above is the entire hiring process, your junior developers aren't going to have to be concerned about their imposter syndromes, because they'll be working along side actual imposters.

[ritchiea]

Anyone else feel like there is a lot of esoteric information here? For instance:

> 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.

[tall]

I don't really care for this style of interviewing. A technique that really works is to take a problem the company is currently facing, slim it down and present it to the candidate pre-interview. Then when he comes in you ask him to explain his solution, and the choices he made.

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.

[shittyanalogy]

It's also kind of sleazy as you're getting them to do work for you for no pay. I've been in interviews where similar questions were asked, and they had me go into more detail as I was actually solving problems for them.

[peteretep]

"Can you say 'CSS specificity' without jumbling it up, first go?"

[mkoryak]

I really like this js question (whiteboarding):

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)

[jnbiche]

It's a good question, and a pretty fair one for a Javascript developer to know, given the role that closures play in the language.

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!

[speg]

I feel bad, because as I was writing a solution to this I knew why it wouldn't work and why (returning my counter variable returns the value at the end of the count) but I still couldn't come up with a fix :(

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! :)

[jcrowe206]

Here's another one. Probably not very performant

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

[evunveot]

I may have discovered the worst correct answer:

    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);
    };

[bbotond]

The only solution I could think of is this:

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

What are the two others?

[shawndumas]

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

[serve_yay]

:(

[freshyill]

This has been around for a few years and it's due for some major updates. The CSS questions are becoming very, very dated.

> 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.

[megaframe]

> 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.

[wil421]

>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.

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?

[wnevets]

>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.

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...

[at-fates-hands]

>> This stuff is integral, not optional, these 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.

[FabianBeiner]

Lets imagine the two worst case scenarios here:

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.

[cozuya]

While there's definitely a lot of useless trivia (worse, useless trivia from 5+ years ago that no longer applies at all) in this list, the good parts of these questions _are the job_. If you don't know how to answer the relevant questions in this list, you aren't a good developer. There is currently an explosion of "front end developers" who don't know anything at all beyond "here's where I put in the bootstrap class to make the page look right" and "here's where I put in the angular expression" (or jquery plugin). Asking questions like this weeds them out.

[abrahamepton]

These questions make me angry by being so fucking dumb. No I don't know off the top of my head what splitting on an empty string does and if you give a shit whether I do that tells me all I need to know about whether I want to work for you.

[AustinG08]

Man, the hardest questions for me to answer was the first one: "what did you learn yesterday/this week"? I do so much reading and research in my free time and then to realize how hard it was for me to summarize what it was exactly that I learned. Maybe I just read this stuff for the short term stimulation. When it comes to comprehension and retention maybe I'm not getting out of it what I thought I was. Maybe I should start asking myself what I just learned after everything I read and take some notes o_O

[ivanhoe]

IMHO this can go as an example of a totally wrong way to formulate questions. Interview questions should be about the general concepts, not the tiny details, leave that for quiz shows. You want to know if the person understands how things work, not to test her memory. People can always google out the details that they can't remember, as long as they know what to do with this info...

[shawndumas]

The 'make this work' examples are kinda silly, no?

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

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

[scelerat]

A few selections from this list might make up a fraction of a phone screen, not so much a full in-person interview.

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

[ArtDev]

This one is a joke right? "What's your favorite feature of Internet Explorer?"

[elwell]

> i'm a lasagne hog

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

[bhhaskin]

Not a bad list of questions. I think I will use some of these.

[pacofvf]

just avoid the fizzbuzz questions, they aren't a good benchmark for good developers.

[jrm2k6]

Is there anything like that for Android developers?

[CountHackulus]

Turns out that most of these questions can be answered with just "arson", and I might even consider giving a further interview to someone that actually did.