Fizz/buzz, graph traversal, and etc actually come much more easily for me haha.

See the other side: a significant number of applicants can't implement fizzbuzz, Fibonacci sequences or anything, but ask for ridiculous salaries and their portfolios appear to be mostly borrowed plumes. We need a process that isn't too time-consuming to id the chaff, allowing for false negatives (people who are good at Fibonacci numbers and interview questions, but not much else), but keeping the false positives low (I explain the Fibonacci sequence first so it doesn't become a math riddle rather than a programming task).

I don't understand this phrase. What do you mean by borrowed plumes?

edit: this is my best-fit guess. I have no idea what I'm talking about.

Most business do ask for technical questions, but more like how do the UML diagram of some architecture, how to write SQL queries, implement some code to make their unit tests green, describe what is virtual method dispatch and so on.

You may not think databases are a front-end topic, but I have been asked about them on more than one occasion. Prepare to talk about sharding, natural primary keys, what your favorite database is and why, etc.

Something that has been extremely useful for me is to have a project that I've built myself to show and talk about during the interview. Although I have had one interview where I was asked to talk in detail about how I built some of my projects that are in my github, I like to respond to general technical questions while referencing something I've built. A lot of times the interviewer will then use my app as a starting point into a discussion for how I would scale it. Here's an example of an app I built quickly and have used for discussion in interviews: http://moviemap.xyz/ More here: http://valeriemettler.com/

Opinions will differ, but IMHO closure is a great concept to divide those who know JS at a conceptual level (or at least have crammed for the interview) from those who don't.

What I also like about it is that a closure isn't the only way to solve it. You can use `let` for example to make sure the variables are block scoped, or use `bind` to partially apply a function with the number.

So in the end it's a conceptually very simple exercise that can give you a very good insight into how much the candidate knows about how JS actually works.

  const f = (k) => {
    const funcs = [];
    for(let i = 0; i < k; i++) {
      funcs.push(() => i);
    }
    return funcs;
  }

  const test = f(4);
  console.log(test[0]()); // 0
  console.log(test[1]()); // 1
  console.log(test[2]()); // 2
  console.log(test[3]()); // 3

  // Assuming pre-ES6
  function iterate(k) {
    var funcs = [];
    for(var i = 0; i < k; i++) {
      (function(num) {
        funcs.push(function() {
          return num;
        });
      })(i);
    }
    return funcs;
  }

  var itTest = iterate(4);
  console.log(itTest[0]()); // 0
  console.log(itTest[1]()); // 1
  console.log(itTest[2]()); // 2
  console.log(itTest[3]()); // 3

If you haven't already read them, I highly recommend the You Don't Know JS series of books. One of them covers this exact question.

https://github.com/getify/You-Dont-Know-JS

As an interviewer I can see why you would want to force someone to jump through arbitrary hoops like that but if someone can show me `() => i` and explain why that works, that would be good enough for me.

In fact I would argue it's important that if the candidate shows practical knowledge of ES6 you need to make sure they also grasp the actual semantics (i.e. they won't rely on implementation details of Babel and run into errors in native ES6 environments).

That said, if you are hiring for a dedicated frontend developer role, the majority of JS you write will have a build step. If it has a build step, you should use modern tooling. If you use modern tooling, you might as well include Babel to make the developers' lives less of a pain.

You should be familiar with what ES6 is and what Babel does. These technologies probably won't be specific questions per se but if they come up and you can't speak about them, it'd be a red flag.

Even for a front-end developer you should have a basic knowledge of data structures like linked lists, binary trees, min/max heaps, depth/breadth first search, tries, recursion, hash tables, etc. These often come up in whiteboarding questions.

Practice whiteboarding on an actual whiteboard so you get used to writing code then practice on hackerrank so you get used to quickly writing code that actually compiles. Some companies only use whiteboards, others want your code to run.

Make sure you think of test cases for your problems. TDD in an interview is usually a good sign.

Usually knowing this stuff and having some sample code will usually get you through most of the interview. Knowing the specific things mentioned in other comments is useful, but I can't imagine not hiring someone because they didn't know some specific CSS selector or how to use flexbox.

Other tips - don't get visibly flustered, talk your way through problems. Stay postive about past employers. Good luck!

I would never care about these if I was specifically hiring a front-end dev. I've never once seen any of them come up in the context of front-end work in my entire career. And in fact an interviewer asking questions about them would be a huge red flag for someone who prioritizes nerd-cred over actual business needs, and is therefore likely to make poor decisions.

