
Ask HN: How to prepare for a Front-end Developer interview? - eesta
How should I prepare for a front-end dev interview? What type of questions do you usually ask &#x2F; or have been asked in an interview?
======
andrewstuart
Most modern production quality software systems there days are implementing
fibonacci algorithms as part of their core business rules, controlled via a
red/black tree. Usually it's held together by a fizzbuzz architecture so as a
minimum you should be able to whiteboard fizzbuzz. You should understand all
these things well, and really if you are doing modern software development
these things hould be day to day tasks anyway so they should be top of mind.

~~~
cmenge
I agree that it's far from what is needed in everyday tasks, but in defense of
that process: if you are unable to implement fizzbuzz, Fibonacci numbers,
etc., I am _almost sure_ you can't understand react sagas or dependency
injection properly. Mixed with more open-ended questions (why was React built?
how does it compare to Angular? What's a generator function?), I believe this
isn't the worst type of interview.

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

~~~
hifumi
> their portfolios appear to be mostly borrowed plumes.

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

~~~
jimcsharp
When you aren't being forthright with the position you held on a development
team. If you were a late onboard to a project and spent your time firefighting
bug reports, you could perhaps lend cachet to your resume by omitting the
relatively minor role you had in the project. Then you'd be borrowing the
"plume in your cap" from your team, who deserves more of the credit.

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

------
valeriemettler
In my experience, closures are a topic that always comes up. It is also
important to know how to handle a closure inside of a for loop. I've been
asked about "this" binding, coercion, and CSS specificity. I've had to solve
problems that required me to know about how to use stacks, trees, and nested
for loops. Other topics that have come up are how to architect an app,
concurrency, memoization, building out and handling api endpoints, and pass by
reference vs. pass by value.

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/](http://moviemap.xyz/)
More here: [http://valeriemettler.com/](http://valeriemettler.com/)

~~~
mathgeek
> In my experience, closures are a topic that always comes up.

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.

~~~
ShellfishMeme
I agree. We always put the little 'for loop that creates a list of functions
that spit out the current number of the iteration' exercise first in all of
our interviews. Generally, when people solved that one fast, they also did
well in the rest of the interview and if they struggled there, they also had a
hard time coming up with an elegant solution for most of the other tasks.

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.

~~~
danyim
Would that exercise be the following? I'm not sure I understand what's being
tested.

    
    
      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

~~~
ricardobeat
Try writing that same thing without ES6.

~~~
danyim
I'm also in the process of interviewing for a front-end engineer position, so
thank you for replying and providing feedback. I'm assuming it has to be
written this way because the function being pushed was referencing i, which
was within the scope of the closure. Turning it into an IIFE breaks out of
that. Thoughts?

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

~~~
mathgeek
I'd probably ask you to do the printouts from within the function itself.

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.

~~~
weaksauce
neat series of books. thanks for the tip

[https://github.com/getify/You-Dont-Know-JS](https://github.com/getify/You-
Dont-Know-JS)

------
zzzmarcus
You should at least be familiar with the major front-end libraries and
frameworks - React, Angular and Ember. You don't necessarily need to "know"
them, but at least know about them.

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!

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

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.

~~~
eschutte2
I don't understand how that's possible. For example, in a recent project I
needed to implement a path-finding algorithm to draw connections routed around
arbitrarily-placed boxes. More recently, efficiently snap a line to the
nearest edge from an in-memory set of (again, arbitrarily placed and changing)
objects as the mouse moves. I'm having to use and think about some item from
that list on a daily basis. Where's the disconnect here - are we talking about
different kinds of front-end work?

~~~
jonahx
> Where's the disconnect here - are we talking about different kinds of front-
> end work?

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.

~~~
eschutte2
We may be on the same page here. I don't like the way dev interviews are run
and I think the focus on textbook algorithms is misplaced. I would say if your
interview process can be aced by somebody hitting the books for a month,
you're not testing for hard enough things.

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.

~~~
jrumbut
So, so many people do things the hard and reliable way, or don't do them at
all and sacrifice some desired feature, because they don't recognize a well
understood computer science problem lurking underneath a business problem or a
UI implementation.

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.

------
rfrey
If the anecdotes I read here are correct, you should be prepared to implement
a red-black tree in C, followed by an A* pathfinding algorithm on the
whiteboard.

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.

~~~
jasonthevillain
Asking a front-end developer to write a red-black tree is insane. Is anyone
actually doing that?

~~~
krat0sprakhar
I'm pretty sure the OP is making a joke.

------
justrossthings
I'm a front-end dev going through the hiring process right now. Here's a list
of some of the questions I have been asked in technical interviews: \- What is
a clojure? \- What is a callback? \- What is an IIFE? \- How can you use scope
to keep a copy of i in a loop? \- What is going on when you click a link to go
to a website? \- Difference between classical inheritance vs prototypical \-
Difference between object-oriented programming vs functional \- Knowing what
'this' is referencing at different points inside a function/class \-
Difference between <p>, <div> and <span> \- Difference between css selectors:
'.classA.classB', '.classA .classB', '.classA > .classB' \- Difference between
'x is undefined' and 'x is not defined' error messages

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/](https://www.interviewcake.com/) and
Hackerrank can prepare you for programming problems but outside of the giants
you don't often get asked these.

~~~
theshadowmonkey
you meant closure ?

~~~
galori
No he's from the UK. He meant clousure

~~~
theshadowmonkey
lol man.

------
bzalasky
Generally, I start by getting an idea of how well a candidate understands
JavaScript with a problem like this:

Write a function that enables the following API...

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

Next, if things are going well, I have the candidate transform a JSON
collection response to match some arbitrary requirements using
Lodash/Underscore.

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.

~~~
patrickdavey
Pointers on how to improve this (while maintaining your API) would be great :)

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

};

