Interviewing as a Front-End Engineer in San Francisco

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.

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

    There are only two hard things in Computer Science:
    cache invalidation, naming things, and off-by-one errors.

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.

I studied computer engineering and have no desire to take the FE exam, as being licensed is almost entirely useless in my field. As far as the difference between "engineers" and CS majors, at my school basically the only difference is math requirements, and how math is used in the higher level classes. In ECPE (computer/electrical) we differentiate ourselves from CS by studying circuits, systems, physics which are very calculus-intensive. The area where it crosses over into CS is when you get into computer architecture, digital design, assembly, which is like programming, but due to being so close to the hardware level (working with raw digital logic) it ends up being more math intensive than most high level programming.