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?
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."
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.
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."
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.
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.
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. :-)
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.
>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.
Surely one is capable of customizing the interview based on the candidate?
I'm operating under the assumption here that the candidate has already been working professionally as a front-end developer. Do you really think it's unreasonable to expect someone who's professionally doing exclusively front-end development for a minimum of 40 hours a week to do at least somewhat well on these questions?
I didn't mean to imply that one should completely rule out people who've worked in other domains. But if a full-time exclusively front-end developer is applying for a front-end position, I do not find the idea of asking questions about front-end development to be unreasonable.
For what it's worth, in your example, if I needed someone to work through some very hairy distributed computing problems and someone with 20 years of experience applied who had never once in their entire career worked with distributed computing, yes, I'm going to take that into account. Why shouldn't I? No, that doesn't mean I'm going to immediately rule them out, and I certainly don't think there's a talent shortage, but if someone else applies with 20 years of experience in distributed computing, I'm going to lean towards them initially.
I totally understand the preference for experienced candidates. I'd make the same choice all things being equal.
But I think I'd probably have trouble hiring, and I'd start to think there's a talent shortage.
What we're doing, as an industry, is eating our own seed corn. We're eager to front-run on experience and knowledge, but unwilling to sit around and let them cook. And, frankly, this is somewhat justified, as devs aren't famous for sticking around.
What we should be doing is satisficing rather than optimizing.
If you (and now I mean you you, not the indefinite) were going to work exclusively on the front-end, I highly doubt you'd know the answer to these. Hypothetical: you're fired today, I hire you tomorrow to work on my front-end stuff. Is the first thing you do to start looking up JS trivia?
No! Hell no! Because you're a responsible person. You'd work on...what needs working on. Oh, this page is loading slowly, time to learn how to use Chrome's profiler. Hmm, this div is behaving oddly, time to refresh on CSS.
And yeah, you'd get bitten by something on this list. But...so what? There's always something like that, no matter your experience level, and if you do happen to be that mythical person who's absolutely mastered a stack, surprise! We're switching (back) to Backbone tomorrow.
Would any of this make you unsuitable for the position? I don't think so.
Back to the example, yes, if you've got a hairy distributed systems problem, and someone applies with 20 years of experience in distributed systems, yes, you hire them. But if and when they call and say, "Well, Google offered me more millions than you offered me hundreds of thousands, so..." and you're left with candidates with 20 years of experience divided between COBOL, webmastering, AJAX, Rails work, and open-source contributions to Julia and Battle for Wesnoth...then yeah, sorry you didn't get the unicorn, but that second guy will be just fine. Get the distributed-systems guy in as a consultant for a week or two if you have to. If he really is that good, you might not need to hire anyone at all!
This whole thing is a result of developers overvaluing intelligence and being scared of not being the expert on something, employers buying it that programmers are superpeople, and then acting like it's a betrayal of trust when they don't know every small detail of every technology they've ever used, and both parties' refusal to think about what they need, rather than what they want. The tell-tale sign is that "hiring is hard," but there are still technology companies around. Sure, if you're hiring better ("top 1%") people rather than good ("good") people. And developers are just as bad: not everyone can be paid above average.
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.
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.
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.
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.
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.
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.
"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.
>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).
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.
>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!
Fairly often. Since the selected DOM element is the value of this in any event handler callback, you can migrate out the function and use it for different things (i.e. validation of, say, autofill after a settimeout) and different contexts with call/apply.
I don't see how this requires you to know the intricacies of call/apply or how it would even force you to use it frequently enough to understand the difference.
I guess I don't understand. There's a lot of ways to accomplish tasks in any programming language but in JS in particular there's a way to assign the value of this and you can use it to have clean, dry code, and I'd expect any sr. level people to know how to use it. jQuery source has over 100 uses of call and apply.
> jQuery source has over 100 uses of call and apply.
Right, jQuery does it for you. You usually don't need to do it yourself unless you're contributing to jQuery (or another lib/framework that needs them).
I might ask someone about call and apply but wouldn't be overly concerned if they didn't remember the exact syntax or mixed them up. I've done the same myself. I wouldn't expect someone to remember every little nuanced part of a language, especially if it's not something they use frequently.
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.
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.
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.
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.
> 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.
> 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.
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?
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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?