Front End Developer – Interview Questions

https://github.com/h5bp/Front-end-Developer-Interview-Questions

by shridhad • 12 years ago

172 139 12 years ago

github.com

bhhaskin• 12 years ago

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

pacofvf• 12 years ago

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

throw_away• 12 years ago

fizzbuzz isn't meant as a benchmark for good developers, it's meant to weed out the obviously bad.

steakejjs• 12 years ago

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• 12 years ago

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

jambox888• 12 years ago

Or you knew what those terms meant at some point, but your brain cleared them away when you didn't use them for a year to make more space for the next crazy thing you have to learn.

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.

untog2• 12 years ago

If you don't know what the difference is between <script> and <script defer> that doesn't mean you aren't a competent developer.

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.

ibudiallo• 12 years ago

All these questions test my google skills, not necessarily my front end skills.

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

Alex3917• 12 years ago

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.

thejacenxpress• 12 years ago

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.

thatmiddleway• 12 years ago

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.

abrahamepton2• 12 years ago

Congratulations to you for having memorized many unnecessary-to-remember things then, I guess. I have a good memory for detail and have "spent a lot of time in the DOM" and most of the questions I skimmed I had no off-the-top-of-my-head answer for.

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.

cozuya5• 12 years ago

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.

serve_yay6• 12 years ago

Well, they are both exactly the same. The only difference is the particular way each accepts arguments, and it's easy to forget which is which. So yes you should know how they work, but the distinction between them is contingent and difficult to remember.

FLUX-YOU3• 12 years ago

Call and apply are core concepts to writing good javascript.

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!

lsdafjklsd• 12 years ago

I agree, but I'll say that it wasn't until I started writing non-ember application code (switching to react + immutable.js + pure functions) that I needed things like call / apply / bind on the regular. So writing framework code can really insulate you from needing these things, not implying that that's a bad thing, but personally writing regular javascript has been a breathe of fresh air.

driverdan2• 12 years ago

How often do you use call and apply? I've been a JS developer for a long time, have written a lot of JS code, and rarely need to use call and apply.

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.

tericho4• 12 years ago

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.

serve_yay6• 12 years ago

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

If you really believe this you would probably be terrible at making web pages. (You're probably better off, but still.)

I do agree about call and apply specifically - I write JS every day and often get them switched up. But knowing what FOUC is, or what a doctype is, that's not trivia.

thejosh2• 12 years ago

I know what the full term means, but never heard of the acronym before today... So glad I ran across that.

jypepin• 12 years ago

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.

josefresco• 12 years ago

Ok so what would you recommend be changed? Different trivia? No trivia? Harder code challenges? I tend to agree with your sentiment, however I'm not sure how you'd go about evaluating skills short of an on-the-job test.

blowski• 12 years ago

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.

jameshart• 12 years ago

"If you can do that effectively, you should probably be presenting and writing books on JavaScript."

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.

FLUX-YOU3• 12 years ago

Depending on the role, that might be perfect, or you might be looking for the exact opposite.

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

EC13• 12 years ago

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• 12 years ago

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.

curun1r• 12 years ago

It's also an excellent way to tell the best candidates to look elsewhere for employment. There are some environments where exceptional people will just make waves, get unhappy and leave. If you can filter those people out in the interview process, you can maintain a happy and stable team of mediocrity.

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.

nilkn2• 12 years ago

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.

alexsop2• 12 years ago

I used to use these questions to interview candidate but found it to be really off putting and not terribly helpful.

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.

dropit_sphere2• 12 years ago

if I were going to work exclusively on the front-end

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.

_greim_• 12 years ago

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.

oceanstone2• 12 years ago

I like to associate `.apply` with "Array", and `.call` with "Columns".

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

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

MRSallee• 12 years ago

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.

dustingetz2• 12 years ago

imo the tech lead just has to know this stuff, if he is learning on the job, you're going to end up "throwing the first one away" whether you plan to or not (http://c2.com/cgi/wiki?PlanToThrowOneAway).

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.

noiv• 12 years ago

difference between .call and .apply

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.

mkoryak2• 12 years ago

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)