~~~
insin
Bonus points for being meta?

    
    
        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
        }

~~~
tkxxx7
This is neat, but those functions can only be used once.

------
pauljaworski
Here are a few questions/problems I was asked in from-end interviews a couple
months ago:

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...](https://github.com/h5bp/Front-end-Developer-Interview-Questions)

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

~~~
pauljaworski
I understand that point, but I just personally hate the stress and the
irrelevance of the "over-the-shoulder" algorithm problems that a recent CS
grad would be almost more suited to answering. If I'm really interested in
working for a company, I have no issue spending a couple hours building a
little app to prove my chops.

------
dstarcev
In general, don't pretend to be someone you are not. If you don't know
something, just say "I don't know this, but I learn quickly". Being flexible,
open-minded and easy-adapting is much more important today than knowledge of
specific languages, algorithms or frameworks. Google knows everything, you
only need to be able to ask it right questions and handle the answers. So,
just be ready to prove that you are such kind of person.

------
tylerlh
There's a pretty good repository of potential questions for front end
developer interviews on GitHub[0]. I'd suggest skimming through the list and
making sure you've got a decent grasp on most of them.

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...](http://h5bp.github.io/Front-end-Developer-Interview-Questions/)

------
jameslk
Having gone through this situation before, my biggest mistake while performing
this type of interview was not actually having candidates build something with
the team. Frontend development is usually very visual and UX-oriented, so it's
important to see what they can build and their attention to that type of
detail. There's plenty of knowledge questions that can filter candidates down
by experience, but until you get them working in your setting, you won't be
able to see whether they can build something you actually want and get along
with others in a team-oriented way. My suggestion is to give them a small
project they can build during an interview with you/your team.

~~~
jonahx
Couldn't agree with this more. When I originally read the OP's question, I
assumed he was asking how to prepare as a candidate, and you gave a great
answer for how to prepare as an interviewer -- the question is ambiguous and
even on re-reading I'm not sure which he meant.

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.

------
Imagenuity
Understand Big O notation [1] and how to use more technical JavaScript
features like .map [2] and .reduce [3].

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](https://en.wikipedia.org/wiki/Big_O)

[2] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Array/map)

[3] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce)

~~~
sz4kerto
Big O notation is an entry-level question, any fresh grad should know it well.

------
alexashka
Same way you prepare for any other interview - you don't.

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

------
corecoder
Before Babel, I often used to ask about code organization/modularization,
mostly to filter out candidates who haven't been on a big project and have
only copied and pasted jQuery snippets together; today I'd ask if you use
Babel modules and why/why not. As other people have said, closures will surely
come out. A favorite of mine is array functions: map, forEach, filter. Also,
promises, callbacks, workers. Finally, xhr throttling.

~~~
grosbisou
Why would Babel change drastically the way you organize your code? Isn't it a
just compiler?

~~~
corecoder
I really meant ES6 modules, I said babel because it's what made ES6 features
actually usable in production.

------
cvinson
Aside from all the technical questions, don't underestimate the importance of
knowing about the company you are applying to.

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.

------
transcranial
Nice list here, but by no means exhaustive: [https://github.com/h5bp/Front-
end-Developer-Interview-Questi...](https://github.com/h5bp/Front-end-
Developer-Interview-Questions)

