
Interviewing as a Front-End Engineer in San Francisco - d_j_s
http://css-tricks.com/interviewing-front-end-engineer-san-francisco/
======
steven777400
We were hiring a non-senior full-stack developer recently and I noticed there
were no "frontend" questions on the list, so I added what I thought would be a
question that any developer with frontend experience could answer, and would
also pave the way for some more interested discussions for an advanced
candidate. The question was something to the effect of "In JavaScript, what is
the value of 'this' in a method?"

I would have accepted an answer as simple as "The value of 'this' depends on
how the method is called" or even "The value of 'this' confuses me because
it's often not what I expect."

It was a disaster. We may as well not have asked the question at all. Nobody
seemed to even be aware of anything about it.

~~~
wturner
I've been doing Javascript for a few years and recently answered a few
StackOverflow questions. One was regarding "this".If anyone wants to hire my
ass feel free to contact me. One of my techniques for learning has been by
going on interviews and flopping, then going back and learning all the
interview question material on my own time. Wash and repeat.I've been doing
this bullshit since the first day I started teaching myself. It all began with
an interview that required knowledge of strictly HTML & CSS. Suffice to say
after I tried to mimic an unordered list with 12 div blocks I didn't get the
gig. Things are better now. I promise! Where am I? Whats this padded wall
doing here? !!!!

~~~
steven777400
If you're looking, we are still hiring for a third position (we've been on a
bit of a binge lately with hiring).
[http://agency.governmentjobs.com/washington/default.cfm?acti...](http://agency.governmentjobs.com/washington/default.cfm?action=viewJob&jobID=775637)

~~~
wturner
Thanks. I'll fill it all out in the next 24 hours

------
Osiris
Are algorithm questions really that useful when looking for a candidate? I
find myself being really nervous about applying to other jobs because I'm not
formally trained in CS.

My job and side projects are mostly web sites that require knowledge about how
to architecture software but I very rarely write complex algorithms.

If something comes up where I need to optimize something I can usually spend
some time Googling for some insights on how to improve it, but it's been 15+
years since I've written a sort algo. The idea of being forced to come up to a
solution to an unknown problem on the spot makes me feel inadequate.

~~~
millerm
I'm a full stack developer. Currently focusing on iOS. Interview questions
should really depend on the expectations of the type of software being
developed.

I've been to a couple interviews lately and this has been the first time (in
my career) that I have been tested (with time constraints too, mind you). I
was either pointed to a whiteboard, or sat in a room with nothing but a couple
sheets of blank (unruled) paper, a non-erasable pen, and a list of ~10
algorithms questions with a few to be implemented and their running time, and
memory footprint to be explained.

I was not prepared, at all.

I have been developing software for about 17 years. Do you have any idea how
many times in my career I have been asked to write a heap sort, a trie, or
create a power set? Never. So, I had forgotten some of the specifics of how to
implement them. Let alone on paper. A quick note... My handwriting is
atrocious. I'm 41 and I am extremely embarrassed as to how bad it is. I can
play classical guitar, but I screw up everything I write or attempt to draw. I
thought it was a dyslexia thing or something, but I don't seem to have enough
of the symptoms for that. That's pretty much why I liked using a computer when
I was younger; I could fix my mistakes. So, needless to say, when I am asked
to write stuff down I kind of freak out.

Anyway, there is a reason I have reference materials and the Internet. If I
don't remember the specifics of something, I go look it up. I know what a lot
of data structures and algorithms are, but I just don't bother memorizing all
their specifics. I know what to look for. I read the description and can
decide what the best thing to do is. Sure, I remember the basics of the major
algorithms and data structures, and some of their their Big O characteristics.
Implementing these isn't really what I do on just about any given day.

