14 ms·

Front End Developer – Interview Questions

172 points by shridhad 12y ago

steakejjs 12y 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 12y 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 12y 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 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.
  - untog 12y 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.
    - wwweston 12y ago
      Or you had other ways of indicating scripts were meant for processing after the document had been parsed (which might be smart or even essential depending on your support targets). 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."
      - untog 12y ago
        Even if you chose a different implementation in the end, you'd still be aware of what defer is.
        k__ 12y ago
        I've seen it for the first time. 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.
    - Silhouette 12y ago
      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. 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.
  - ibudiallo 12y 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.
    - Silhouette 12y ago
      When I was younger, I knew how do simple things like checking the length of an array or joining a list of strings together or dividing two integers with various kinds of rounding/truncation. I could have told you instantly the correct syntax to do this in every language I knew. 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. :-)
- Alex3917 12y 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 12y 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 12y 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.
  - abrahamepton 12y 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.
- cozuya 12y 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_yay 12y 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.
    - tericho 12y ago
      Like most JS concepts, to me it's a "use it or lose it" situation. When I have to use them they are fresh in my head, when I move on to another project for 6 months that has no complex modules or uses a framework like Angular, there is no way I'll remember the intricacies. That being said, there is still a different between having used them and simply being aware of their existence, which I suppose could be made clear during an interview.
    - alxndr 12y ago
      This sounds like a very good answer to that question.
  - FLUX-YOU 12y 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 12y ago
- tericho 12y 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_yay 12y 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.
  - thejosh 12y ago
    I know what the full term means, but never heard of the acronym before today... So glad I ran across that.
    - spacemarine 12y ago
      (Flash of Unstyled Content) 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.
- jypepin 12y 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 12y 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.
  - deleted 12y ago
    [deleted]
- blowski 12y 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 12y 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.
- arturodomingo 12y ago
  just being vaguely aware of the existence of call and apply should put you ahead of many fizbuz dropouts.
- EC1 12y 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 12y 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 12y 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.
- nilkn 12y 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 12y 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.
    - drinchev 12y ago
      Sure, but I doubt this list is meant to be as THE LIST of all questions that you should ask / be asked on an interview. 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.
  - dropit_sphere 12y 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_ 12y 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.
  - ChrisAntaki 12y ago
    I like to associate `.apply` with "Array", and `.call` with "Columns". f.apply(this, arrayOfArgs); // Array f.call(this, arg1, arg2, arg3); // Columns
    - angersock 12y ago
      "Columns" -> "call()'ems" :)
      - ChrisAntaki 12y ago
        Oh, that's good
    - johnotander 12y ago
      I have a similar association, but use "Commas" in place of "Columns".
- MRSallee 12y 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.
- dustingetz 12y 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 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 12y 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.
ritchiea 12y 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 12y 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.
  - ivanhoe 12y 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_yay 12y 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.
bhhaskin 12y ago
Not a bad list of questions. I think I will use some of these.
- pacofvf 12y ago
  just avoid the fizzbuzz questions, they aren't a good benchmark for good developers.
  - throw_away 12y ago
    fizzbuzz isn't meant as a benchmark for good developers, it's meant to weed out the obviously bad.
    - mcgaffin 12y ago
      Yes, exactly. I wouldn't hire someone because they can implement fizzbuzz, but if someone fails to implement fizzbuzz I can't imagine that I would want to hire them.
mkoryak 12y 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_yay 12y ago
  :(
- speg 12y 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! :)
  - tcqag 12y ago
    Here's a solution using closure: http://codepen.io/anon/pen/KwmQam http://codepen.io/anon/pen/KwmQam
  - b3tta 12y 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]());
    - deleted 12y ago
      [deleted]
freshyill 12y 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 12y 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-flexbox-bugs/ http://philipwalton.com/articles/normalizing-cross-browser-f...
  - freshyill 12y 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/ 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.
    - 12y ago
AustinG08 12y 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 12y ago
"Can you say 'CSS specificity' without jumbling it up, first go?"
forrestthewoods 12y 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.
- cozuya 12y 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.
  - EC1 12y 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.
    - jurre 12y ago
      That seems really expensive?
    - fizwhiz 12y ago
      Notepad++? Or shudder regular notepad?
    - danielweber 12y ago
      How do you get an employee to leave a permanent position for your temporary position?
      - frandroid 12y ago
        Most full-time, permanent jobs have a 3 month probation period at the start of the contract where the employer can fire the new employee easily.
FabianBeiner 12y 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.
- cozuya 12y 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.
  - FabianBeiner 12y ago
    1st scenario.
- arturodomingo 12y ago
  > Someone is a good developer but fails at these questions There probably aren't that many people who can confidently answer 90%+ of these questions, but if someone were to call themselves a good developer, surely they should be able to accurately answer most (>50%) of them.
shawndumas 12y 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); };
deleted 12y ago
[deleted]
ivanhoe 12y 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 12y ago
Any similar resources for back end devs too?
- shridhad 12y ago
  One that I am aware of is https://www.reddit.com/r/programming/comments/2t227g/front_end_developer_interview_questions/ https://www.reddit.com/r/programming/comments/2t227g/front_e...
