Interviewing as a Front-End Engineer in San Francisco

We were hiring a non-senior full-stack developer recently and I noticed there were no &quot;frontend&quot; 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 &quot;In JavaScript, what is the value of &#x27;this&#x27; in a method?&quot;<p>I would have accepted an answer as simple as &quot;The value of &#x27;this&#x27; depends on how the method is called&quot; or even &quot;The value of &#x27;this&#x27; confuses me because it&#x27;s often not what I expect.&quot;<p>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.

Are algorithm questions really that useful when looking for a candidate? I find myself being really nervous about applying to other jobs because I&#x27;m not formally trained in CS.<p>My job and side projects are mostly web sites that require knowledge about how to architecture software but I very rarely write complex algorithms.<p>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&#x27;s been 15+ years since I&#x27;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.

One problem is that many people associate front-end development mainly with HTML and CSS. HTML and CSS are not programming languages.<p>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&#x27;m much more drawn toward the CS-related tasks of the job such as writing JavaScript.<p>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.<p>As more sites gravitate toward complex JavaScript-driven web apps, it may be useful to ditch the general term &quot;front-end,&quot; differentiating C.S.-oriented front-end developers from those who prefer visual design.<p>This might make the expectations of a front-end development position much clearer, allowing for a simpler interview process.

&quot;I&#x27;d rather hire a smart person and teach them X then hire someone who knows everything about X but lacks creativity, logic, and reasoning.&quot;<p>False dichotomy. How about a smart person who knows a lot about X and is creative and logical? They do exist.<p>I feel like many interviewers want to categorize someone in to one of those two categories from the outset - &quot;this person already knows a lot about XYZ, therefore, I&#x27;d rather look for a smart person who doesn&#x27;t know XYZ and teach them&quot;. Sounds crazy writing it out, but it&#x27;s the impression I got years ago interviewing. It&#x27;s also the impression I get from friends of mine who have interviewed in the more recent few months.

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&#x27;d known about it ahead of time.<p><a href="https://github.com/darcyclarke/Front-end-Developer-Interview-Questions" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;darcyclarke&#x2F;Front-end-Developer-Interview...</a>

<i>I&#x27;d rather hire a smart person and teach them X then hire someone who knows everything about X but lacks creativity, logic, and reasoning.</i><p>This!<p>That one sentence pretty much addressed all of your questions and concerns. So instead on hacking the apparent process, read that sentence again and <i>get it</i>. This is pretty much an absolute truth in almost any industry for almost any skill. It&#x27;s especially true in tech because:<p><pre><code> - &quot;X&quot; will be different in 2 years anyway. - &quot;X&quot; 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&#x27;s so complicated to learn, it&#x27;s too complicated to use.</code></pre>

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&#x27;m about to talk about might not be like what is going on over there at all.<p>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.<p>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.<p>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&#x27;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&#x27;t going to hire them.

A coworker and I wrote a script that&#x27;s been through a few iterations based on feedback and tailored to whatever company I&#x27;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&#x27;s the front-end interview script I use: <a href="https://gist.github.com/potench/e71e09c882628054c119" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;potench&#x2F;e71e09c882628054c119</a> So far it seems to do a good job at promoting conversation and identifying thoughtful and talented FE developers.

As a follow-up to my earlier comment, i&#x27;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 &quot;Is this a front-end position or not? I know C# and .net MVC but i&#x27;m focusing my career on Angular&quot; his reply &quot;I honestly don&#x27;t know, they just told me to call you and ask you a series of questions on advanced C# development&quot; Job posting title &quot;Senior Frontend Developer with AngularJS&quot;

I&#x27;ve had similar experiences in the last month of interviews i&#x27;ve been through. I was asked how i&#x27;d design a secure backend API in asp.net, various algorithm questions, some basic javascript questions (&quot;what is a closure?&quot;, &quot;what does the var keyword do?&quot;, etc&quot;) 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 &quot;Is this a Front end Developer position you just interviewed me for?&quot; 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&#x27;ve had building Angular or Knockout apps or or cross-browser JS&#x2F;CSS issues.