serve_yay6• 12 years ago

speg• 12 years ago

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

tcqag2• 12 years ago

Here's a solution using closure: http://codepen.io/anon/pen/KwmQam

b3tta• 12 years ago

Using a closure:

  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]());

Using Function.prototype.bind():

  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]());

jnbiche2• 12 years ago

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!

mkoryak2• 12 years ago

The 3 solutions that I came up with are:

  - 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 bind is best in terms of memory and simplicity, but will not run on on IE 8 or crappier, so in that case #2 is preferred.

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

bbotond• 12 years ago

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?

serve_yay6• 12 years ago

That's using a closure, another would be to use Function.prototype.bind (but really that's still using a closure, just putting it out of sight), can't think of any others.

Daiz• 12 years ago

You could use Function.prototype.bind in a couple ways, or even Array.prototype.map (though sadly you can't really do new Array(n).map, if that was true you could make this a one-liner).

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

shawndumas2• 12 years ago

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

evunveot• 12 years ago

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

jcrowe2062• 12 years ago

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

tcqag2• 12 years ago

Just fyi indexOf is O(n), which means if you tried to do:

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

It will take O(n^2) and will probably never complete whereas all the other solutions here will probably take ~1second.

freshyill4• 12 years ago

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.

wnevets• 12 years ago

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

freshyill4• 12 years ago

IE9's global share is 2.13% and 3.84% in the US. It's 2.38% for the sites I'm supporting.

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.

wil421• 12 years ago

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?

freshyill4• 12 years ago

So what is the other interview question?

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.

at-fates-hands• 12 years ago

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

megaframe• 12 years ago

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.

ritchiea2• 12 years ago

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.

VLM• 12 years ago

What it needs is the explanation why.

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.

ivanhoe2• 12 years ago

This is a bit unrealistic... asking someone what spacer.gif was used for could in theory work the way you describe, because it was something wide-spread and doesn't require you to recall too much details, just a general idea. On the other hand, issues like this xml mime-type thing are just too specific to recall after all that time. Frankly I don't remember half of the things that I've read last week and this was decades ago...

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

serve_yay6• 12 years ago

The context of the questions is important - they can tell you what someone knows and what they don't. I don't think the idea is "don't hire anyone who is unaware of the consequences of serving pages as application/xhtml+xml".

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.

habith• 12 years ago

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

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.

ritchiea2• 12 years ago

Makes sense I don't know any of this, I was in high school in the early 2000s.

AustinG08• 12 years ago

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

peteretep• 12 years ago

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

forrestthewoods• 12 years ago

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.

cozuya5• 12 years ago

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.

EC13• 12 years ago

Employment probation. We fired a few people right off the bat within 3 months because they very clearly bullshitted us. One guy fucking used notepad to code. I'm not joking.

thesimon2• 12 years ago

A startup I worked for made the applicants do pair programming for two days. Needless to say, the people getting hired were very good.

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)

FabianBeiner2• 12 years ago

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.

cozuya5• 12 years ago

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.

FabianBeiner2• 12 years ago

1st scenario.

shawndumas2• 12 years ago

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

ivanhoe2• 12 years ago

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

avinassh• 12 years ago

Any similar resources for back end devs too?

shridhad• 12 years ago

One that I am aware of is https://www.reddit.com/r/programming/comments/2t227g/front_e...

drinchev2• 12 years ago

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.

tall• 12 years ago

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• 12 years ago

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.

teh_klev• 12 years ago

Less sleazy would be to ask them to solve an already solved problem (whether you tell the candidate it's already solved or not is up to you).

jrm2k6• 12 years ago

Is there anything like that for Android developers?

CountHackulus• 12 years ago

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.

elwell• 12 years ago

i'm a lasagne hog

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

scelerat• 12 years ago

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.

abrahamepton2• 12 years ago

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.

ArtDev• 12 years ago

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

insin• 12 years ago

Alt+F4 or "the X button", shurely?

(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)

FLUX-YOU3• 12 years ago

"It downloads Chrome/Firefox quickly."

Front End Developer – Interview Questions

Related Stories