------
icc97
For general programming questions I found
[https://www.interviewbit.com/](https://www.interviewbit.com/) very good. It
is both a tutorial and programming questions at the same time.

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.

------
andy_ppp
Closures, specificity, home made getElementsBySelector, DOM traversal stuff,
weird IE things, coding standards, an understanding of how jquery works, how
to protect against npm poisoning/leftpad issues, lodash, semantic naming
strategies, being opinionated (why is BEM shit/great?), box model, floats,
flex box, centering techniques, an understanding of how plane old js works,
cross origin/same origin stuff, basic design principles (spacing, fonts,
information hierarchy, fitts law), react.

~~~
dwaltrip
xhr, promises, a modern build tool (webpack? browserify?), prototypal
inheritance, virtual dom, object oriented programming, when to add more
abstractions and when to tear them down, front-end performance & memory
profiling, browser dev tools, canvas, svg, service workers, browser caching,
cookies, websockets, SASS, Ecmascript 6, API design principles, data modeling,
when to use a hash and when to use an array, basic concepts of UX, and of
course, most importantly, box shadows

~~~
andy_ppp
All correct! Babel, Redux/data flow and immutable data structures. Basic
software design principles. Anything else?

------
encoderer
JavaScript:

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

------
wwalser
tl;dr Have a zen attitude about getting turned down. The best companies in the
world are still spectacularly bad at technical interviews.

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.

------
Justen
I'm in the process of doing this and was told I needed to know sorting
algorithms (among other things) so I made a barebones redux project to stuff
it into. Not sure if this is your case but if it helps, take a look:
[https://github.com/Outc4sted/AlgorithmAtelier/blob/master/sr...](https://github.com/Outc4sted/AlgorithmAtelier/blob/master/src/reducers/sortAlgorithm.js)

------
alexbanks
In my experience interviewing candidates and being interviewed, the experience
is wildly inconsistent. Most times, if it's a Front-End specific position, I
wouldn't (and haven't been) asked about algorithms or data structures. I think
the most important thing is to be able to talk intelligently about a bunch of
subjects. Some examples:

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

------
joeld42
When I interview front-end developers, I take a wireframe mockup, or sometimes
just a screenshot (either from a real product, or just make one up), and ask
"how would you implement this". I want to see if they know the toolkit, can
make good choices, can discuss tradeoff (e.g. should something be a custom
widget or a stock system), can discuss performance (what if that table had
100k items? would it still work?). Then I ask if they have suggestions to
change or improve the design, just to see if they think of themselves as more
of an implementer or as sharing the responsibility with the interaction
designer (both have their place). Finally, I do make sure they can do simple
coding tasks, and give them some questions to test their comp-sci background,
though that wouldn't disqualify someone, it can help.

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.

------
citeguised
It heavily depends on the company and area I'd say.

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.

------
acbabis
Be sure to review these: [http://code.tutsplus.com/tutorials/the-30-css-
selectors-you-...](http://code.tutsplus.com/tutorials/the-30-css-selectors-
you-must-memorize--net-16048). When I interview candidates, I make sure they
know more than just class and element selectors.

------
da_n
I had to demonstrate how to inverse the value of an immutable object hashed
data stream whilst ensuring that the dilithium matrix array was phase
decoupled.

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.

------
ebbv
It really depends on the job you're applying for. If you're applying for a job
at a company that provides SaaS on a particular software stack that's gonna be
really different than applying at a work-for-hire web development house.
There's really not enough information here for me to give you any kind of
useful advice. If you'r qualified for the job you should know the basics that
are applicable to just about any front end web developer job.

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.

------
Rapzid
When I worked at Rackspace I recall the same sentiment as the majority of the
comments here.. Testing for specific things the interviewer(s) happens to have
fresh on their mind at the time. I've fallen into this trap myself and recall
a particularly harsh interview we put an internal candidate through. It was
almost a joke in this case and we wanted him anyway(incidentally he did
surprisingly well regardless), but these were par for the course at the time.
I doubt I could answer the questions I asked as well as he did if I had to
today.

------
meanJim
I usually supplement the interview with a take home project, because front end
web dev (emphasis on web) is about building interfaces and managing state
really well and that is hard to test in an hour!

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.

------
pjmlp
It of course depends on the front-end stack.

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.

------
samblr
Im not an expert in frontend but key concepts kind of remains same across
frontend design: MV*, pub-sub patterns, what not to do in a UI-thread,
lifecycle of a page/view load, talk through on how candidate goes about
representing a given json/xml data to a web page - can candidate show his
skills in choice-and-usage of UI elements here.

Data structures.

Then specifics about language and framework.

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

------
DavidWanjiru
I don't know how these things work, but I'd have thought showcasing your prior
work goes a long way in determining if someone wants to hire you. A bit
similar to how, if I wanted you to create an ad campaign for my product, I'd
more interested in seeing other campaigns you'd done, more than anything else.
To see how you quantified the problem and the solution you came up with. Isn't
that what front end dev is?

------
ilostmykeys
We hire people who've done something great or have attempted doing something
great, and who love to work on finding a better mouse trap, so to speak.

------
k__
The ones that hired me just asked if I can do the job ;)

~~~
teknologist
I got one of my best roles like this. Admittedly there was also a part where I
was asked to share my laptop's screen and after one look the guy said "ok
you're hired."

------
khan4019
Here is a list of interview questions: [https://github.com/khan4019/front-end-
Interview-Questions#fr...](https://github.com/khan4019/front-end-Interview-
Questions#front-end-interview-questions)

------
tn13
Depends on the company and what they are doing. If it is google/Amazon etc. be
prepared for technical interview process similar to other engineers. Same
problems of recursion, dynamic programming etc. with some component of domain
Android knowledge.

------
superjisan
You got this, I believe in you. Go for No and that way you can't fail.