This seems fairly typical, and I understand the rationale on both sides.<p>In any kind of engineering role, not just front-end, having domain experience&#x2F;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&#x27;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.<p>So why wouldn&#x27;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&#x27;t mean they won&#x27;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.

You were interviewed by back-end engineers. That&#x27;s what they knew.<p>My question is why didn&#x27;t you leave the interview upon seeing it was a waste of time?

You&#x27;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.<p>Interviewees always forget to figure out why they interviewer and company is asking these questions or requiring particular knowledge. Next time just ask them!

I&#x27;m a PHP&#x2F;WordPress dev shipping product every single day, but I think I&#x27;d probably fail questions like these if I was asked in an interview setting.<p>I don&#x27;t really worry about functions like these until a need arises, and when it does (and I don&#x27;t know how to do it), I learn until I do.<p>This is an absurd way to recruit front-end talent and partially explains the so-called talent crunch.

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).<p>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.<p>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&#x27;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&#x27;t even frontend oriented.

It could have been a sign that they trusted your front-end skill. If I know someone has a skill, I don&#x27;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.<p>So I&#x27;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?

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&#x27;re doing it wrong.

Great writeup. This is pretty much the same experience that I had when I moved to San Francisco. I got a lot of &quot;college memorization&quot; 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.<p>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.

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 &#x27;front end specific&#x27; 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?

I do lots of front-end work and have tended to do front-end phonescreens for the past few years. I&#x27;m a huge fan of Steve Yegge&#x27;s five essential phone screen questions: <a href="https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions" rel="nofollow">https:&#x2F;&#x2F;sites.google.com&#x2F;site&#x2F;steveyegge2&#x2F;five-essential-pho...</a><p>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&#x27;t!).<p>Designers-turned-JSers tend not to do so well on data structures and bits and bytes.<p>After the five questions, I move to HTML&#x2F;CSS questions: inline vs. block, what does float really do, the display property, valid values for display besides &quot;none&quot;, visibility: hidden vs display: none, position, absolute vs. relative (with relative offset parent questions thrown in).<p>For the JS portion, I ask scoping, closures, global object, the values of &quot;this&quot; based on calling context.<p>I like front-end engineers who are also, y&#x27;know, <i>engineers</i>. I like working with people who I can say &quot;that distributed system has performance characteristics akin to a hashtable&quot; and they know what I mean.

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&#x27;s frustration and have felt it myself. I&#x27;ve often stepped into interviews for other departments and teams that had no FE developers to give them a hand.<p>At the same time, I&#x27;ve come across far too many developers who assume &quot;front-end&quot; only meant HTML, CSS, and jQuery.<p>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&#x27;t describe some of the inner workings of JS to me, then I may weed you out. That&#x27;s just my preference though; other hiring managers differ.<p>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.<p>So whenever I&#x27;ve coached technical hiring managers who have no experience with front-end development, I&#x27;d tell them to go right ahead and ask questions on general programming logic. Even if the candidate&#x27;s verbal answer is incorrect, the thought process behind trying to answer it can be helpful.<p>FYI, the type of phone screen questions I would ask are:<p>+ Why is a doctype significant? (HTML)<p>+ What is the box model? (CSS)<p>+ Describe the event model. (JavaScript)<p>(You&#x27;d be surprised at how many purported front-end engineers get these wrong.)<p>These were accompanied by general programming logic questions. They all designed to assess the developer&#x27;s ability to communicate and explain, and not the developer&#x27;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&#x27;s experience. The &quot;What is the value of &#x27;this&#x27; in a method?&quot; question is a great one too.

I think these problems stem from the job posting. Like the author, I&#x27;ve come to love interviewing and I&#x27;ve conducted a good deal of interviews myself. I&#x27;ve noticed that a job titled &quot;front-end developer&quot; with a poor description casts too wide a net and wastes everyone&#x27;s time.<p>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&#x27;m going to feel like I&#x27;m attending amateur hour.<p>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.<p>Don&#x27;t envy the front-end developer. At this point we have to be prepared for anything.

