Interviewing as a Front-End Engineer in San Francisco

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

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.

When interviewing engineers at my last gig, we tried to find people who will "get things done", which in turn depends a lot on your specific job role. For a good majority of the software dev positions we had, getting things done didn't require in-depth knowledge of arcane data structures or algorithms. We just needed the candidates to be smart, and ideally have some experience in what they were being hired for.

So for say an iOS dev position, we would pick the candidate who had released two apps on his own but maybe didn't know much about say red-black trees, vs. the candidate who knew all his CS theory but hadn't yet written a single line of iOS code. We also valued good communication skills, and what Linus refers to as "good taste".

However, we did have a few roles (machine vision, big data, etc) where algorithmic knowledge was essential to getting things done. And for these roles, we always favored candidates who had excellent math & algorithmic chops.

So it depends. I think the problem really is that most interviewers run all candidates through an identical "favorite list of questions", regardless of what the role is. This is quite unfortunate.