
Interviewing a front-end developer - lesterbuck
http://blog.sourcing.io/interview-questions
======
RyanZAG
I don't think this kind of questioning is useful. Does it really matter if the
dev knows all the strange intricacies of javascript, or does it matter if they
can actually put together a well engineered application? I can easily see a
more big-picture oriented dev who only uses the bare minimum javascript
features fail this test yet create very well engineered code. I can also
easily see a dev who likes to study manuals doing well on this test and then
making code so difficult to understand he can't even fix it himself.

~~~
erikpukinskis
That's my reaction too, but it's hard to know if OP is actually overzealous or
I'm just not good enough for them. This line stood out to me:

> it's important that anyone you hire has a comprehensive knowledge of apply
> and call

To other Javascript developers: is this really true? I do use call every now
and then, but it's pretty rare. Maybe that kind of stuff is more important if
you're trying to functionally isolate components with richer interfaces
between them? I tend to keep a pretty polluted namespace, so maybe that's
where I'm going wrong.

That said, I have a "I could learn that but I have stuff to ship" mindset
about Javascript. That has its ups and downs. Maybe I should work on that a
bit more.

~~~
timdown
I'm not convinced. I think not knowing that apply() and call() exist would
lead to unnecessarily clunky code, but even after over a decade of using them
occasionally I still sometimes have to look up which is which. My use of them
tends to end up deep in library code rather than everyday functions.

~~~
davedx
This is a crucial point. apply and call tend to be more useful for libraries
than application level code, in my experience.

Even in the "front end development" subfield of web development, there are
divisions. Do you want someone to produce lots of modular libraries that are
reusable throughout your company/application suite, or perhaps to build a UI
framework? Then knowledge of these parts of JavaScript will be very useful. Do
you want someone to build a rich internet application in Meteor? Then
knowledge of positioning, layouts, templates, UI effects and how to tie them
into the Meteor framework is much more valuable.

Where I work we do a lot of 2D animations, so it's great if the people who
work here know all about CSS transitions, requestAnimationFrame, and so on.

------
scarecrowbob
This is interesting.

These are things that I understand when pointed out to me, but off the top of
my head, with no google, I'd have to think for a second. They are things that
I implement most every day. For instance, the position fixed/absolute thing...
I work with things like that pretty much every day, but usually it takes me 10
minutes of fiddling, or 50 seconds of googling if I've had to do it before,
unless I get lucky and it just reveals itself as obvious.

Oh well, I suppose that's why I live in the sticks and freelance instead of
working for Twitter or Stripe :D I mean, this stuff seems esoteric to me, even
though I work with it every day... it's neat to know that there are a lot of
folks who have this stuff wired well enough to do it with no reference
material.

~~~
rymndhng
My thoughts the same. Frontend dev is too forgiving as an interactive
playground that I tend to iterate on the solution by getting some feedback
from feeling things out rather than straight up knowledge.

~~~
CmonDev
I would say HTML is too unintuitive.

~~~
nelmaven
I would say that the Box model is unintuitive.

------
taude
The problem with interview questions like this is that it looks for code-
monkeys. I'd maybe have questions like this if I were hiring an expert
consultant to crank out some short-term JavaScript for me, but for filling a
slot on the team....probably not....as there's really about 10 other things
I'm more interested in (assuming they have the necessary technical chops,
which I feel these questions don't really answer).

"At this point, if the candidate is doing really well, I'll ask them to
implement currying arguments."

Why? If they've already proven enough tech knowledge to do the job, why
continue to ask more questions that might/might not use to server your hiring
decision? (It sounds like you'd continue a different direction if they
couldn't implement with currying).

EDIT: I'd probably not be really hiring a short-term consultant like this
either, though, now that I think about it.

------
bulatb
This interview could go much faster if it didn't use a laptop _or_ a
whiteboard. A strong candidate should fire off responses to those questions
just as fast as you can ask them.

Spacify: "Split on empty, join with spaces." Done.

String.spacify: "Attach that function to String.prototype and call the
split/join on `this`." Done.

And so on. It does serve as a way to test if they can actually _write_ code,
but my guess is that there's not that big a difference between talking through
the code you'd write and actually writing it.

I'd be very comfortable with going through this verbally, but I'd be horrified
to get an interview like this where they expect me to type code and talk to
them while doing it. I'd honestly much rather have a whiteboard than a
laptop—at least I'm used to writing with a pen while someone judges me. The
laptop would just take away that comfort and make sure my brain turns off.

Am I alone in that?

~~~
erikpukinskis
The split on empty thing seems silly to me. It's a hack. If you weren't
familiar with the specific javascript implementation, you might expect split
to return ['hello world']. It's a nice hack, but it's a hack. It's something
you can do if you offhand know about that quirk of split.

~~~
bulatb
Alternatively: "Iterating through the string, take each character and dump it
plus a space to a temp string. Return the temp string trimmed."

I wouldn't say that's any worse, especially in this scenario. But they should
get it just as quickly.

Edit: trim the string. :)