As an incredibly simple example that comes up all the time, if you get back a collection of items from an API do you store them in a hash keyed by id or in a list? If you can't reason about how e.g. lists are ordered but a hash has O(1) access, and use that to decide which is better in a particular case, you won't be a very strong front-end dev.

Not to mention if you need to dig into performance issues, e.g. dropping frames in animations or something.

I've also seen a lot of frontend bugs related to not thinking about/dealing with asynchronicity well. That's not a data structure problem per se, but you need a working knowledge of some basic CS concepts like threads, concurrency patterns, queues, etc.

I think the key in interviews is that this stuff shouldn't be evaluated like a school exam, where you need immediate recall of all the terms without stumbling. It's all about being able to work towards the right answer and it's fine if that involves a bit of asking or googling to double-check your ideas.

Yeah I would assume so. Of course if know the job requires such knowledge, you should interview for it. But I'm thinking of more average front-end work, where you'd be building forms or dashboards or ordinary websites.

It sounds like you're building a complex application that just happens to be hosted in a browser. Although even then, I'd argue that while your knowledge of when to apply those algorithms is important, you still shouldn't be writing them yourself. You should be finding a well-vetted library and taking the function from there.

I was just a little surprised about those particular items because I feel like they're such an essential background for all software development. But I don't think they should be quizzed for in an interview.

I'm not saying that's what anyone in this discussion is doing, just that I see it everywhere (and have done it myself). 1000s of lines of incomprehensible code because no one realized that this drag and drop flow chart creation interface can be understood as a graph.

I'd say if someone can independently learn the things you think are important enough to interview around in a month then they're the sort of person you should be hiring, unless you don't expect new problems to ever emerge you'll need people who can develop their knowledge anyway.

But binary trees? Last time I needed them was in a CS class. Linked lists? They only came up when I had to convince a coworker that we really don't need to implement one in JS, we only have 50 items here, and someone is going to forget to update a linked list if we use one.

Then sometimes you see a "front-end developer" role and you find out it's actually a designer role.

I don't have a ton of actual front-end dev experience but when I get to do it in my consulting role I like it. So I'm trying to move into a role like that but the comments here make me think I don't have those skills. I don't have a strong CS background but was hoping I could still do front-end dev work. Then people are talking about algorithms and being a math minor and I'm not sure I could do that.

Be that knowledge of data structures, algorithms, ui design, ux, project management or advertisment. Especially in startups where you can't afford dedicated teams for every aspect.

If the team is already strong on the design/ux front, I might favor a candidate with better cs fundamentals. And if my team mostly consists of the latter, I might favor a "worse" programmer but one who knows and cares about typography, color harmony, paper prototyping etc.

I just find this extremely unlikely if not borderline impossible. Hash tables are one of the most universal data structures in practical software development. This is just as true in JavaScript for front-end work as it is anywhere else.

