
Front End Technical Interview Best Practices - mrharrison
http://popsnip.com/topic/36/Front-End-Interview-Techniques-and-Questions
======
RKoutnik
This is one of my least favorite interview antipatterns: multiple small tasks
that only show understanding of one of hundreds (if not thousands) of concepts
front end devs should understand. Most things here are easily googleable - why
judge someone on something that won't hamper them if they blank on it in the
day-to-day?

Pub trivia is fun in the pub but absolutely rubbish for determining if a
candidate is good at what they do.

------
aaronbrethorst
I like to ask the candidate to do a code review on a pull request. It needs to
be something where they'll be able to demonstrate a good grasp of the
fundamentals of software engineering, along with a solid understanding of the
specific platform they'll be working with. Bonus points if the pull request
introduces a couple subtle bugs they'll need to ferret out :)

------
unclebucknasty
I never did well in interviews wherein someone asked me to solve a problem
while they watch. Too conscious of their presence, I suppose. Give me time to
think without someone breathing down my neck and I can demonstrate my
aptitude.

So, seems to me a better approach for some candidates is to allow them to do
some of the work from home or otherwise unattended. It's a more realistic work
scenario anyway.

But, these types of interviews are de rigueur. Am I that unusual in finding
this challenging?

~~~
Luyt
Nope, I used to be somewhat nervous too, when someone was watching me. Not
knowing where to begin, doing things slower than normal, losing my train of
thought, etc... I did two things to overcome this: 1) showing people source
code on my laptop while browsing, navigating and explaining it, and 2) develop
new features in a coffee shop with lots of people around. I guess I found the
nearby physical presence of someone distracting - but not anymore.

------
wonkaWonka
I just hate the concept that there exists such a stratification, such as the
"front end" developer.

I similarly hate the distinction "qa developer" which seems to the ear like
parlance for a hobbled, maimed version of an "actual" developer.

It's like HR and technical recruiters are making designs to pay you less, and
harp on the fact that you somehow incur less responsibility, solve less
challenging problems, and therefore, mostly importantly, deserve to be paid
less.

~~~
jaredhansen
> _It 's like HR and technical recruiters are making designs to pay you less
> ..._

This is not an accurate description of the primary reason the term "front end
developer" exists, and moreover is an unfortunate example of the unhelpful us-
vs-them conspiracy theorizing that seems so prevalent lately.

The term "front end developer" exists, like the term "backend developer" to
denote a particular specialization. If I need to improve the look and feel of
my web app, someone with a strong design sensibility and a lot of experience
in the latest web development technologies (i.e., a _front end developer_ ) is
who I want -- not someone with a lot of experience doing low-level memory
management in C for a graphics engine. The latter might be a great programmer,
but won't be as helpful, as quickly, as the former.

In any case, frontend developers, as a class, bear no less "responsibility"
than others (after all, the frontend is how the user experiences the product),
and I think most frontend developers would tell you there are plenty of
challenging problems to be solved there, rivaling anything else you'll find
elsewhere in the stack.

What sets the price of frontend dev expertise is the same thing that sets the
price of every other good and service in the known universe, barring weird
regulatory interference: supply and demand. The calculus for a hiring manager
is not "how can I pay X class of people less than others", it's "how can I
minimize the amount of $$ I have to pay while maximizing the value I obtain?"
In an individual case, it's "what's the least I can pay this particular
individual in order to get him/her to do what I want"?

------
2np
"I mean a large-ish block of real code from the actual domain the candidate
will be working in, which will likely offer a strong candidate many
opportunities for pointing out how badly it is written"

That might be a bad idea. Interviews work both ways, and you could scare away
the best candidates with bad code. Maybe it would be better to show them code
and say, "Here's an example of code that could be improved - how would you
improve it?"

------
arikrak
Google has a standard interview process for all software engineers and
afterwards you can end up either on in front-end development or back-end
development. So they at least think specific knowledge of front-end
development isn't necessary coming in.

~~~
swang
They now have a separate process for FE developers

~~~
arikrak
Well they still have a standard interview process for them, but maybe there's
also a separate one. I joined Google in Novmeber after their standard SE
interview process, and I primarily work in FE development (Angular).

------
maruhan2
I don't get the closure question. How are the two logs different?

~~~
gefh
The first call is to User.getCount() - 'this' refers to User, so the function
returns 1. The second call is to a bare function - or more exactly, a function
on the global scope - so 'this' refers to the global object, which is window
in a browser. So it returns undefined, as there is no window.count.

------
sirtastic
Explain the box model... What is this 2010?