I believe the mindset behind this behavior is A) they take it for granted that you&#x27;re proficient in your stated area of expertise, B) they&#x27;re not necessarily proficient in your area of expertise, so wouldn&#x27;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.<p>Google&#x27;s publicly available prep material reinforces this third point, even if they don&#x27;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.

Similar in NYC. I remember an interview where I was asked to bit-shift in Javascript, for the sake of itself.<p>I&#x27;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.

I&#x27;m sorry you had to go through that bullshit.<p>That generally sucks when you&#x27;re interviewed by assholes who have no idea that the specific platform that you might work on requires.<p>Consider most front-end engineers ALSO to be designers, and I&#x27;d suspect thats where I would drive the interview. I would wish the same treatment.<p>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.<p>The latter is more admirable, but depends on the situation at hand. 5 minutes, white board, using your fingers as eraser.

I was full stack at my old job, so I do phone screens for front end engineers now. It&#x27;s incredible how many people claim &quot;front end&quot; 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&#x27;t ask questions like &quot;how would you optimize the static content of the page?&quot; I&#x27;m sure we would end up hiring OK general devs who actually don&#x27;t know anything about front end.

I interviewed for a long-term &quot;Frontend engineer&quot; role in June for a large cable company here in the Netherlands. I&#x27;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.<p>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.<p>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.<p>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&#x27;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.<p>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.

I know it&#x27;s a bit off-topic, but I&#x27;m a student so anything about interviews interests me a lot. For the Bacon Number question, I&#x27;m struggling a bit to get my head around a good way to do it.<p>My immediate idea is to derive a graph where nodes are actors and an edge between 2 actors means they&#x27;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.<p>It looks like that graph would be quite slow to derive though - my naive pseudocode being something like:<p><pre><code> 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 </code></pre> That looks pretty slow without deriving a running time, so I&#x27;m guessing there&#x27;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?

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 &quot;get the job done&quot; on the front-end. If hiring for a smaller company, I would be concerned about this person&#x27;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&#x27;s potential for future growth. Also, it&#x27;s usually apparent from projects or employment history that someone can do what&#x27;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&#x27;d rather take the opportunity to find out if they&#x27;re a solid engineer as well.

My understanding is that this is type of &#x27;shallow&#x27; technical interview in SF with notable companies is not limited to front-end.<p>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.<p>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.

Concerning that they ask you computer science questions when you will be working on the front end.<p>What if you were to ask CSS and Javascript questions to a DBA? Do you see how absolutely ridiculous that sounds?

I interviewed at a well-known place here in Portland and they seemed really disappointed that I didn&#x27;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.

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.<p>It is interesting that the company I ended up at-- while they did ask some standard algorithm and &#x27;how do you think&#x27; 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.<p>Thanks for posting this!

Hey. I work at Twitter. I think that at certain companies the &quot;front-end&quot; 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.<p>Having said that, I&#x27;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.

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

&gt;&quot;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.&quot;<p>How does the referenced jquery statement represent basic CS principles? OOP? Definitely not that.

The two CSS questions I ask (but skip depending portfolio quality):<p>1) Make these two discs sit next to eCh other. What other ways you could do that? Why each way bad&#x2F;good for what?<p>2) center this. Other ways? Bad&#x2F;good about each?

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

Those are excellent suggestions in the &quot;My Suggestions&quot; section. Thanks for the article.

I&#x27;m almost entirely backend, but I can relate to the travails of interviewing in the Bay Area and dealing with unprepared interviewers.<p>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&#x27;re from an objectively better place like NYC or Austin-- <i>obviously</i> 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?)<p>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.<p>I could be generalizing negative experiences, but it seems to be like they didn&#x27;t prepare for your interview (recognizing that you were a <i>front-end</i> engineer) because of that obnoxious (and completely false) assumption that, if you were any good, you&#x27;d already be in the Bay Area. Obviously they had enough interest to take time out of their day, but not enough to prepare.<p>In New York, there are a lot of startups that are of low quality; but the arrogance of Silicon Valley is unparalleled. Wall Street&#x27;s reputation would have you expecting it to be worse but, by and large, it&#x27;s not.