~~~
jaredsohn
I would think an advantage to using split/join is that you aren't
concatenating a lot of immutable strings together (although if this only
happens one time and for a short string, it may not matter.)

Edit: Not tested myself. I had a suspicion about it and "confirmed" it via an
older post that is perhaps outdated now. Updated this comment to sound less
authoritative ("I would think").

~~~
parksy
Someone already set up a jsperf test for this an hour or so ago, so I added my
regex solution. [http://jsperf.com/spacify/2](http://jsperf.com/spacify/2)

On my machine, I was surprised to see that the for loop is the fastest (Chrome
+ Crunchbang).

I'd guess that this is probably because looping structures are heavily
optimized in modern JS engines.

~~~
bulatb
One thing I've learned from jsPerf is that this sort of micro-tuning tends to
be particularly fruitless in JavaScript. Even if a tweak increases speed
consistently across the target browsers, there's no telling which will
optimize what cases in the next few versions.

Basic things like caching DOM lookups are always good, but not so much the
little things.

~~~
parksy
Yup, I just ran the tests again and the results are completely different and
what difference there is is basically negligible.

------
yeukhon
_Ideally the candidate has a really full GitHub 'resume', and we can just go
back through their open source projects together. _

Note not everyone is a Github user. Some brilliant Python projects that I use
are still hosting on Bitbucket and/or Google code (and of course some on
sourcegeforge) so we should be careful with that. I will assume OP is making
an alias rather than excluding other service providers, though it is important
to keep that in mind (in particular, if you are implementing a form with a
field "github profile", please provide either a drop-down menu or a general
field with multiple textboxes)

Combining the rest, I can consider this almost a Javascript tutorial for
experienced programmer. Bravo on the neat, concise writing.

~~~
davedx
Of course.

Most programming interviews I've had over the years have asked for code
samples. Github is just the first thing people think of, but companies will
always in my experience ask for you to email them some code samples if you
don't have a Github account.

Although there's an argument to be made that owning a many-starred project or
contributing to a big OS project is also an indicator :)

~~~
taude
I've never once had a company ask for a code sample. What's the point in that?
Lazy lame candidates will just go copy something off the internet.

~~~
frankzinger
That is why people say 'get them to walk through their code'. Also, it's not
that easy to fake a project's complete git or other VCS history.