So, what have I been doing about it? I've been spending the last couple weeks
going back over the "Algorithms" book
([http://algs4.cs.princeton.edu/home/](http://algs4.cs.princeton.edu/home/))
and grabbed all the videos from the Coursera courses on the same book/topic.

I admit it's all my fault. I have written a lot of very successful
applications over my career. These have fulfilled requirements for power
generation, real estate, healthcare, search engine, and marketing companies.
Using higher level abstractions (like using an OO language) with industry
tested APIs for sorting, lists, trees etc.. kind of makes you push that stuff
to the side because for 95% of the development, that kind of low level detail
is just not necessary.

Now, of course, this really depends also on what type of development you do.
Sure, if you are writing a lot of C code, you may need to manually write these
structures. Or, if you are writing low level code (game event loops, collision
detection, file system stuff, you know) that needs to run as optimally as
possible, sure. A lot of us write applications that take in data, and spew it
back out. Heck, a lot of developers are forced to write just a hell of a lot
of SQL queries and they'll never see a data structure beyond a class file, an
array list, and a result set.

Again, I am attempting to better myself now. I don't know how long it will be
before I can answer some of the more crazy questions I have been asked though.

TL;DR I was not prepared, at all.

~~~
tgflynn
It's not "all your fault".

The problem is that there is a belief in the industry that 15-30 minutes of
technical interviewing tells more about a candidate than that person's entire
career history. I have seen no actual data to support this belief.

I think someone who has a history of having built successful applications is
far more likely to be qualified than someone who happens to have a good memory
for algorithmic solutions and performs well under the stress of an interview
situation.

This interviewing approach may make sense for entry level candidates who have
nothing more to show than what they have learned in their CS classes but
applying it to an experienced professional is simply brain-dead.

~~~
millerm
One of my favorite quotes:

"Never memorize something that you can look up."

\--Albert Einstein

~~~
lightblade
Then again, you probably should memorize it after looking it up for the 10th
time.

~~~
millerm
Statistically speaking, I haven't had to look them up that many times. I've a
high percentage of the JDK memorized though, and a pretty good portion of the
CocoaTouch and Objective-C Foundation framework. :-)

------
hawkharris
One problem is that many people associate front-end development mainly with
HTML and CSS. HTML and CSS are not programming languages.

I say this a front-end developer who has to write HTML, CSS and JavaScript on
a daily basis. Yes, strictly speaking, HTML and CSS may be considered
programming languages, but they lack control structures, design patterns and
other interesting tenants of computer science. Like the author, I'm much more
drawn toward the CS-related tasks of the job such as writing JavaScript.

To be clear, I have an enormous amount of respect for people who enjoy the
design aspects. Writing CSS, using Photoshop, etc., requires a lot of skill.
My point is simply that there is a divide among those front-end developers who
are drawn toward programming and those who are drawn toward layout and design.

As more sites gravitate toward complex JavaScript-driven web apps, it may be
useful to ditch the general term "front-end," differentiating C.S.-oriented
front-end developers from those who prefer visual design.

This might make the expectations of a front-end development position much
clearer, allowing for a simpler interview process.

~~~
philipwalton
Post author here. I agree 100% that HTML and CSS are not programming
languages. However, any application that you build on the front-end is going
to require your JavaScript code to interact with the HTML and CSS, so a solid
understanding of how all the pieces fit together is crucial.

I can't tell you how many times I've seen back-end engineers hack together a
100+ line JavaScript solution to a problem when one line of CSS would have
fixed it.

If you don't know CSS, HTML and DOM very well, then you're probably going to
be over-engineering your front-end apps.

~~~
kika
Any book recommendation? I can say I know JS as a language sufficiently well
(I can write basically anything on Node), but I almost completely lack a
systematic understanding how the HTML+CSS and DOM work together (layout
engine, rendering, etc). I have some basic knowledge here and there, but
reading "We need to make outside div relative to be able to use absolute on
the inner one" leaves me staring out of the window.

------
mgkimsal
"I'd rather hire a smart person and teach them X then hire someone who knows
everything about X but lacks creativity, logic, and reasoning."

False dichotomy. How about a smart person who knows a lot about X and is
creative and logical? They do exist.

I feel like many interviewers want to categorize someone in to one of those
two categories from the outset - "this person already knows a lot about XYZ,
therefore, I'd rather look for a smart person who doesn't know XYZ and teach
them". Sounds crazy writing it out, but it's the impression I got years ago
interviewing. It's also the impression I get from friends of mine who have
interviewed in the more recent few months.

~~~
rhc2104
It's more like, "we want smart people, so let's optimize our interview process
to find smart people, and give everyone the same interview questions."

The problem here is that firms tend to prefer giving "engineering interview
problems" to everyone, and do not want to segment interview questions by
position.

~~~
kyrra
Because that takes a lot more time for the interviewers. For a growing tech
company, they could have as many open reqs as they have engineers. Crafting
questions for all of those positions takes a lot of time that most companies
don't have time to do.

~~~
justinsteele
Hiring is pretty much the most important thing you do as a company.. if you
can't spend an hour per position developing applicable questions for each
position, you are setting yourself up for failure.

~~~
rhizome
Yet, time and time again, these posts come up and the comments contain a not-
insignificant of anecdotes about hiring processes that resulted in high
failure rates in interviews, so they hire someone kinda smart anyway and teach
them the concepts that other interviewers failed to answer satisfactorily in
the interviews. Why ask at all, then?

------
philipwalton
Related, I just found out that Darcy Clarke put this list together of good
front-end interview questions. I would have included it in the article if I'd
known about it ahead of time.

[https://github.com/darcyclarke/Front-end-Developer-
Interview...](https://github.com/darcyclarke/Front-end-Developer-Interview-
Questions)

~~~
krsunny
"Whats your favorite feature of internet explorer"

I think I see what she did there..

~~~
whileonebegin
The ability to emulate different versions of IE. Of course, the only reason
this is necessary is because of the many breaking changes that the different
versions created.

------
edw519
_I 'd rather hire a smart person and teach them X then hire someone who knows
everything about X but lacks creativity, logic, and reasoning._

This!

That one sentence pretty much addressed all of your questions and concerns. So
instead on hacking the apparent process, read that sentence again and _get
it_. This is pretty much an absolute truth in almost any industry for almost
any skill. It's especially true in tech because:

    
    
      - "X" will be different in 2 years anyway.
      - "X" will be VERY different in 4 years.
      - Well funded companies want long-term talent.
      - Start-ups seeking their place want long-term talent.
      - Companies with long-term vision want long-term talent.
      - A jack of all trades is usually better than a master of one.
      - If it's so complicated to learn, it's too complicated to use.

~~~
rondon
I've done very little HTML,CSS but I feel confident that I could become
proficient as a front-end dev. But it is going to take months. I assume you
are saying that these companies are hiring based on expected performance at 1+
years. They don't expect the person who gets the job to be making major front
end code changes the first month?

------
wanderr
Note: I work for Grooveshark, which is in Gainesville, FL, about as far away
from San Francisco as you can be in the continental US...so what I'm about to
talk about might not be like what is going on over there at all.

When we bring someone in for an interview, we generally already have a pretty
good idea of their technical skill level. Part of the filtering process is
asking to see their work, either code samples or a portfolio. For frontend
engineers it is especially easy to see their work since you can load it up in
the browser, inspect, interact with the console, etc.

If we are impressed by their work, the interview is 90% making sure they are a
good personality fit, 10% making sure the work we looked at was actually
theirs. We probably end up asking slightly more frontend-specific questions
than the author experienced, but probably not much.

We find that this process generally works quite well, but a few people that we
gave offers to did tell us they were surprised because they felt they had
bombed the interview, assuming that since we didn't get into a lot of nitty
gritty technical stuff or ask them to write code on a whiteboard, that we had
already decided we weren't going to hire them.

------
potench
A coworker and I wrote a script that's been through a few iterations based on
feedback and tailored to whatever company I'm hiring for. Based on the
participants self-rating (1-10) you can ask increasingly more nuanced
questions in each area of CSS, HTML, and JS. Here's the front-end interview
script I use:
[https://gist.github.com/potench/e71e09c882628054c119](https://gist.github.com/potench/e71e09c882628054c119)
So far it seems to do a good job at promoting conversation and identifying
thoughtful and talented FE developers.

~~~
nairteashop
This is a good list. Can I ask you something though? I've always been curious
about the value of questions like these (just to take a sample):

> On a scale of 1-10, what is your comfort level developing with HTML, CSS &
> JavaScript?

> How well do you think you work with other fellow developers?

> Given a choice, would you rather work alone or in tandem with someone?

What are the "correct" answers to these? Or more specifically, in your opinion
what are the "wrong" answers?

On the first, the problem I see is one of self-reporting. We have seen
developers self-report a 9 on something, only for us to determine later based
on the interview that they were more like a 5. We didn't put value on either
of these numbers, because both were relative - the "9" was presumably relative
to his previous job environment, and the "5" was relative to ours. (At another
company the person could've been a "2", for example.) Fact is, it doesn't
really matter - we were just looking to see if the person can add value,
regardless of whether they were a 5 or a 10.

On the latter two: we have had "loners" crank out incredible bits of code on
their own, and "team people" do the same as part of a larger group. We have
also seen people switch between the two "personality types" based on context -
the specific project, their team mates for the project, and so on.

So we prefer not to ask these types of questions as we don't seem to get any
relevant information out of them, but perhaps we're missing something, and so
I'm curious as to what your motivations are.

------
ktavera
As a follow-up to my earlier comment, i'm doing a phone interview right now
and the first interviewer started off with questions about how IIS internals
worked and some obscure C# questions. I immediately asked him "Is this a
front-end position or not? I know C# and .net MVC but i'm focusing my career
on Angular" his reply "I honestly don't know, they just told me to call you
and ask you a series of questions on advanced C# development" Job posting
title "Senior Frontend Developer with AngularJS"

~~~
_random_
It seems that JS MVC frameworks change every year, maybe they decided that
asking questions on the flavour-of-the-month is not an indicator? Would expect
some JS questions though.

~~~
ktavera
As a bonus, finally got to talk to the hiring manager a second ago and he
informed me that there would be NO javascript or front end development in this
role, just converting Crystal Reports into some other obscure reporting
system. So I ended the call promptly with a "Thank you for your time and good
bye"

------
ktavera
I've had similar experiences in the last month of interviews i've been
through. I was asked how i'd design a secure backend API in asp.net, various
algorithm questions, some basic javascript questions ("what is a closure?",
"what does the var keyword do?", etc") and other very non-specific things. At
the end of most of my interviews when they ask if I have any questions about
the positions I tend to have to ask "Is this a Front end Developer position
you just interviewed me for?" Not once have any of the interviewers been
front-end devs, only SVP of Development or Director of Design or some other
inflated title. I want to talk about problems i've had building Angular or
Knockout apps or or cross-browser JS/CSS issues.

~~~
walshemj
Interesting so I hope you said get ready to spend a fuckload of cash on state
of the art secure key stores as this is the only way to properly build a
secure back end.

------
ckorhonen
This seems fairly typical, and I understand the rationale on both sides.

In any kind of engineering role, not just front-end, having domain
experience/expertise certainly helps you be more productive from the get go.
In a previous company we hired developers with good CS chops but no iOS
experience to build our iPhone app - they picked it up, but it took a couple
of years and numerous rewrites to get an awesome product. Thats a huge
opportunity cost. You'll end up with a better product right off the bat if you
hire an expert, especially with technologies which have a ton of quirks and
nuances.

So why wouldn't you want to hire a front-end expert? In a lot of smaller
companies flexibility can trump expertise - having an engineer who is smart
and can work across the entire stack is essential in smaller teams. That
doesn't mean they won't be primarily doing front-end development, but its
helpful if they know their way around the back-end to some extent without
hand-holding from other engineers. A good candidate needs to be smart enough
to quickly pickup new tools and techniques, and it is important to determine
this in the interview process.

~~~
mackey
I was just thinking about the similarities in iOS development. I have worked
on a project where the original authors weren't iOS developers but were very
competent front end developers, and it wasn't pretty. It doesn't just affect
the code, but also things like the build environment and documenation.

------
meritt
You were interviewed by back-end engineers. That's what they knew.

My question is why didn't you leave the interview upon seeing it was a waste
of time?

~~~
philipwalton
To be honest, I was actually having a good time. I'm one of the crazy people
who likes interviewing. I think it's kind of thrilling.

Also, they flew me up there, so what was I gonna do?

------
mikeya
You'd hope that before they bring you in they know that you know basic front
end stuff. To be honest most front end tech is simply memorization of
standards and idiosyncrasies between browsers. Anyone can go through and
figure this stuff out via a simple google search. On the other hand taking say
data from a Ajax call and sorting it or filtering it with custom logic takes
some creative problem solving to do it gracefully.

Interviewees always forget to figure out why they interviewer and company is
asking these questions or requiring particular knowledge. Next time just ask
them!

------
nhangen
I'm a PHP/WordPress dev shipping product every single day, but I think I'd
probably fail questions like these if I was asked in an interview setting.

I don't really worry about functions like these until a need arises, and when
it does (and I don't know how to do it), I learn until I do.

This is an absurd way to recruit front-end talent and partially explains the
so-called talent crunch.

~~~
hackinsack
Nothing against you, as I don't know you or your work, but "shipping product"
does not equal doing good work. People ship crappy, buggy code every day. Just
because one "ships daily" doesn't mean that what they're shipping is worth
anything or means they know what they're doing. I've seen people that have no
clue how to write code copy and paste crap they find all over the internet
into a file and ship it. It's a slow, buggy and ugly hack, but it shipped. It
will come back days later as unexceptably bad by the customer. That's the
purpose of these tests. To weed out the people that have no clue how to write
proper software that deals with high loads, scalability and performance
criticality.

~~~
sigsergv
Software engineers make product, not code. I'd prefer talented developer with
good practical experience in “releasing products” rather than an algo-geek who
can only solve stupid hiring quizes.

Slow buggy ugly WORKING RELEASED product is a much-much better than ideal
clean and effective thing not yet ready for release for a few years in row.

~~~
hackinsack
Not saying I disagree with that, except for releasing slow buggy code. Why not
accept either of those people? There are efficient ways, as described in the
article, to interview for people that are great at releasing quality code in a
productive time frame. I was simply pointing out that releasing code daily
doesn't mean you know what you're doing. If you can't answer at least some of
the questions that were in this article, I'd question your ability to write
productive code. That's not to say that only questions like that should be a
determining factor for ones ability to produce.

~~~
nhangen
You're right that shipping !== good code, but I wouldn't be able to keep
shipping the same product if it weren't somewhat valuable to my customers.

The point isn't that I'm a unicorn, but that good developers can exist outside
of code challenges.

People like me, that are self-taught and work super hard in order to improve
our craft...we're not appreciated enough.

Everyone wants a rockstar, forgetting that drummers and bass players add a lot
of value.

------
ritchiea
I had a similar experience with a well known bay area company. I was
interviewing for a front end job and they gave me a live coding interview with
a recursion question about assembling trees from strings (or maybe vice
versa).

I had spent the majority of my time preparing for the interview preparing for
front end stuff. I stuffed my brain with Javascript quirks and made sure that
the stuff I already knew I could articulate really well. And I gave myself a
quirk algorithms review because I knew that is something the Bay Area values.

I struggled with the first question. They asked me if I was interested in a
non-dev job because apparently they liked my personality and thought I may be
a good cultural fit. It struck me as odd that they liked me enough to inquire
if I'm interested in other positions, but only gave me one chance to show them
I could be a frontend candidate and the sole interview question wasn't even
frontend oriented.

------
codingdave
It could have been a sign that they trusted your front-end skill. If I know
someone has a skill, I don't waste my time interviewing them to prove it. I
try to figure out what else they can do, where they can grow, and how well
they would fit in with the team.

So I'd pose the question back to you -- did you provide them a portfolio or
any code samples that would have made the front-end questions redundant?

~~~
philipwalton
Yes, I provided a detailed resume as well as my Github account for all of
these. The problem is it didn't seem like the individual interviewers had
taken much time to actually look at what I'd done.

If they had, then maybe I'd agree with you, but it seemed like many of them
were just going through the motions. It seemed like they interview people all
the time.

~~~
majormajor
"It seemed like they interview people all the time."

I bet you hit the nail on the head.

At my current job, I've had weeks where I've been on an interview loop every
day. At that point, I'm not going to spend much time looking at your github
code in depth beforehand each day. Especially when it's a candidate whose area
of expertise isn't the same as mine, so I wouldn't know what to look for.
Ideally we'd be better able to match interviewers with interviewees, but if we
had enough people to be doing that, we wouldn't be in the mad hiring rush that
ends up with a developer doing five interviews in a single week around career-
fair season. ;)

(My last job was a much smaller company where each hire was weighed a lot
more, and we absolutely would've looked at all that stuff there.)

However, I always start off asking about a specific project from the
candidate's resume, usually the one that I think sounds most interesting to
me. Depending on how long they take to explain it, or how interested they seem
to be in explaining it, I'll follow up with a more open-ended question of what
their most interesting or challenging project was -- if you can sell me on
that project, it's just as big an influence on me me as the coding or design
question that I'd also ask.

But I have coworkers who don't ask about other projects like that, which I
think kinda sucks.

------
vikas5678
I have friends who have politely refused to answer or indulge the interviewer
in the algorithm questions labyrinth. As someone being interviewed, you should
atleast try to divert the interview toward your strengths. On the flip-side,
if a company is interviewing you for a front-end position and not asking
enough DOM, CSS questions, they're doing it wrong.

------
joeblau
Great writeup. This is pretty much the same experience that I had when I moved
to San Francisco. I got a lot of "college memorization" questions. Basically,
you could read a book, memorize the answer and come up with it. I was also
interviewed by some young guys out of Stanford who asked me a question that
they probably spent a few weeks in class working on that I had 45 minutes to
figure out. When I look at the interview process, it seems more like a battle
than an actual interview, but it is engineers we are dealing with.

When I do interviews, I want to know that you can program, but I care more
about whether or not I can work with you.

------
bjryan
I am honestly a little shocked by this. I am a university student and this
past semester I interviewed with around 10 companies in the Bay area, all of
which were for Front-End engineering positions. I can only think of one
company which did not give me any 'front end specific' questions. I was asked
everything from hoisting and closures to explaining how Webkit works and
various ways to improve page load time. Are you free to elaborate on what
companies you spoke with?

~~~
philipwalton
Maybe offline. I'm not interested in publicly calling out any companies. I
mainly wanted to shed light on the process and my experience.

I will say that when interviewing for previous jobs in the past (at smaller
companies), I got asked a lot more front-end questions. Maybe it's just a big
company problem.

~~~
auctiontheory
It's true on the business side as well. Small companies ask relevant questions
because they have to - their survival depends on finding someone who can _do
the job_.

Big companies, even famous ones, have moved so far beyond their scrappy "gotta
survive" days that they have become quite lost in their bureaucracy and
arrogance.

------
drhayes9
I do lots of front-end work and have tended to do front-end phonescreens for
the past few years. I'm a huge fan of Steve Yegge's five essential phone
screen questions: [https://sites.google.com/site/steveyegge2/five-essential-
pho...](https://sites.google.com/site/steveyegge2/five-essential-phone-screen-
questions)

Good breadth, no one gets bounced for not knowing a couple of the answers,
great way to get a larger picture of what the candidate knows (or doesn't!).

Designers-turned-JSers tend not to do so well on data structures and bits and
bytes.

After the five questions, I move to HTML/CSS questions: inline vs. block, what
does float really do, the display property, valid values for display besides
"none", visibility: hidden vs display: none, position, absolute vs. relative
(with relative offset parent questions thrown in).

For the JS portion, I ask scoping, closures, global object, the values of
"this" based on calling context.

I like front-end engineers who are also, y'know, _engineers_. I like working
with people who I can say "that distributed system has performance
characteristics akin to a hashtable" and they know what I mean.

------
mikeleeorg
As a former front-end engineering manager that has screened, interviewed, and
hired tons of developers for large corps and small startups, I hear this guy's
frustration and have felt it myself. I've often stepped into interviews for
other departments and teams that had no FE developers to give them a hand.

At the same time, I've come across far too many developers who assume "front-
end" only meant HTML, CSS, and jQuery.

NOTE: Not JavaScript, but jQuery, which are very, VERY different things. The
author does himself a disservice by citing a jQuery example instead of a
general JavaScript one. I get how prevalent jQuery is, but if you can't
describe some of the inner workings of JS to me, then I may weed you out.
That's just my preference though; other hiring managers differ.

In my particular cases, we needed FEs that knew JavaScript and server-side
scripting languages - to the extent of being able to write some presentation-
layer logic if necessary.

So whenever I've coached technical hiring managers who have no experience with
front-end development, I'd tell them to go right ahead and ask questions on
general programming logic. Even if the candidate's verbal answer is incorrect,
the thought process behind trying to answer it can be helpful.

FYI, the type of phone screen questions I would ask are:

\+ Why is a doctype significant? (HTML)

\+ What is the box model? (CSS)

\+ Describe the event model. (JavaScript)

(You'd be surprised at how many purported front-end engineers get these
wrong.)

These were accompanied by general programming logic questions. They all
designed to assess the developer's ability to communicate and explain, and not
the developer's technical skill. For that, I looked at code samples and the
results of a take-home code exercise. And the specificity and difficulty of
the questions would depend on the stage of the interview and level of
candidate's experience. The "What is the value of 'this' in a method?"
question is a great one too.

~~~
thekingshorses
This guy hired me based on my FE skills even though I didn't had any
development experience. It was my first job as a FE engineer.

I won't be able to get a job based on algorithm/standard CS interview
questions.

------
fistofjohnwayne
I think these problems stem from the job posting. Like the author, I've come
to love interviewing and I've conducted a good deal of interviews myself. I've
noticed that a job titled "front-end developer" with a poor description casts
too wide a net and wastes everyone's time.

If I see that you mentioned design experience and Backbone in your job posting
and then you quiz me on Rails and database queries I'm going to feel like I'm
attending amateur hour.

However, if you state that data structures, algorithms and all that other
great CS stuff is fair game in the job posting or the follow-up emails – then
go ahead.

Don't envy the front-end developer. At this point we have to be prepared for
anything.

------
_greim_
I believe the mindset behind this behavior is A) they take it for granted that
you're proficient in your stated area of expertise, B) they're not necessarily
proficient in your area of expertise, so wouldn't be able to assess your
skills anyway, C) algorithm knowledge is hard to fake, so your false positive
rate for hardcore engineers will be low, even if your false negative rate will
be ridiculously high.

Google's publicly available prep material reinforces this third point, even if
they don't say it explicitly. They recommend books, point you toward places
where you can learn the concepts, and tell you if you fail once, try again in
a few months.

------
usingpond
Similar in NYC. I remember an interview where I was asked to bit-shift in
Javascript, for the sake of itself.

I've also had good experiences though--I liked one where I had to build
certain UI components and get my code evaluated in real-time.

~~~
lgieron
Since it's just *2 (right shift) or /2 (left shift), I'm pretty sure they
wanted to quickly test how are you with general programming knowledge.

~~~
nanidin
In javascript, the number type is just number. To truly bit shift with this
method, you'd need to convert the bitwise representation into a number,
perform the given operation, handle the corner case of odd numbers when
dividing, and the convert it back into some representation of bits.

Trying to judge people with questions like this seems like a misguided
endeavor. Yes, it's probably valuable to know that bitshifting is roughly
equivalent to *2 and /2\. But that's more like trivia - the chances you'll
actually use that in real life is really low. I've had to work with people
that think bitshifting is an appropriate optimization for
division/multiplication by even numbers. I then have to explain overflows,
underflows, and the fact that the compiler will compile it to shifts if
appropriate anyway, so don't sacrifice readability in the name of micro-
optimization.

------
seivan
I'm sorry you had to go through that bullshit.

That generally sucks when you're interviewed by assholes who have no idea that
the specific platform that you might work on requires.

Consider most front-end engineers ALSO to be designers, and I'd suspect thats
where I would drive the interview. I would wish the same treatment.

Also lol that the interview questions are basically EITHER memorizing formulas
and remembering why something was that way or trying to cram down a solution
on the whiteboard in the little time you have.

The latter is more admirable, but depends on the situation at hand. 5 minutes,
white board, using your fingers as eraser.

~~~
Bahamut
I think we are also seeing the rise of the frontend developer, where they
spend most of their time on JS, with maybe some time in HTML and CSS - at
least, that is what I do for work, although I am fully capable of excelling at
CSS as well.

~~~
greghinch
My career as a developer has been coming up through the role of front-end
engineer, really from when that was first being defined as a separate role
(2004-2005, around then). In hindsight now, I would never hire myself. Either
you're a developer, in which case you should be able to traverse that stack
(so for example JS as well as PHP/Ruby/Python) or you're a designer, and you
can traverse that stack (so you design, implement your designs in HTML/CSS,
maybe a little JS as necessary). But while there is crossover between the two
domains, there isn't a separate role in the middle. Trying to fit development
workflow around people who just do HTML/CSS/JS ends up creating too many
bottlenecks, on both sides: "I'm waiting for designer A to deliver X" or "I'm
waiting for back-end person B to deliver Y". When you just have people who
work their whole stack, that bottleneck is removed.

~~~
Bahamut
It gets necessary at some point - it's not cheap finding highly skilled full
stack developers, and they're not the most common beasts around. Everyone
wants them, but they have their pick of jobs. It's far easier to hire for the
positions separately, and if your company is in need of rapid expansion, I'd
say almost necessary given the market.

While I term myself as more of a frontend developer currently, I also know CSS
pretty well (I sometimes fix bugs the UI team can't figure out), and I am
currently transitioning to doing some backend work at my current job as well.

All developers should strive to be full stack, and designers should strive to
know code more, but realistically speaking, not everyone is there yet of
course, so you have to focus on developing the talent or hiring it.

------
sbilstein
I was full stack at my old job, so I do phone screens for front end engineers
now. It's incredible how many people claim "front end" and fail at basic JS,
HTML api, or page optimization questions yet do well at algo questions. I am
far from an CSS expert but if we didn't ask questions like "how would you
optimize the static content of the page?" I'm sure we would end up hiring OK
general devs who actually don't know anything about front end.

------
davedx
I interviewed for a long-term "Frontend engineer" role in June for a large
cable company here in the Netherlands. I've been a full-stack developer for
the past 3 years or so, and before that I was in game development, and before
that still, I wrote enterprise middleware.

My frontend experience going into this interview was almost entirely jQuery,
with the exception of one 2 month freelance project where I had a crash course
in AngularJS.

I was asked a ton of technical frontend questions, and I was able to answer
them at a conceptual level but not from experience. I got the job, and I think
what was important was my broader experience as a programmer, not the answers
to specific frontend questions.

The thing is, real frontend programming of large JavaScript applications is a
brand new field. There are lots of people with lots of jQuery experience (it's
telling that this article deals with jQuery as an example of frontend
development), but not so many with serious JavaScript programming experience
outside of a library or framework.

I think because of this, companies are just being realistic when they
interview for frontend positions based on general programming knowledge and
experience. Maybe in 5 years they will drill down more, as the pool of expert
frontenders expands.

------
mcintyre1994
I know it's a bit off-topic, but I'm a student so anything about interviews
interests me a lot. For the Bacon Number question, I'm struggling a bit to get
my head around a good way to do it.

My immediate idea is to derive a graph where nodes are actors and an edge
between 2 actors means they've been in 1 or more films together. I believe the
shortest path between them and Bacon could then be found by breadth-first
search.

It looks like that graph would be quite slow to derive though - my naive
pseudocode being something like:

    
    
        for bucket in hashtable:
            for actor in bucket:
                if actor not in graph, add a node for actor
                for other_actor in bucket (up to actor):
                   add an edge between other_actor and actor
    

That looks pretty slow without deriving a running time, so I'm guessing
there's some optimisation that can be made from the current structure of the
hashtable. Could anybody give me a pointer in the right direction please?

~~~
yetanotherphd
It is the final inner loop that is problematic.

Instead, your graph should comprise movies _and_ actors as vertices (edge =
actor was in a given movie), and to get the Bacon number you just halve the
distance in this graph.

So you code would look like

    
    
        for bucket in hashtable:
            add node for bucket
            for actor in bucket:
                if actor not in graph, add a node for actor
                add an edge between actor and bucket
                add an edge between bucket and actor
    

If each movie contains exactly K actors, and there are N movies, then your
graph has O(NK^2) edges while mine has O(NK) edges.

~~~
mcintyre1994
Ah that's awesome, really smart optimisation, thanks. I hadn't really thought
of the possibility of having the two different features in the same graph but
that's definitely better!

------
mVChr
I have been a front-end engineer for over a decade, and if I were hiring for a
position a decade ago I would understand and agree with your points. However,
with the breadth and depth of skills required for great front-end engineering
today, I would feel very uncomfortable hiring someone who only had the arcane
skills required to "get the job done" on the front-end. If hiring for a
smaller company, I would be concerned about this person's ability to
contribute to more than just the tasks in their silo. If hiring for a larger
company, I would be concerned about this person's potential for future growth.
Also, it's usually apparent from projects or employment history that someone
can do what's required on the surface for front-end work, so why would I waste
interview time going over details and minutiae in that area? I'd rather take
the opportunity to find out if they're a solid engineer as well.

------
bredren
My understanding is that this is type of 'shallow' technical interview in SF
with notable companies is not limited to front-end.

A good friend recently interviewed at multiple well known and respected
internet companies for an Android position. This guy is perhaps a global
authority on Android. Technical questions were of the computer science type,
and did little to illustrate the substance of value the companies were
actually trying to hire for.

Rather than take the time to understand whether he really, really knew
Android, they wanted to see if he could traverse nodes in a tree. Two
companies even asked the exact same non-Android specific question.

------
sergiotapia
Concerning that they ask you computer science questions when you will be
working on the front end.

What if you were to ask CSS and Javascript questions to a DBA? Do you see how
absolutely ridiculous that sounds?

~~~
Jgrubb
More ridiculous than asking CS questions of a front end dev. I'm a self-taught
front-end dev who has flunked numerous interviews because of a lack of CS
degree and being able to get through the sorting algorithm questions. I then
went home and have spent lots and lots of time teaching myself those
fundamentals, if only to interview better. Those fundamentals have made me a
vastly better front end dev, able to efficiently solve problems I wouldn't
have been able to solve a year ago.

I have had the exact same experience with the author of the article regarding
a total absence of actual front-end related questions, though. Not sure how to
feel about not getting those gigs.

~~~
krsunny
Can you give some examples of which algorithm have been the most
relevant/helpful?

~~~
sergiotapia
His silence is highly amusing to me. :)

~~~
Jgrubb
Your condescension is highly distasteful to me.

~~~
krsunny
Who was he talking about? Me? If so, I upvoted the reply, what more do I need
to do?

------
badman_ting
I interviewed at a well-known place here in Portland and they seemed really
disappointed that I didn't already know Rails. That was surprising to me,
since like the author, I am more familiar with the mindset that you prefer
smart people rather than people who know technology X. Beforehand I spent all
this time reviewing data structures, algorithms, etc, but they just cared
about Rails. I also got one of those goofy OO-design questions about Human
inherits from Animal. Not at all what I was expecting.

~~~
_random_
Times when Rails development was considered an out-of-box thinking have
clearly passed...

~~~
badman_ting
Yep, just another orthodoxy now, for some.

------
char
Just wanted to share that I had a very similar experience interviewing as a
front-end engineer last year, and had made many of the same assessments about
the process as you have.

It is interesting that the company I ended up at-- while they did ask some
standard algorithm and 'how do you think' type questions-- there were also
many questions probing my front-end skills, including some quick JS coding
problems. The interview just felt SO different than anything else.

Thanks for posting this!

------
necolas
Hey. I work at Twitter. I think that at certain companies the "front-end" role
is not as specialized as assumed, and you tend to interview for a specific
team that has an opening, rather than for a generic position among a hoard of
similar developers.

Having said that, I'm surprised there was only one CSS question, and the
suggestion to combine questions with front-end specific knowledge might be a
good way to ease into the interview.

------
camus2
A bit off topic,but is there a website that gather common computer science
interview questions with solutions ? thanks.

~~~
millerm
I saw this on Reddit yesterday.

[http://www.grokit.ca/spc/computer_science_review/](http://www.grokit.ca/spc/computer_science_review/)

So, perhaps this can get you started.

I plan on getting a copy of: [http://www.amazon.com/Cracking-Coding-Interview-
Programming-...](http://www.amazon.com/Cracking-Coding-Interview-Programming-
Questions/dp/098478280X) too.

------
ra3
>"A correct answer to this will demonstrate both an understanding of basic
computer science principles as well as a deeper knowledge of what jQuery is
doing behind the scenes."

How does the referenced jquery statement represent basic CS principles? OOP?
Definitely not that.

~~~
whatevsmate
The referenced jQuery statement gives the candidate a chance to speak on:
selector complexity (id look ups vs traversing to find descendant elements),
first-class functions (passing a function reference to the .on() method),
regular expressions (to add class names to an existing class attribute in
older browsers that don't have .classList property on elements). There are
probably other things but those are just a few off the top of my head.

------
proksoup
The two CSS questions I ask (but skip depending portfolio quality):

1) Make these two discs sit next to eCh other. What other ways you could do
that? Why each way bad/good for what?

2) center this. Other ways? Bad/good about each?

------
NDizzle
SF Tech Interviews. By recent college grads FOR recent college grads.

------
cleverbaker
Those are excellent suggestions in the "My Suggestions" section. Thanks for
the article.

------
michaelochurch
I'm almost entirely backend, but I can relate to the travails of interviewing
in the Bay Area and dealing with unprepared interviewers.

The engineers were like anywhere else-- and a fair proportion of them were
very good-- but there are just a lot of arrogant people in the managerial
ranks of the Valley. After you get an offer and you get to the negotiation
phase, most Bay Area firms try to lowball you because-- even if you're from an
objectively better place like NYC or Austin-- _obviously_ everyone wants the
privilege of working in California. (Expensive housing even in the suburbs,
nightmarish traffic, and the most aggressive homeless population in the U.S.
Where do I sign up?)

Then there was one silly game company (which, presumably unrelatedly, is now
being sued) that wanted me to sign a full NDA just to do a coding test. Not an
NDA over the material of the test (which I would have signed) but one that
included a one-year non-solicit covering all employees of that firm.

I could be generalizing negative experiences, but it seems to be like they
didn't prepare for your interview (recognizing that you were a _front-end_
engineer) because of that obnoxious (and completely false) assumption that, if
you were any good, you'd already be in the Bay Area. Obviously they had enough
interest to take time out of their day, but not enough to prepare.

In New York, there are a lot of startups that are of low quality; but the
arrogance of Silicon Valley is unparalleled. Wall Street's reputation would
have you expecting it to be worse but, by and large, it's not.

~~~
thecage411
I haven't really seen the assumption that "if you were any good, you'd already
be in the Bay Area."

I have seen sort of the opposite, though -- if you are experienced, you likely
have a family and there is no way in hell you are moving to the Bay Area.