Would I hire a front-end developer who didn't know that, or didn't know that they had O(1) lookup time? Very possibly. Because there are so many things that are more important than that knowledge when you are actually building software for a business. Things like experience with usability testing, JS/CSS build tools, unit testing and refactoring, a decent eye for graphic design (even if they won't be doing that work themselves), an open-mind and lack of ego -- just off the top of my head, these are all things I'd consider orders of magnitude more important than knowing technical details about hash tables.

I would find these things very relevant if you were working on apps that deal with large datasets as picking the wrong data structure can lead to slow execution. It's also good to know what the limits of the candidate's knowledge is.

But unless they're being hiring to develop a library, they don't need to have these algorithms memorized.

Now, about most of the other things that were mentioned… I'm not convinced.

Your graph example could just as well also be a tree example depending on the structure of the dependencies. Hash tables show up everywhere. Recursion is a natural and general programming technique. That only leaves linked lists, tries, and heaps from the original list. I'd agree that these are less likely to pop up in general front-end development, but it's not impossible to imagine them being useful.

I'd rank the concepts from the list in this order (obviously very subjective):

- Hash tables. Universal concept in programming. If you don't know this, you don't know how to program.

- Recursion. General technique for structuring code. Not understanding this indicates a severe lack of exposure to code in general.

- Graphs. Lots of data is naturally structured as a graph. I think it's natural to include trees in this category as well.

- Linked lists. Classic data structure. They're mainly worth knowing about in order to be aware of their performance shortcomings with lots of data. It's less about knowing when to use one and more about knowing when not to use one.

- Heaps. When useful, they tend to be incredibly useful. But they're not all that useful for front-end development.

- Tries. Similar to heaps in this regard.

Personally, I think for a purely front-end role that won't be focusing on the development of new libraries but just the usage of existing ones, I'd focus only on hash tables from this list and use the rest of the interview for more targeted questions.

Most of these have not come up for me ever when interviewing with a strong frontend bent, even at companies like Google. Recursion has come up for me some (mostly for senior or higher positions), and knowing space/time complexity, but otherwise nothing super specific for frontend.

In the past year or so, I've been asked to live code various UI components at a fairly dependable clip, whether it be a typeahead/autocomplete, components with iteration (i.e. containing lists), and aligning various elements horizontally and vertically. Oftentimes these questions lead to various other questions while carrying out the implementations, probing for knowledge on various approaches and various tradeoffs/benefits of each approach.

That's a nice thought, but what if your past employer was Oracle? Doesn't honesty count for anything?

I think the best preparation you can do is to spend several hours reviewing your old projects.

For each project, recall and be prepared to explain in depth:

- The biggest technical challenge you faced and how your team solved it

- The technical tradeoffs your team made in the implementation, and whether you would make the same tradeoffs today

- What your specific contributions were to that project.

- If you can bring code that's great; if not then have the high-level design in your head and be ready to outline and explain it.

If you're anything like me, for three or four projects that represents a couple days or more of preparation.

I think the front-end interviews I’ve been to and run are different to the ones you have.

Programming problems: - Calculating fibonacci numbers - Depth-first binary tree search - Turning a hashmap with multiple levels of embedded hashmaps inside-out - Handling API response data to create new objects - Creating a login form - Using media queries to make responsive pages - Determine if word is a palindrome - Using recursive functions

Knowing methods to reduce computation time and space with hashmaps and arrays is important. You will also be asked to state the computation time and space of your solutions

Framework-specific questions: - What is the difference between a component and a directive? (AngularJS) - What is the difference between a service and a directive? (AngularJS)

I'm sure there's more I've forgotten.

https://www.interviewcake.com/ and Hackerrank can prepare you for programming problems but outside of the giants you don't often get asked these.

Write a function that enables the following API...

    createOlympian()
      .name('Katie Ledecky')
      .sport('Swimming')
      .country('USA')
      .log()

    // Katie Ledecky, Swimming, USA

After that, I focus on the candidate's experience and talk about projects they've worked on, their process and what they're looking for in their next position.

If you're a front-end candidate that's solid at design, visualizations or complex layouts, I'd encourage you to bring your personal laptop and show off some of the work you've done on your own.

var createOlympian = function() { return (function() { var attrs = []; // private variable for our olympian attributes

    var olympian  = {
      name: function(name){
        attrs['name'] = name;
        return this;
      },

      sport: function(sport) {
        attrs['sport'] = sport;
        return this;
      },

      country: function(country) {
        attrs['country'] = country;
        return this;
      },

      log: function() {
        console.log(attrs['name'] + ", " + attrs['sport'] + "; " + attrs['country']);
      }
    };

    return olympian;
  })();

    function createOlympian() {
      let props =  ['name', 'sport', 'country']
      let olympian = {
        log() {
          console.log(props.map(prop => this[prop]).join(', '))
        }
      }
      props.forEach(prop => {
        olympian[prop] = function(value) {
          this[prop] = value
          return this
        }
      })
      return olympian
    }

Write a function that accepts an array of ints and a target number. If two of the numbers in the array can add up to the target, return their indices. (aka Two Sum)

Write a function that accepts an int x and prints a spiral of "#"s so that the number of "arms" in the spiral equals x.

Write a function that accepts a month and a year, and draws a calendar view of that month.

Given a non-negative int x, repeatedly add all its digits until the result has only one digit.

I think I was also asked something that involved a tree structure, but I can't remember the specific problem.

I thought all of those questions were fucking stupid. The good interviewers, IMO, gave me a "take-home" problem of building some mini front-end app that hit an API, and the really fun one involved reverse engineering an unpublished API - that's how I got my current job.

I spent a lot of time studying the h5bp Front End Interview Questions[1], and the only front-end specific question I was asked was, "What is an SVG sprite?" during an initial phone chat with a CEO.

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

I agree with you, but whenever this subject comes up, a lot of folks here on HN complain that they have full-time jobs and families and don't have time for "take-home" questions.

Ideally you'll get mostly questions that are relevant to what your job will be, but I wouldn't be surprised to see some CS stuff in there as well (basic data structures & algorithms). Good luck!

[0]: http://h5bp.github.io/Front-end-Developer-Interview-Question...

To add to your answer, having them build a clone of a simple game in 1-3 hours, especially when they have to balance a bare bones look with more features versus a slicker look with fewer features, and deciding which to cut and what's important to them and how they think about it -- all that can be revealing.

I get asked these frequently, and it was never mentioned to me when I asked for advice on how to prepare. This may be specific to senior developer positions.

[1] https://en.wikipedia.org/wiki/Big_O

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

There are a ton of developer positions, after going through about 5-10, you'll know every question they ask you, off the top of your head.

So there's no need to stress or prepare - you'll screw up the first few and it'll get easier going forward.

The mindset you should be coming in with is I'm a new guy, willing to learn and work the extra hours. I don't know everything and will need a little mentoring to get me going - if you don't offer that, that's ok, there's plenty of other places that do.

You're just starting out - you'll get screwed on salary and get worked to the bone for the first few years until you learn to say no. The advice I'd give is have a little more confidence in your inner voice that tells you when you're getting fucked - and know that you're right.

That's more important :)

Not to mention needing to handle .fetch()s lack of abort if you're not using xhr.

1. You can solve that already in ES6, by returning fn from a function, also avoiding the global variable;

2. Your ES3 linter should warn you about the redefined variable.

I've hired several developers over the last 10 years, and by the final round, there are often candidates with similar technical ability. The applicant that really understands the company they are applying to work for (the current state of their app, their competition, the direction you think they may need to go) will have an edge.

I was asked to describe the important properties of a hash map in a telephone interview. The interview contained less technical questions but various developers asked me about all areas of my CV. There was also a HTML/CSS/JS coding exercise to create a small application to a spec that they gave.

So expect to get questions on anything that you've put in your CV. If you're not familiar enough with it - take it out of your CV.

For example, in a recent string of interviewing here for a couple of large SF-based companies and startups, I've encountered questions like re-implementing jQuery, doing the JS for the game Snake, palindrome checkers, longest chain of ascending numbers in an array, shortest path, matching node (given a node in one tree, find the same node in an identical tree), and basically a whole bunch of other questions where only JS skill were assessed.

-Variable hoisting

-Es6/Es2016

-Experience with react, angular, or another modern js framework

-Do you understand build tooling? Webpack? It's becoming a standard.

Css:

-Given a task of basic ui animation, are you still using js or have you adopted css transitions and animations?

-Do you have experience with sass or less? Opinions?

Html5:

-Know it.

Http2

-How will this affect your life as a front end developer?

Tradecraft:

-What can you do when working with designers to make handoff easier?

-When is something good enough to ship?

-how do you learn a new, complicated code base?

Whew, reading these answers is depressing. Not because of any of the answers that anyone has given (they are mostly good) but because it's a reminder of the state of both software engineering interviews and the state of the JS ecosystem.

I recently started a company but before that I was at a company that would be considered by most to be top-tier amongst places that create web based software. After leaving that job I interviewed at and received offers from several other places that are top tier by SV standards (think GooAmaFaceSoft and their similarly hyped but non-public peers).

One of the interviews was over coffee because networking really is the bees knees (there were further rounds involving actual programming). While it started as a fairly straightforward "tell me about…" interview, we eventually got to just chatting as peers in the industry. One of the points of discussion was the state of interviewing technical candidates. I've interviewed >150 candidates over the past 8 years. I'm opinionated about all sides of the process and I think I as well as the rest of the industry have a lot to learn.

In a moment of candor I said to the person across the table something along the lines of "I'm very confident in the fact that I'm a great engineer overall and that I'm particularly skilled and highly marketable as a JS dev because that's what I've been focused on for the past five years. That said, throughout these interviews, I wouldn't be surprised if I get an offer from about 50% of my interviews."

The person who has sat down to interview me and would later give me an amazing job offer mostly agreed with my statement. They tried to be comforting asserting that it would probably be a little more than half. In the end I got offers from 3 out of 5. All three of the offers were had a first year take home north of 2x my previous salary.

None of this is an indictment of the companies that turned me down, I just think it's worth saying to someone prepping for interviews that there's a strong chance that you'll get turned down. You might truly bomb and interview and you might walk away thinking you nailed it only to learn that they didn't feel the same way.

Don't let it get to your too much. Zen mode, enabled.

- Do you know a client side MVC? Do you know why the internet thinks this client side MVC is bad? What are some alternatives? When should you use what?

- Why is SASS valuable?

- In javascript, describe the this keyword. What is the difference between Call and Apply? Bind?

- What is prototypal inheritance? How do you feel about it (no right or wrong answer, just a thing to talk about).

- Typical web security vulnerabilities.

If I whiteboard a candidate usually it'll be something very basic, something like write a palindrome function in JS, then write it a different way, then tell me when to use which. Also, I ask a lot about a candidate's interests. Why do you think Elm is cool? What've you written with D3 that was nifty? Talk about the problems you've solved, how you solved them, and why it was interesting.

Most importantly: be passionate about learning and doing.

Oh yeah, I also ask them to talk about how to make an interface feel responsive even though most actions can trigger a network call that may take several seconds to respond.

At my company, an IT-Consultancy in Germany, the junior-position-baseline is a solid understanding of HTML and CSS, and at least a basic grasp of Javascript. For mid-level-positions I expect "fluency" in all of those areas, plus a good knowledge of standard-tools and accessibility. I also look for a good foundation in either design or CS, depending on the interviewees background.

The interview is the same for every level, though we look for different things of course. We ask the applicants to set up a basic front-end-file-structure and to start coding a design we created specifically for interviews. During that we ask them to think aloud and talk about the reasons they do things the way they do.

The second exercise is a palindrome-function in JS (or on the whiteboard for juniors).

They seem like simple tasks, but you wouldn't believe how many interviews we had where the person couldn't even code an img-tag from mind.

I understand that at Valley-Companies/Start-Ups, Frontend-Development includes many more advanced topics than in our case.

Seriously just be yourself, don't over think it. If you don't know something, don't be afraid to so, but you're keen to learn if it is something useful. You can't know everything, no one can, just be confident in the things you do know. Nothing worse than a faker, you'll be caught out anyway, you're going to be judged on your strengths not your weaknesses, unless the employer is crappy, and you wouldn't want to work for them anyway.

Good luck.

I'd try to find out as much as you can about what the company you're applying to does so you can get familiar with that stuff.

Some of the more domain specific stuff is about building a scalable components library that your team can use, testing your code, building assets in the most elegant way possible (gulp, webpack, grunt). So make sure you're very honest with your resume!! (dishonesty is bad).

For the case of front end web, here is what I would ask from the top of my head (thinking aloud):

- A good interview will have some pair programming. I usually like to give a very simple mock. These mocks will have a simple task where I will ask you to implement me a two column layout, or a popup window. Therefore I'd like to see that you have strong fundamentals of CSS, HTML, and Basic DOM manipulation using JavaScript. Nice interviewers will allow the use of google!

- You should understand how a network request and response works. I'll probably ask you to teach me what an AJAX request is to start. I hope to have a good conversation because I forget things often and like to learn from others.

- I will probably ask you what are some ways to implement components that won't produce side effects in a large codebase.

- I will probably ask you questions about how you plan to work with Design and other product stakeholders to ensure that you're able to iterate quickly on the front end. This is because requirements and design changes frequently (more common with companies that are focused on product versus growth/retention).

- I will ask you how you approach testing, and how do you ensure your interface will work cross browser, cross device.

- If you're really a generalist and you have no front end experience but a lot of other programming experience, I'll probably ask you to serialize a network response with JSON, where you'll create a map of ids and their resources (for fast access!) and walk through an object tree to do this. We can probably pseudo code this if you've never touched JavaScript and know nothing about its data structures (this jon snow case is rare, like jon snow).

- If you're really junior I'll ask you a generic algorithm question because I'm probably going to train you on the job anyways. No one should be punishing junior people for being junior with stupidly difficult domain specific questions. Don't work somewhere where they punish you for being junior because they won't realize how much potential you have (you have a lot).

Last note: Good luck and have fun, remember to be yourself and try your best.

HTML, Android, iOS, UWP, WPF, UWP, Qt

General design questions how a specific design would be implemented using the stack best practices.

Things not according to your opinion should have been designed better.

How to create an UI component in a specific stack.

How to avoid freezing UI effects and the best practices to have a responsive (in speed) UI.

How to use the framework features to adapt to several screens.

In the specific case of HTML, some additional general questions about JavaScript, with the typical this trap.

Data structures.

Then specifics about language and framework.

Knowledge based questions like comparing frameworks - pros and cons. Technical challenges overcome in previous roles.