------
jaredsohn
I like how the article suggests letting applicants bring their own laptops
(and only using the interviewer's laptop as a fallback.) Many people don't
realize that is pretty hard to work on someone else's computer, especially in
a stressful situation. (Different installed software, software configuration,
keyboard, etc.)

~~~
invalidOrTaken
I had a remote interview this morning using etherpad, and I was surprised how
hard it was without emacs bindings. You'd think that because not everywhere
has them (like, say, this HN comment box) it would be easy, but apparently
when I'm typing code I really feel it. It really is the little things.

------
revelation
A lot of that stuff sounds like "my favorite list of code smells and anti-
patterns". Yes, it's cool you know these things about JavaScript, and now
please never use them.

------
jwarren
It's interesting that the new definition of a front-end developer is
increasingly JS first, HTML/CSS second.

~~~
jiggy2011
I guess HTML/CSS is something that can be done by a non programming designer,
so if your team is large enough to have separate back-end devs , front-end
devs and designers it's more important for the developer to be able to
manipulate CSS than design it from scratch.

------
club7g
I don't mean to be pedantic; well actually I do. The spacify solution is
incorrect as the sample suggests that a blank space is not replaced with 2
blank spaces.

A correct solution would be:

function spacify(input) { return input.replace(/([^ ])/g, '$1 '); }

~~~
himal
Actually, there are two spaces in the given example output as well.

Additionally, you could also use,

    
    
      function spacify(str) {
      return str.split('').join(' ').replace('  ','');
      }
    

to remove the additional space.

~~~
club7g
Yep 2 spaces was the intention, where as the original implementation yields 3
spaces. My codes failure is that it appends a blank space to the end... I
guess the real take away here is that there are many ways to achieve the same
outcome. Knowledge of quirks is not essential. I would think the most
important first step is understanding the requirements, what sort of
performance is acceptable given the intended usage, coding for maintainability
and ease of usage. For example, the solution for ensuring getCount has the
proper context requires knowing how getCount was implemented then taking extra
steps. A better solution may be something like this: var User = { count : 1 };
User.getCount = function() { return User.count; }

------
wooptoo
The greatest thing about this article is actually the link at the bottom:
[http://bonsaiden.github.io/JavaScript-
Garden/](http://bonsaiden.github.io/JavaScript-Garden/) Great resource.

------
CmonDev
Misleading title: it's actually just about interviewing JavaScript developers.

~~~
danceonfire
It's about interviewing Frontend _Web_ Developers. I don't think someone who
cannot write JavaScript can call himself a Frontend Web Developer.

~~~
retrogradeorbit
What about coffeescript, or clojurescript, or any of the hundreds of other
languages compiling to javascript and targeting the browser?

~~~
taude
If you don't know JavaScript, you're really handicapped using any form of
higher-level language wrapper. Coffeescript is syntax sugar. Run into problems
or library incompatibility with other components and you don't know
JavaScript...well...

BTW, for the record, I've never actually known a coffeescript dev who didn't
know JavaScript, too, though.

------
hising
My take on questions like these are that they most of the time focus on
putting the focus on some niched skillset of the interviewer and has very
little to do with real life problem solving. If a company hire based on how
well a person scores on some niched test, I guess they will end up with a lot
of internal nitpicking among the developer on who solves some obscure array
sorting algorithm the smartest way instead of focusing on getting shit out the
door.

~~~
garethadams
And any interview technique that involves "real world" problem solving is
criticised for being too contrived.

And any interview technique that involves the candidate actually working on
production code it criticised for being exploitative and effectively slavery.

------
flipstewart
Seems strange that the interviewer would be so pedantic while showcasing their
own lack of understanding... for example:

"How they choose to center content inside the overlay is also revealing. Some
of the candidates might choose to use CSS and absolute positioning, which is
possible if the content is a fixed width and height. Otherwise may choose to
use JavaScript for positioning."

First of all, JavaScript... just... no. Stop.

Secondly, hey, you don't need a fixed width or height, you just use:

    
    
      position: absolute;
      top: 50%;
      left: 50%;
      transform: translate(-50%, -50%);
    

I would really challenge the writer and anyone else interviewing for any
position to consider that maybe they don't know everything.

------
martin-adams
What's missing in the article for me is the ratio of candidates who scored
well. I've learnt that you can have some excellent developers who get excluded
which half a day of training when they start can bring them up to speed.

In my experience, interviewing is a costly process and being too particular
can simply mean you don't find the right candidate. Companies which have a
brand reputation that attracts talent can get away with this, but smaller more
unknown companies sadly can't.

------
michaelbuddy
I'm curious to assess if people separate front end designer / dev with front
end engineer.

I just don't know too many people with a rich design / artwork talent as well
as heavy javascript programmer mind. Maybe I just don't know enough people.

I suppose when you have a massive web app, you call your people front end
enginers because there are twenty of them and they don't have to create an
entire UI, they have been able to focus on specific issues and manipulating
the DOM.

------
wturner
I would have got number 2 wrong. I would have assumed that adding to the
prototype of String is hands down completely unacceptable bad practice.

~~~
davedx
You should say that.

"This is how I would do it, but I would strongly recommend against doing this
in a serious project of course because [reasons]"

------
wkdown
It seems as if the "github resume" is becoming more commonplace. I am married
with a 2yo son. I currently do not have time to contribute to open source
projects, and my company does not use git for versioning its codebase. Will
having an empty github account effect me adversely these days?

------
taude
Note: these questions aren't related to the article, but at sourcing.io who's
blog is writing content.

I'm trying to figure out how sourcing.io gets it's developers. As a techie,
there was no obvious way for me to put up a profile or anything. There's an
explanation that it uses the companies team's social networks, so maybe the
employees have to share all their specific account profiles with the company
(see below on more on this).

How does this differ from something like TalentBin that scrapes together
peoples various social profiles and aggregates them into a single
"report/summary"?

Also, do employees really give up their social graph to their employer? I keep
mine pretty tightly locked away. I've built it, maintained it. I might or
might not be with the company in six months (They might lay me off. I might
get a better job.) Occasionally, I've dug into mine to find someone when one
of those emails is sent around mentioning a hiring bonus for a certain
position. Or when I need to hire someone directly. But I still don't openly
share mine.

------
feulix
Lots of these comments are the reason I read HN. I love an educated
discussion, especially as a response to an article with breathes pretentions
like this one.

------
dave_sid
"proxies its string argument to console.log()" \- Think it's delegation rather
than proxy. A proxy would have the same interface as the target.

~~~
criswell
I understand all of these things when I use and see them, but when I have to
call them by name I'm screwed.

~~~
csixty4
It doesn't get easier. I was taught C++ in college without terms like
"encapsulation". It was just "hey, you can make one of the variables in your
object hold another object, isn't that cool?". Took me almost ten years to sit
down an learn modern OOP jargon, just in time for OOP to start falling out of
favor.

------
jiggy2011
You could probably skip most of these questions by asking "Did you read and
understand 'Javascript the good parts'?"

------
Thiz
The most important skill in a programmer is his search ability.

I don't know anything, but I know where everything is.

And I know how to search for it.

------
strictfp
>> My interviews are very practical

Cue list of the most obscure js tricks and gotchas the interviewer knows.

Nice one.