drinchev 12y 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 12y 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 12y 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 12y 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 12y ago
Is there anything like that for Android developers?
CountHackulus 12y 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.
ggregoire 12y ago
Any similar resources for UX designer? :)
psteynza 12y ago
Wow, being a front end developer must be so fucking lame.
elwell 12y ago
> i'm a lasagne hog I think you meant: "i'm a lasagna hog"
scelerat 12y 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.
abrahamepton 12y 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 12y ago
This one is a joke right? "What's your favorite feature of Internet Explorer?"
- insin 12y 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-YOU 12y ago
  "It downloads Chrome/Firefox quickly."

172 points by shridhad 12y 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 12y 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 12y 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 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.
- untog 12y 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.
  - wwweston 12y ago
    Or you had other ways of indicating scripts were meant for processing after the document had been parsed (which might be smart or even essential depending on your support targets). 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."
    - untog 12y ago
      Even if you chose a different implementation in the end, you'd still be aware of what defer is.
      - k__ 12y ago
        I've seen it for the first time. 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.
  - Silhouette 12y ago
    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. 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.
- ibudiallo 12y 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.
  - Silhouette 12y ago
    When I was younger, I knew how do simple things like checking the length of an array or joining a list of strings together or dividing two integers with various kinds of rounding/truncation. I could have told you instantly the correct syntax to do this in every language I knew. 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. :-)
Alex3917 12y 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 12y 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 12y 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.
- abrahamepton 12y 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.
cozuya 12y 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_yay 12y 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.
  - tericho 12y ago
    Like most JS concepts, to me it's a "use it or lose it" situation. When I have to use them they are fresh in my head, when I move on to another project for 6 months that has no complex modules or uses a framework like Angular, there is no way I'll remember the intricacies. That being said, there is still a different between having used them and simply being aware of their existence, which I suppose could be made clear during an interview.
  - alxndr 12y ago
    This sounds like a very good answer to that question.
- FLUX-YOU 12y 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 12y ago
tericho 12y 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_yay 12y 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.
- thejosh 12y ago
  I know what the full term means, but never heard of the acronym before today... So glad I ran across that.
  - spacemarine 12y ago
    (Flash of Unstyled Content) 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.
jypepin 12y 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 12y 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.
- deleted 12y ago
  [deleted]
blowski 12y 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 12y 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.
arturodomingo 12y ago
just being vaguely aware of the existence of call and apply should put you ahead of many fizbuz dropouts.
EC1 12y 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 12y 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 12y 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.
nilkn 12y 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 12y 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.
  - drinchev 12y ago
    Sure, but I doubt this list is meant to be as THE LIST of all questions that you should ask / be asked on an interview. 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.
- dropit_sphere 12y 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_ 12y 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.
- ChrisAntaki 12y ago
  I like to associate `.apply` with "Array", and `.call` with "Columns". f.apply(this, arrayOfArgs); // Array f.call(this, arg1, arg2, arg3); // Columns
  - angersock 12y ago
    "Columns" -> "call()'ems" :)
    - ChrisAntaki 12y ago
      Oh, that's good
  - johnotander 12y ago
    I have a similar association, but use "Commas" in place of "Columns".
MRSallee 12y 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.
dustingetz 12y 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 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 12y 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.

ritchiea 12y 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 12y 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.
- ivanhoe 12y 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_yay 12y 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.

bhhaskin 12y ago

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

pacofvf 12y ago
just avoid the fizzbuzz questions, they aren't a good benchmark for good developers.
- throw_away 12y ago
  fizzbuzz isn't meant as a benchmark for good developers, it's meant to weed out the obviously bad.
  - mcgaffin 12y ago
    Yes, exactly. I wouldn't hire someone because they can implement fizzbuzz, but if someone fails to implement fizzbuzz I can't imagine that I would want to hire them.

mkoryak 12y 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_yay 12y ago
:(
speg 12y 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! :)
- tcqag 12y ago
  Here's a solution using closure: http://codepen.io/anon/pen/KwmQam http://codepen.io/anon/pen/KwmQam
- b3tta 12y 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]());
  - deleted 12y ago
    [deleted]

freshyill 12y 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 12y 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-flexbox-bugs/ http://philipwalton.com/articles/normalizing-cross-browser-f...
- freshyill 12y 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/ 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.
  - 12y ago

AustinG08 12y 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 12y ago

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

forrestthewoods 12y 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.

cozuya 12y 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.
- EC1 12y 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.
  - jurre 12y ago
    That seems really expensive?
  - fizwhiz 12y ago
    Notepad++? Or shudder regular notepad?
  - danielweber 12y ago
    How do you get an employee to leave a permanent position for your temporary position?
    - frandroid 12y ago
      Most full-time, permanent jobs have a 3 month probation period at the start of the contract where the employer can fire the new employee easily.

FabianBeiner 12y 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.

cozuya 12y 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.
- FabianBeiner 12y ago
  1st scenario.
arturodomingo 12y ago
> Someone is a good developer but fails at these questions There probably aren't that many people who can confidently answer 90%+ of these questions, but if someone were to call themselves a good developer, surely they should be able to accurately answer most (>50%) of them.

shawndumas 12y 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); };

deleted 12y ago

[deleted]

ivanhoe 12y 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 12y ago

Any similar resources for back end devs too?

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

drinchev 12y 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 12y 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 12y 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 12y 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 12y ago

Is there anything like that for Android developers?

CountHackulus 12y 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.

ggregoire 12y ago

Any similar resources for UX designer? :)

psteynza 12y ago

Wow, being a front end developer must be so fucking lame.

elwell 12y ago

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

scelerat 12y 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.

abrahamepton 12y 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 12y ago

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

insin 12y 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-YOU 12y ago
"It downloads Chrome/Firefox quickly."