Grow your CSS skills. Land your dream job.

Interviewing as a Front-End Engineer in San Francisco

Published by Guest Author

The following is a guest post by Philip Walton (@philwalton). Philip recently went through a slew of interviews for front-end jobs at tech companies in the Bay Area and found them to be not what he expected.

A few months ago I started casually looking for front-end gigs in the San Francisco Bay Area. I liked my current job, but I felt I was outgrowing the tech scene in my town. I wanted to leave my small pond and see how I'd fare in a big one, with some of the best developers in the world.

When I started looking I knew I wanted to work at a place where I wouldn't be the expert, so I only applied to big name companies. The whole experience ended up being quite valuable, and through it I got a chance to meet some of my heroes and visit the offices of some of my favorite companies.

But it wasn't all good. In fact, after looking back on the process I can't help but feel like there is something fundamentally wrong with the way tech companies interview their front-end candidates.

Before continuing, I want to offer this disclaimer. Parts of this article are going to be critical, so I think it would be best to keep the names of these companies anonymous. After all, who they are is not relevant to my overriding point.

The only details I will share is that I applied to and had phone interviews with six companies, four of which invited me to interview on-site. In total I had 23 different interviews, all of them technical.

The other thing worth mentioning is that these were all well-known companies. Companies I'm 100% sure you've all heard of, and I mention that not to brag, but to suggest that since they're the ones who set the bar where it is, the experiences I had were probably pretty close to the norm.

My Experience

Overall, my experience was quite good. Some of these companies have a reputation for their excruciating interviews, but what I went through was not nearly as bad as the stories I'd heard. Everyone was nice, everyone was professional, and if I didn't know the answer to something, I never felt belittled. Most of the time it just seemed like a simple conversation about technology between two people discussing the best way to solve a problem.

But there was something obvious missing: front-end specific questions!

Now, I'm no interviewing expert. And I'm sure most hiring managers would disagree over how to best measure the effectiveness of any particular set of interview questions. But one thing I'm sure everyone can agree upon is that the questions you ask should be questions that will be best answered by the most qualified people for the job.

To put that another way, if a talented computer science grad, fresh out of college, with almost no front-end experience can outshine a great front-end engineer in your interview, you're probably asking the wrong questions.

This basically sums up my criticism. The overwhelming majority of my interview questions were logical puzzles, generic coding challenges, and algorithm design problems — things that are necessary but nowhere near sufficient.

What Was Missing

I know several people who do a lot of interviewing, and I hear the same line from them over and over: 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.

I get that. The problem is that front-end development is a domain specific skill set. It's not just about mental ability, it's also about knowledge and experience.

Front-end engineers, at their most basic level, are developers who write code that runs on the user's browser. Today that means someone who writes HTML, CSS, and JavaScript and knows the various APIs that browsers expose. The difference between the general term "programmer" and specific term "front-end engineer" is simply the domain where one's knowledge exists. A superstar front-end engineer is probably also a superstar programmer, but the reverse is not necessarily the case (often not).

If you agree with what I've just said, then you can understand my surprise at the absence of some of the following topics from all 23 of my interviews:

  • I wasn't asked a single question about new or upcoming HTML APIs.
  • I wasn't asked a single question about the differences between various browsers and browser versions or how to target/deal with those differences.
  • I wasn't asked a single question about the differences between desktop and mobile browsers or about techniques for building webapps to run on both.
  • I was asked just one CSS question (just one!), and it was "tell me the difference between inline and block", a question that even most non-front-end people know.
  • I was only asked one question that had anything to do with the DOM, DOM events, or event binding.

What I was asked is a lot of questions like these:

  • Write a function that takes two sorted lists of numbers and merges them into a single sorted list.
  • Given an array of integers (positive or negative) find the sub-array with the largest sum.
  • Determine if a given string is a palindrome.
  • Given a large hash table whose keys are movie names and whose values are a list of actors in those movies, write a function to determine the Bacon number of a particular actor.

Again, I don't want to imply that there isn't value in asking these questions. The problem is they have nothing to do with front-end development. As I said before, most smart developers with a strong computer science background could answer all of these, even if they'd never built a website.

So What's Going On?

I'm sure part of the problem is the newness of the need for front-end only positions as well as the term "front-end engineer" itself. It's not a well-defined term and could mean very different things depending on who was using it. I'm willing to admit the possibility that my idea of a front-end role is different from those who were posting the job, but I suspect there's more to it than that.

Another likely causes is that the majority of my interviewers were not themselves front-end engineers. They were senior team members, hiring managers, VPs, founders, etc, but they were usually not front-end engineers. As a result, they stuck to what they knew, and they asked the same questions they always ask.

My Suggestions

Given my recent experience, I want to offer the following advice to anyone reading who might be interviewing a front-end engineer in the near future.

  • Front-end candidates should be interviewed by at least one front-end team member (preferably more). If you don't have a front-end team member, find someone you know and trust and ask them to do it.
  • Obviously topics like logic and algorithms are important, especially for certain companies, but if you're interviewing for a front-end position, a substantial portion of the questions should focus on the front-end.
  • If you really want to ask questions about logic and algorithms, figure out a way to do so that combines your questions with front-end specific knowledge.

To illustrate that last point, instead of asking about the complexity of merge sort, ask about the complexity of this jQuery expression:

$("#nav a")
  .attr("data-initialized", true)
  .on("click", doSomething)

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.

Instead of asking someone to write a function that adds two dates, have them build a simple calendar widget to go along with it.

Instead of quizzing them on CSS trivia, give them two paragraphs of text and see how many ways they can think of to arrange them side-by-side as columns. Then ask them to describe the pros and cons of each method.

Finally, good front-end engineers tend to be very self-motivated. Since browser technologies aren't usually taught in schools, most front-end engineers learned this stuff on their own. So instead of asking them what they know (which is of limited value), ask them how they stay current, and how they keep from falling behind. What are they doing to make sure they'll be better in a year than they are today?


Interviewing is a tricky thing, and even some of the most innovative companies get it wrong sometimes. And interviewing for a front-end position can be even harder because of the ambiguity of the term and the range of expectations that come with it.

The impression I got from many of my interviewers was that most of these companies have only recently begun to realize the importance of dedicated front-end people. Their front-end code bases are starting to get massive and really hard to manage. And part of the problem is the people who manage them aren't well versed in front-end best-practices.

If you're looking to hire a front-end candidate, consider reexamining your interview process. If you're doing some of the things mentioned in this article, you may very well be missing out on some great people.

If you're looking for a job as a front-end engineer, you couldn't be looking at a better time, but if my experience is any indication, I would suggest brushing up on some of your computer science fundamentals. One resource I highly recommend is the MIT Open Courseware lecture series, specifically Introduction to Algorithms.

Lastly, I hope this article isn't just seen as a rant by someone who didn't like his interview questions. That is certainly not my intent. My hope is that I can do my part in raising the bar for front-end work in our industry. And I believe one of the best ways to make that happen is to help companies hire the right people for these jobs.


  1. This is a great insight, and also slightly terrifying

  2. Josh Johnson
    Permalink to comment#

    I’ve been looking at that jQuery function for 5 minutes and it just doesn’t seem that complex? Besides being an assumptive selector, I can’t see much wrong with it – excuse my ignorance!

    • Permalink to comment#

      Two things I noted:

      Why is it adding the class “link” via javascript? Based on this bit of script, it doesn’t seem to be conditional, so why not just add it via HTML and save that bit of DOM manipulation.
      Ditto above for data-initialization attribute.

      That being said, those seem like pretty minor things, so I would love to hear from the author about what I might be missing.

    • I was mainly referring to algorithmic complexity, not complexity in the general sense. Algorithmic complexity is used to determine the efficiency of an algorithm.

      But you’re correct in pointing out that there’s nothing particularly “complex” about that expression.

    • Hery
      Permalink to comment#

      Your comment is funny. I think by “complexity,” he meant “time complexity.”

    • Benjamin Goering
      Permalink to comment#

      The biggest thing I noticed is putting a single click handler on each anchor in #nav. That will take up memory proportional to the number of anchors (linear complexity).

      Instead, it would be better to delegate the click handler to the nav, so that there only needs to be one (constant time complexity).

      $('#nav').on('click', 'a', fn);
    • SZRimaging
      Permalink to comment#

      @Benjamin Goering – Do you have any more information about this? I’m failing to figure out the proper google search terms to find out more. Would like to reduce my memory usage if possible.

    • Erik Reppen
      Permalink to comment#

      $(“#nav a”)

      //Two native dom API calls that are fast. No problems here unless id="nav" is more
      //broad than your typical ul/li/a scheme
      //this loops through the collection
      //it adds 'link' to the class in every element. This triggers CSS reflow I suspect only
      //once since it all gets set in one function
        .attr("data-initialized", true)
      //this doesn't actually loop although I suspect you might expect it to
      //it changes the first element in the collection triggering reflow yet again.
      //If the idea is to change all links assuming we still wanted to do that
      //it would be better to change  the attributes in a .each loop and I personally
      //would access via this['data-initialized'] to avoid potential overhead in the attr method
      //which probably does a ton of branching for form element issues
       .on("click", doSomething)
      //and now a second or third (intended) loop of all the elements
      //better to use bubbling or set in the same loop so we don't iterate the same collection //2-3 times needlessly
    • Griz
      Permalink to comment#

      I think the idea is to explain what jQuery is really going to do in the context of the 3 front-end technologies.

      #nav could possibly be a nav element
      adding the ‘link’ class programmatically could likely be optimized without JS
      data-initialized is an HTML5 element boolean attribute
      adding the click event uses jQuery event management which could optionally be namespaced
      doSomething is a named function within the current JS scope, but will also be executed in a different scope (‘this’ will change)
      due to lack of event delegation, you can assume it’s a static nav (which your comment suggests)

  3. Code is like language, not everyone who knows the language can write a book.
    Interviewers want to see if you can write a great book with your language skills.

    In other words, can you give the best solution for the problem with your skills.

  4. Great insight Philip, Thanks for sharing.

    However, I would like to clarify something since your term ‘Front End Engineer’ can be confusing for other, like me, Front End Developers that may read this article.

    In very simple terms, you’re a Web Developer, a.k.a Front End Engineer, more than a “Front End” guy.

    However, you happen to have something that no web developers I’ve met before have: You worry about Front End stuff, and that’s awesome :].

    So after reading your experience, I see that HTML, CSS and JavaScript is the overlapping ground were “Front End Developers” and “Front End Engineers” meet, whereas the first may have more ‘Web Design’ influences and the second more ‘Web Development’.

    Clearly the Web Industry Job Titles dance gets even more complex…

    Again, Thanks for sharing your experience.

    PS. Who would want to leave Google? o_O

    • The Google job is the one I ended up taking :)

    • jsdev
      Permalink to comment#

      Other than people leaving Google for pre-ipo facebook, twitter, and snap chat, or better yet to start their own…

      But yeah Google is #1 place to work for many years in a row. Lots of happy engineers doing amazing things.

    • Ricardo, I agree with your questioning the semantics of the word “engineer”. The term is way overused and has lost meaning, unfortunately.

      My education was in Computer Engineering, in which I learned many facets about the physics, math, systems, theories and models of digital and analog technology (components as well as electromagnetics). My peers and roommates were usually in some engineering discipline; chemical, electrical, mechanical or civil (and perhaps physics as major).

      Sure, these things can become more specific when applied in industry, and some schools even go so far as to develop programs for them, but there is a common thread between them of using defined systems with designed behavior, physics, equations and math, and an understanding how it all fits together to create things. It’s still a debate in my mind about calling anything purely software a form of “engineering” without the physical aspect and I find it more appropriate to use the word “developer”.

      I refer to myself as a Front-End Developer, but of course am forced to take whatever title is bestowed by the employer. At parties and in general public I find it easier to just say “I make websites”.

  5. I knew exactly what this article after reading the introduction sentence. Everyone at these top companies are people who really know their computer science, and it would be a pretty big shift to start hiring people who didn’t. By leaving things as they are, these companies are definitely missing out on some pretty great front-end developers at the cost of ensuring they’re not hiring someone bad.

    To me, this is the difference between a front-end developer and a front-end engineer; the latter is a software engineer who can participate in any software development activity without problems but is focusing on web development.

    I definitely agree there are issues and maybe there needs to be a balance or something, it kind of boggles the mind to think that you’re not being tested on what you’re actually going to be doing.

    Also, I recommend Steven Skiena’s The Algorithm Design Manual for everyone interested in giving it a go. It goes over complexity, data structures, algorithms, etc. with very minimal formal math.

  6. Henri Helvetica
    Permalink to comment#

    Nice post. I’ve oft spoken to recruiters who knew very little about dev/code but somehow were left in charge at some point of the hiring process. Wonder how Philip feels about Darcy Clarke’s ‘Front End Interview Questions’ ( Either way, that was a pretty enlightening post. Certainly something to keep in mind and to keep the blade sharp. Thx.

    • @Henri Helvetica, Most recruiters’ scale of understanding of dev/code moves between the following values:

      Zero • ——————— • Nothing

      Rarely (very) I’ve met someone with some blurry idea of dev/code, and I’ve experienced this very recently with several recruiters for several months.

  7. Had a similar experience which discouraged me from pursuing San Francisco opportunities. I interviewed with about three similarly Big companies out there. There were logic puzzles and mini projects to test my abilities in theory and practice, and I did have many frontend-oriented pair coding sessions with different people, and they did ask many of the kinds of things you outline–especially over the phone. For some reason, my phone interviews always felt strongest, even though I’m pretty sure I was performing at the same level over phone and in person.

    But I ended up walking away feeling like any company in that area was going to take a lot of time and energy to interview with but would be less likely to make me an offer as the scales are weighed in favor of those with solid computer science backgrounds, whereas mine is in design.

    In the longterm, I couldn’t see working for any of these companies as being significantly more satisfying than working for myself. I decided to save the hours out of my life I would have spent making myself to their liking and instead spend them on making projects, landing clients, and teaching, all wholly more satisfying than a rejection letter after marathon interviews.

    What I’m getting at is that you can’t buy back the hours out of your life. If you REALLY want to work at one of these companies, if it’s REALLY going to make you happy, by all means go forth and remake yourself in their image. Court them rigorously! But, if you’re unsure that working for Tech Giant in SFO A will make you happier than working for Medium-sized Startup in New York City B, then maybe it’s not worth the extra effort. Life’s too short to beat yourself up over other people’s expectations if there’s important, fulfilling work you can do right now.

    • Jake
      Permalink to comment#

      This is the first comment I agreed with. “You can’t buy back the hours out of your life.” — So often, it seems like people don’t realize time is as valuable as money. I interviewed once in Silicon Valley, and have since passed on every opportunity to go back. Just like I decided not to get my PhD and become a professor, I decided there are too many opportunities all over the world to focus myopically on getting past the doors of one company in one tiny little valley guarded by Stanford Valedictorians. Sure, I could probably do pretty well if I wanted to make the effort- it’s just that the reward is hardly better than what I already have.

  8. Andrew Shebanow
    Permalink to comment#

    As a front end developer at Google, I sympathize with your point of view. But as someone who does a lot of interviewing, I can tell you that the problems you think “most smart developers with a strong computer science background could answer” are anything but. You would be amazed at how many people I interview who have many years of experience yet completely fail at the most basic CS/math questions. The fact that you found them straightforward is a testament to your own abilities, and not something you should generalize.

    • Tanel Suurhans
      Permalink to comment#

      Andrew Shebanow: so that’s exactly my problem with this approach in my opinion. I’m going to base this on my personal experience as an example but I’m sure there are tons of people like this out there.
      So I graduated from university about 8-9 years ago. Most of the CS stuff, especially algorithmic etc., is not something you get to use daily at your job (thats because these issues are usually solved for you and hidden in the tools or frameworks you use). So obviously I’m rather rusty on algorithmic or puzzle questions. But then again as I have the knowledge, I just need a little to remind me about it – like a quick Google – and I can pick it up again. Now when conducting interviews I hate the fact that I actually have to know algorithmic stuff that I don’t use at my daily work and I also don’t seem them being relevant to my experience and skills as well to some extent. I have over 10 years of experience, I have a diverse engineering background, I’m not terribly good at puzzle questions – but I always get my work done, produce good quality results and have had nothing other than awesome feedback. And I will easily be pushed aside for a candidate fresh out of school, with zero real-life experience, but who has a good grasp on algorithms and just remembers them freshly. I personally see this as a problem and I don’t feel like companies are really trying to fix this either. For them it’s easier just to deal with missing a good candidate vs hiring someone who fails their tests and eat up that cost. I mean I get it, you need to have something to measure a candidates skill by, but I think right now the questions used are not ideal.

    • Alex Gorbatchev
      Permalink to comment#


      I would be one of those developers who would fail CS questions. I’m self taught and I’ve been a full time full stack developer for ~15 years now. So far I am yet to encounter a CS related problem on my job. Please look back at the last couple of weeks worth of your work and ask questions related to that, not back from your CS courses.

      I interview people multiple times a week for full stack web dev position and at no point do I care if they can sort arrays, btrees, create random shuffle algos, reverse a linked list or anything else from that domain. I care if you can be productive and contribute to our team with tasks that we do on daily basis. Do you have understanding of JavaScript? Closures? Async? What about CSS? Multi-column layout? Rendering speed? Do you have experience with TDD? How would you approach testing async code? These are the problems that we solve. Ability to commit to memory CS textbook isn’t one of them.

      I would love to hear what kind of problems front-end engineers at google encounter that require CS?

    • Carrie
      Permalink to comment#

      I, too, would fail that kind of interview, and have worked as a webdev for 17 years, at companies as big as Dell, Intel, and Microsoft. In all these years, I’ve barely had to deal with anything more complex than high school math – test me on the type of tasks I’ll be doing when I sit at the computer on the job, not on some vague theories that don’t have anything to do with anything. My favorite interviews are the types that give you a little homework task to turn in – let me just show you that I can get the job done.

    • olivvv
      Permalink to comment#

      And those who fail basic CS / math questions, do they end up being good or bad devs ? As a dev, I never have to write “classes in js”, or closure definition monologue or sort algos (typical CS course but I ‘m self-taught), etc
      So I can easily freeze when questionned on it. Now I did train that type of things, but it is specifically for interviews, not for any real world usage.

    • Michael Hasenstein
      Permalink to comment#

      I too just have to agree with everyone who responded before me. I’ve always been really good with theory and algorithms, recently started math again (correspondence study) just for fun (I doubt I’ll finish with a degree – I already have one in CS, I just want to test my brain).

      However, in all my many years of work in the valley and now (back) in Germany I have yet to encounter a real hard “CS” problem, and if I do (once a year or less?) I can find the solution through Google in a minute or I can formulate the algorithm myself spending MORE time.

      What is MUCH more important, I have found, are people

      Willing to take on a(ny) challenge, who don’t lean back and say “I can’t do this, I’ll let someone else take care of this issue”
      Who love to write (inline!) documentation – really describing WHAT they do and WHY and not what happens (anyone who can read code can see that!)
      Who are relaxed, which means admitting not knowing things and mistakes you made comes EASY, instead of pushing it under the rug.

      The least necessary ability I have (or had? it probably has degenerated) is to come up with algorithms for the problems presented as examples above.

    • Wojtek
      Permalink to comment#

      Guys, we’re talking here about basic stuff. Figuring out an algorithm to check for palindrome is not rocket science. You’re not even supposed to remember it, you’re supposed to come up with one on spot.

      These questions aren’t supposed to check your memory, but your creativity, basic knowledge of control flow and basic ability to assess algorithm complexity.

    • Andrew Shebanow
      Permalink to comment#

      To be clear here, I’m talking about front end engineers, not pure web developers. Google hires lots of pure web developers, but not to work on complex web applications (e.g. Google Play Music, which I work on). For those kinds of applications, you need to be able to do serious programming in Javascript, just as complex and difficult as anything found in server-side Java/C#/whatever. The skill sets for the two positions overlap but are very different at the end of the day.

    • JW
      Permalink to comment#

      function palindrome(s) { var n=s.length-1; return n < 1 || s[0] == s[n] && palindrome(s.substring(1,n)); }

      Tail-call recursion optimization in JS please :)

  9. Neil Jacobson
    Permalink to comment#

    Very good points and a good criticism of the interview process as it appears to have evolved. The biggest problem with many of the interview questions you were provided is that they don’t even identify ‘smart people’ as one of your subjects noted the intent, they mostly identify someone who has heard that question before. And, of course, they don’t reflect ‘real life’ issues which are usually far more mundane and if they did arise, the expected solutions don’t illustrate how you would likely solve them. In real life you would use libraries and APIs and are not likely to ‘roll your own’ solution. In fact if you did I would immediately suspect your skills.

  10. Jon Forrest
    Permalink to comment#

    “Another likely causes” -> “Another likely cause”

  11. You did not mention where u went for interview and which kind of question they asked u that u reject their job

  12. Permalink to comment#

    I think the reason for such screening process has to do with the role the “engineer” will play. When you’re hired in places like google, github, they tend to have you work across the stack and not just one specific area. In fact it is a good thing for the new hire, since he will learn a lot in return.

    So they are willing to take a risk with someone who doesn’t necessarily know all of the nuances of front end but solid in CS and can adapt when needed.

    I think they should really have two different positions. One should be Front-end-developer and Front-end-engineer.

  13. Permalink to comment#

    This is sadly truth about job interviewes. I recently had one about PHP syntax for arrays, written in …. 2005 ! so the wrong answer [] became true.
    Very sad.

    BTW, I would optimize your jquery event handler. Am I right ?

  14. Eric
    Permalink to comment#

    I recently walked out of a job interview where I was asked to write – on paper, no less – the HTML and CSS for a javascript-free drop down menu that would work in IE 6. I asked if this task was indicative of the kind of work I’d be expected to do on a daily basis, and the two guys interviewing me gave different answers: one said “well, um, probably not” (then why am I doing it in the interview?) and the other said “yeah, all of our products need to work in IE 6″ (thanks, I stopped building IE 6 compatibility 4 years ago).

    In short, right then I realized that this place wasn’t worth my time.

  15. Permalink to comment#

    Perhaps they really are just looking for more CS-oriented engineers.

    I’m working on a big project currently, and some of our front-end devs barely touch html or css. Much of the work they’re doing involves extending our MVC framework (Angular in this case), writing unit tests, or writing APIs for our junior devs (including me) to consume. If we had to replace them on the project, a interview question about jQuery wouldn’t help us find the right candidates.

    I understand that front end engineer is a broad enough term that it may encompass everyone from the kind of people who write frameworks, down to people who only write html and css, but I’m guessing that the larger companies may be having a harder time finding the former class of developers.

  16. I think I’ve interviewed at some of the same places (though it’s hard to tell because the questions are so meaningless they could be for literally any programming job anywhere), and while I mostly agree with you, I think you’re being too generous. You mention that maybe this technique for interviewing front-end devs is the result of not having needed them before, but based on your description of the types of companies you interviewed at it seems they would have needed front-end devs to reach the point where they’d be on your radar.

    My theory is that this is not a problem of companies hiring their first front-end person; those companies need an expert and if they’re looking for someone to fill a niche will in my experience be very careful to find someone who fills it as well as possible. On the contrary, I think it’s a problem that comes up when companies begin hoarding engineers, aren’t hiring people to accomplish any specific task or provide any specific expertise, and mainly just want more bodies available for projects that may come up as they continue their expansion. For that reason, I’d argue that front-end folks should not bone up on their algorithms, but should instead run the opposite direction when they find themselves at an interview where all the questions are generic and none pertain to specialized skills they want to continue to use and hone. If someone is interviewing you as though you’re a commodity, commodity is the role you’ll be accepting.

    • Great points Garann! I think you’re probably right about the commodity perspective and engineer hoarding. I hadn’t thought about it that way before.

      At my last job I was hired as the first front-end engineer, and I was asked a lot more front-end questions. Specifically, I was asked the questions they’d recently been facing and didn’t have good answer to.

      Also, I’m a huge fan of Frip Frap!

    • If someone is interviewing you as though you’re a commodity, commodity is the role you’ll be accepting.

      I like that sentiment.

      If the interview is lame, the job probably will be.

  17. Corey
    Permalink to comment#

    Great post. Just to play devils advocate – My guess is that when you applied for a front-end engineering position you supplied the employer with either a portfolio, sample sites, or at least a list of past projects that they could search for in order to get a feel for your front-end work. Through this they probably could determined that you were a proper candidate.

    A lot of those “puzzle” like interview questions are to see your approach. Your ability to demonstrate your approach trumps your portfolio. Remember, programming positions are unlike graphic design or copywriting ones. People need to see your problem solving approach with their eyeballs. They can’t just trust your portfolio. Code is too easy to copy without understanding it.

    A smart interviewer is deathly afraid of hiring a MindWizard that will “contribute” negative value. MindWizard’s “solve” problems by “rapidly” downloading things and gluing them together until something appears on the screen.

  18. I think it’s risky to assume too much about what a company needs and should be asking you about. You’ll generally be interviewing for an opening in a specific team, and they’ll know what they’re looking for.

    For example, why ask about webapps running on mobile and desktop browsers if you don’t have or want any? If a company is using Angular, why ask about jQuery? If the role is largely focused on day-to-day product development using Node.js and React, why focus on asking candidates about low-level DOM issues that React takes care of? If you’ve already got a good UI framework, why spend the interview asking a candidate about how to write CSS at scale?

    The suggestion to combine questions with front-end specific knowledge could be a nice way to ease someone into an interview, but you could also argue that a strong candidate should be able to tackle problems without them being packaged up in a familiar box. So at some point, you’ll want to see how someone thinks about something unfamiliar to them, if that is a situation they will frequently find themselves in at work.

    Having said all that, I’m really surprised at how few CSS questions you were asked! And congratulations on joining the Google Developer Relations team.

    • Permalink to comment#

      I agree with the spirit of this comment, but I think it misses the point of what Philip is saying.

      You’ll generally be interviewing for an opening in a specific team, and they’ll know what they’re looking for.

      I think Philip’s point is more along the lines that if they knew what they were looking for, it would be much more obvious. If the same questions can be asked on an interview for a .NET developer, then clearly the questions lack focus.

      why ask about webapps running on mobile and desktop browsers if you don’t have or want any?

      Well, what do they want? I think Philip’s point is that the questions should be specific enough to target exactly what will be worked on.

      If a company is using Angular, why ask about jQuery?

      Again, I don’t think his point has anything to do with specific technologies. Of course they would not ask about jQuery if that’s not part of the job description. The article is saying that they didn’t ask enough front-end specific questions associated with the technologies that will be worked on.

      why focus on asking candidates about low-level DOM issues that React takes care of?

      Same deal. They didn’t ask about React, or much of anything else. That’s his point. They’re looking for smart people in general, not necessarily smart front-end developers (which goes back to Garann’s excellent point on being a commodity).

      So at some point, you’ll want to see how someone thinks about something unfamiliar to them, if that is a situation they will frequently find themselves in at work.

      If the job is for “front-end engineer”, why would they “frequently” find themselves in unfamiliar situations? Yes, of course, new and challenging problems come up all the time in front-end development. But all those problems are within a particular framework of technologies. In other words, the questions can be very specific to the technologies, but unfamiliar enough to present a real challenge to the candidate’s skills and experience.

      Again, I think one of Philip’s strongest points in this article, and which Chris nicely addresses, is that many of the questions can be answered more effectively by someone who has never even built a web page, let alone used the DOM APIs.

      The scary part is, if these companies do know exactly what they’re doing (as you seem to suggest), then clearly Garann is right and they view developers as nothing more than a commodity.

  19. Borat
    Permalink to comment#

    By your article I can see that you are very entitled and think of yourself as someone very special and one-of-a-kind.


    A superstar front-end engineer is probably also a superstar programmer, but the reverse is not necessarily the case (often not).

    This is most ridicilous thing I’ve ever read.

  20. Permalink to comment#

    I’ve been interviewing around SF and Silicon Valley a bit for front-end , and I’ve been unimpressed by the interview process. You really are spot on. Like you said, they asked a lot of computer science questions that are perhaps not as relevant.

    One company asked me to replicate the levenshtein distance algorithm. Another asked me about Service Oriented Architecture. While these are important to know about, it says nothing about if I can write good Front End code.

    A savvy Front End person should probably know about good CSS architecture, and more importantly, why it matters (SMCSS, OOCSS, BEM). On the JS side, the DOM and relevant APIs to the company. Maybe how to deal with async stuff. Then to echo what you said, how they learn and keep up to date. Markup and layout is pretty basic, though I will say I’ve seen it butchered by a “front end developer” before. A basic code challenge prior could probably filter them out though.

  21. Yes! Conducting better interviews is one of the most obvious ways that most companies can improve their recruiting process.

    It’s not just a front-end engineering problem though; all sorts of employees are sent in to do interviews with little idea what questions to ask or what specifically they are trying to evaluate. Often they spend time asking the candidate questions that have already been asked in previous interviews, or simply dream up new questions on the spot to fill the time. People, we can do better!

    Ideally, each interviewer has game plan prior to each interview, so they know what questions to ask and where they should focus the interview. The focus of each interview should be driven by a set of criteria for the hire, so that candidates are assessed holistically – particular technical skills, knowledge, key personality traits & motivations, fit with the team/company, experience, etc.

    The thing that frustrates me is, it doesn’t have to be this way! The good news is that increasingly, companies are coming around to the idea that focusing on recruitment is one of the most highly leveraged ways that they can add value so I think it will continue to improve even if there’s still a long way to go.

    If you want to see a list of companies that have embraced a more sensible, structured interview process, check out my website for a list of our customers.

  22. Duncan
    Permalink to comment#

    I had a similar experience interviewing in NY recently (though what amazed me most was the sheer amount of time some large companies spend interviewing—weeks!). Even some advertising/design agencies were seeking serious institutional knowledge over self taught skills.

    However, I certainly feel that that’s the wrong attitude, and I think you’re spot on about the reason for the difficulties in interviewing front end: the field is changing so rapidly, it’s hard to know what makes a good front end candidate. The most important qualification is the ability to continually reinvent yourself, and to not be wedded to your process, but how do you interview for that?

    And, while a lot of front end tasks have a lot in common with straight ahead programming, how incredibly valuable is having the ability to organize a project’s CSS and create a custom framework? No amount of testing one’s ability to construct binary search algorithms will tell you if that particular developer can create modular and reusable elements which will allow your project to fly through it’s final stages.

    Perhaps, if I were interviewing, I’d spend my time asking a developer to defend his/her development process. If she uses grunt, I’d want her to convince me that using grunt is a good idea. Same applies to Sass, Less, etc. I’d bring up a CSS organizational philosophy: BEM, OOCSS, SMACSS, and ask about potential benefits/costs to using it.

    To me, front end development is first a mediator between very opinionated disciplines. It needs to be pragmatic and flexible, always looking for another way to accomplish a task in case the first preferred method doesn’t work. But front end development is also still developing rapidly outside of the institutions, it’s not for everyone, and it can be evaluated as much by a designer as it can by a programmer.

  23. I Would love a follow up post that presents the solutions in JavaScript / jQuery to these logic puzzle questions…

    A very insightful post that was a pleasure to read.

  24. Permalink to comment#

    My experience talking to google recruiters really mirrors Tanel’s feedback. After speaking with a recruiter about various opportunities at Google (everything is possible but the recruiter can’t talk about anything specific that’s going to work for me) and their interview process (starts with a phone call about basic CS type stuff which feels completely divorced from what skills I use day to day as a developer for the past 10 years) I decided not to even bother with the first technical interview. What is more discouraging is that since then every month or two it seems they have a new recruiter who writes me trying to get me back onboard, completely oblivious to the reasons I gave for not continuing in the past.

    I’m rather skeptical these days, I do not talk to recruiters and only look into companies where I have a chance to talk to someone in a similar role that they are hiring for. Google’s approach probably works for new hires (as it worked for me when I started at Microsoft back in the day) but I think they’re limiting themselves quite a bit.

    I also think its silly that google has teams that work together remotely but still expects everyone to come into the office. But thats a bit of a tangent.

    BTW if you work for a company that is looking for a developer with lots of development experience doing front-end and .NET stuff, preferably remote, I’m putting my github profile in the website link (and one of my public repositories contains my resume).

  25. Dom
    Permalink to comment#

    Perhaps consider an alternative perspective: In my experience most good interviewers will be more interested in your soft skills since they would already know your technical capability based on your online profile (GitHub, Blogs, etc), your past experience and references. If they don’t know that and are interviewing you asking technical questions, may I suggest they haven’t done their homework?

    More front-end questions (in my humble opinion) is exactly the wrong way to hire the right people. Most good interviewers will be much more interested in your potential team and cultural fit, your ability to problem solve, your confidence and personality type much more than whether or not you can answer specific technical questions in an interview situation.

    Something to think about.

  26. Kepa
    Permalink to comment#

    “superstar front-end engineer”

    Please, learn what an actual Engineer is so that you do not misuse the term.

  27. Jeremy
    Permalink to comment#

    A comment about the ‘inline vs. block’ question. When I was a hiring manager I used to ask this question a lot, and I hate to break it to you but a lot of people with CSS experience on their C.V. didn’t know the answer. In addition to being a weeder question for phone screens it interesting how a candidate answers this question. Of the dozens of candidates I talked to only one described details about padding, width, etc. when comparing the two. Sometimes it’s more about how you answer than what you answer.

  28. Mo
    Permalink to comment#

    Overall, I had a similar experience in the Southeast. One company in particular asked similar questions (it was for “Front-end Developer) and at the end of the interview, I felt like I was being asked to do both front-end and back-end. No problem there, but alas the company did not take me on in the role and chose someone else. A few months later, it seems they are hiring the same position again and has repeated three times thus far (with no sign of expanding hiring in other areas). Maybe I should e-mail their HR person this article…

    • mmcgu1966
      Permalink to comment#

      Im with Mo, Im currently working for a client that has spend entire days inserting in-line css just to make an inline element look block, or vice-versi. When I explained the difference, she realized that front-end work WAS something different and specialized.

      In general, I think that this topic is a perfect launch-pad for that other dreaded interview question: “Do you have any questions for US?”. That’s the time to pin them down on whether they’re ACTUALLY hiring a front-end developer, a web-designer, or a middle-tier developer and when you help them understand the difference. Typically, I run into interviewers that either want to see more back-end than front-end code, or they want to see pretty pictures of web pages that could easily have been made by monkeys.

  29. noone
    Permalink to comment#

    I think you were just unlucky. I have been asked all of the questions you expected to be asked for such positions before, but it depends on the interviewer. This is typical nonsensical interviewing. Unfortunately, being asked specific CSS and HTML questions like the ones you list out is about as useful / useless as the general comp sci questions you got.

  30. Permalink to comment#

    This is an acute problem in our industry. Being a front-end engineer myself, I have seen this problem a lot and can sympathize with how frustrating it can feel sometimes.

    But the onus is on us, people who love FE challenges and know its intricacies to fix the cultural problem. I try to do my part by asking only front-end engineering questions, things like : closures, callback hell, promises, async/sync, distributed XHR calls, HTTP, MVC in JavaScript, cross domain scripting etc. As far as testing the algorithmic bend goes, there are plenty of fun problems like writing a tic-tac-toe game etc.

    I don’t tend to ask too many CSS questions as I strongly feel JS is where the heart of front-end engineering lies. I try my best to make sure that the candidate interviewing for a FE role doesn’t feel for a single moment that the questions are not related to the role. I have struggled too much with that annoyance in my own career.

    In my experience, big companies struggle to take contextual FE interviews. However, there are a few startups that understand a FE role very well and you’ll walk out happy regardless if you cleared the interview or not.

  31. Permalink to comment#

    I’ve had the exact same experience. I never get asked any actual Front End specific questions, although I seem to land jobs ok. I don’t have a background in CS and I don’t know many if any FE developers that do. I wrote an article on what I think is the unique combination of events and skills it takes to become a front end developer today,

    I’ve been asked a whole slew of algorithm questions in interviews which aren’t relevant in what I do. They are more suited to a game developer.

  32. Permalink to comment#

    I also went through the same kind of experience a couple of months ago trying to land a job in a huge company in Seattle. Even if it was more like back-end software development position in all my 10+ years of business software development I never had a chance to deal with actual algorithms. Nobody does these days. So of course, theoretically one needs to know the big O number of various algorithms, but asking to implement them on an over-the-seas phone interview, I think it’s a bit too much.

    The thing is they are looking for problem solving type of guys and that’s great, but what kind of problem can you squeeze in a 40 minute interview? A tiny one which is not relevant to experience of a candidate, or a standard one which is implementing an algorithm.

    So, I suggest to anyone who is going to have an interview in a huge tech company these days, just learn this stuff by heart, there are plenty of material can be found on the Internet. Dedicate 3 to 5 days to implementing them in your language of choice and it will be a great boon for you on your interview. Once you are through with it you can safely forget all about it.

    This whole algorithm thing is not that hard, just unexpected. But reality is reality and one needs to adjust.
    Anyway I am going to try again in a month or so :)

  33. Do you really think people have time to give interviews in fast moving Silicon Valley companies? I rarely did. Most are scheduled last minute to staff from the hiring manager a day or two before. Very few engineers are going to go out of there way to come up with questions targeted for each job description in the team. On large teams with many roles, its just not practical when you are in the middle of a project due last week…. All people are looking for is to see if you believe in the mission of the company, excited about the job, can fit in well with the team, work hard, can think on your toes, and not need a lot of hand holding to do your job. Every Silicon Valley company has a culture. Interviewing here is an opportunity to get to know you, what you are capable of, not necessarily what you know. For if you know everything, your applying for the wrong job and should be running your own entrepreneurial endeavor instead.

    • MM

      What a silly, pompous response. Your company’s culture was backwards if they didn’t care enough about their product or their interviews to ensure that the proper questions were asked so as not to hire someone who would inevitably fail.

      If a company is looking for someone that cares about the mission statement, they can weed out applicants by the effort they put into their cover letters or the experience they have on their resumes. If a company is looking for someone to fit the culture, they can have a sit-down with them at a coffee shop for 30+ minutes. If a company wants to know what someone is capable of, it’s a short glance at their code repository or portfolio.

      An interview is not a meet-and-greet. It is a place to ask and task the candidate with questions and puzzles that are directly in line with whatever the role may be. It doesn’t take two days to get together with your existing team and say “Okay, what are the types of things we do regularly that will be vital for this person to know?” You can figure it out over lunch.

  34. Permalink to comment#

    If only someone really promienent in the Front End Developer scene would create a github repo of good interview questions…
    Oh Wait: “Front-end Job Interview Questions“, 61 contributors including Paul Irish?

    Now to fax this to Silicon Valley…

  35. Permalink to comment#

    Some disagreement here.

    I feel core product development companies like Amazon, Google, VMware, etc. do the right thing by asking DS algo, puzzles and not the frontend.
    I have given some 30+ interviews for top-notch companies in India, and am working in Amazon as a Web Dev.

    The idea is they want to hire intelligent (and not just knowledgeable) people. And so, the pay scale is incredibly high.

    Looking at your jQuery analogy, its very simple to learn and apply. There is not much intelligence involved in finding out how jQuery chaining works, and why the “#nav a” selector is a slow selector.

    But I definitely agree on the calendar widget part.
    I was once asked to build a Picture puzzle game in the frontend with CSS positioning.

    But things like best practices in JavaScript, cutting edge HTML5 features, CSS techniques, etc. can be found w/o much efforts & are simple to understand & use.
    It then becomes a matter of being active and following right people on the internet. This is unfair unless you know something really very rare, that is not known to other devs.

    Why then a company like Google should pay so high, as high as $150,000 & more for an engineer like me? (I am not getting that much !!)
    Why not write a book with all web content which has jQuery/JavaScript/CSS/AMD/MVC/MVVM
    /HTML5/WebRTC/SinglePage/ResponsiveDesign, and every content available over internet, starting from $100.

    Google employed fresh grads on AngularJS development.
    VMware asked me to implement sleep in JavaScript.
    Amazon asked me to create a JS class for implementing a linked list,
    also, a promise based interface to parse CSS properties of nested DOM elements.

    And I think its perfectly logical. Only exception being I really feel very angry if an interviewer is belittling me just for an algorithm, where he isn’t qualified even close to my frontend skills. Feels like a kid is trying to irritate me.

    Your points are valid for only such companies or Web Dev agencies, who do not actually do such work, and want to hire people on the basis of some skills completely different from what they would actually work on.

    Or may be for startups, who are just creating a team. Since the founders, VPs, etc. of such companies are themselves previous R&D or Research guys, they want to make sure that the person leading a team is intelligent.
    In such a case, they simply believe that your Frontend/UI and backend skills are good, and you only need to prove that you are intelligent

    I personally know of a C++ developer with nothing to do in JavaScript, who within a week was forced to learn new Canvas APIs created an HTML5 Image transformation app now being used at Amazon, to apply filters, remove background, etc. which you can see if you are a seller at Amazon and uploading a product with images.

    The guy wrote all algorithms in JS, using the HTML5 Canvas APIs. And so, Amazon ditched Aviary image suit, since now we had our own Single page app.

    • script god
      Permalink to comment#

      hey, I am really sorry to know that the other C++ guy did the work which you were designated for.
      after all he is a back-end developer and he did a really good job doing front-end work that too in a week. He must be quiet a talented person to grasp a different technology other than his domain.
      It hurts more when you are a self centered person who keeps saying ‘google asks me’ ‘Amazon asks me’.

      I believe front-end now isnt limited to just designing mockups and converting them to html.

      The browser is now capable of performing heavy logical tasks so the need to distinguish between Front-end developers and Front-end designers.

      Let the developer do all the logical thinking like playing with data and stuff, and let the designer focus on css and html and looks of an app.

      So I believe the developer should be asked all the logical reasoning stuff and the designer about html , css , photoshop etc.

      The questions do really matter for what post a person applies for.

      After all you dont want a person who is a Jack of all trades but master of none.

  36. Risto
    Permalink to comment#


    The set of questions that you specified and the companies did not asked are questions for testing your knowledge in some area and all of them can be answered in simple Google search and learned very fast.
    The set of question that the companies asked you is not for testing your knowledge, but your logic and how you solve problems when faced and that cannot be learned. It is a long process to shape your mind to engineering mind.
    The second ones are far more valuable than the first ones, because if you can answer them, then you can easily and fast learn the first ones.

    Best regards,

  37. Permalink to comment#

    Awesome article. Im in a different part of the world from where you are, but what you have mentioned is exactly what happens over here too with regards to the questions asked. One ought to think its bit stupid to just go about an interview with no relevant questions, and more often, people who are far greater front-end developers get dropped to hire people who has the coding basics but do not have good knowledge for the particular post. The main reason, i felt however is that the senior people who are in the firm do not have much knowledge regarding front-end development(basically since its pretty new and extremely vast) and hence they end up asking questions regarding basics or what they know of.

    The no of questions which summed up to 1(CSS), actually validates this view. I really really hope this blog article gets featured in some technology blogs as well, where there ought to be some corporate response.

    p.s : Congratulations on taking up the job on google. I can only imagine how awesome it is over there. Hopefully in a few years, i apply and get a callback, who knows it might be you who takes up the technical round..:). All the best once again Philip. Awesome article and appreciate Chris for sharing this over here.



  38. John Hunt
    Permalink to comment#

    Nice article, thanks for writing this!

  39. What makes this so wild to me are these:

    • Write a function that takes two sorted lists of numbers and merges them into a single sorted list.
    • Given an array of integers (positive or negative) find the sub-array with the largest sum.
    • Determine if a given string is a palindrome.
    • Given a large hash table whose keys are movie names and whose values are a list of actors in those movies, write a function to determine the Bacon number of a particular actor.

    I would absolutely fail at all four of these things, if asked to do it on-the-fly in an interview.

    In “real life” – I could probably figure them all out, but slowly. I’d Google stuff. I’d gather a strong understanding of why I was doing it, which would provide the motivation to get it done. I’d write up a way to do it that would just be me slowly reasoning through it, then bring it to some one smarter at these kind of things and explain it to them and how I went about it so when they can help me make it better, I’ll be able to understand what they are doing.

    Does that make me a crappy computer scientist? Perhaps. I get that those things should be easy-cheesy for the hardcore programmer type. Does that make me a crappy front end engineer? I don’t think so. I’ve worked as a front end engineer on quite a few websites and I feel like I’m pretty decent at it. I think I’d be pretty useful on just about any front end team out there. Yet, I might not make it past the first round of interviews at a lot of companies specifically hiring for that. I’m sure I’m not alone here, so how many good front end folks are getting left out of jobs they would be good at?

    • Chris, its not about if you get the answer to a tough question right or wrong in an interview. Its more about the tenacity in how one goes about attempting to solve it.

      On the job, people find solutions in different ways. Some through research, through Internet, getting feedback from others, or by just outright having the experience to know. Google is everybodys resource nowdays.

      Interviews are about watching the interviewer struggle in the face of adversity. To observe how they overcome challenges, even if they need guidance. And when guidance is given, if they learned and to add more to the solution.

      Im more interested in observing if the individual gave up… hire those with tenacity, who stick with it, ask questions. Give easy questions to make candidate feel comfortable. Then harder questions to see performance under a challenging situation. I didnt care if you got the harder questions right or wrong. I cared about the effort the candidate gave to leave me an impression to compare against the other candidates.

      Its not about knowing everything, its about the true grit of the candidate when faced with tough challenges. In Sf bay area/ silicon valley the atmosphere is very entrepreneurial. It always has been about delivering new ideas, not old ones.

    • Camaron
      Permalink to comment#

      Chris I agree… I had to look up the word palindrome….. But once I saw what it meant I thought how I could get the answer. (My head is full of code not a dictionary of words). i think companies focus on terminology way to closely, and depend on you to know every term off the cuff. Which is not a reality in my book. But i can be wrong of course..

    • Chris: how many times have you dealt with data structures, algorithms and O-notation in the things you build? Probably not much…because you are a UX/UI-first developer (and so am I).

      Many in hiring positions are actually looking for “Software Engineers” who know JavaScript the language — and this is what they call “Front-End Engineers”. NOT those who know new HTML APIs, CSS/RWD, etc and build traditional web applications.

      I’ve worked as a front end engineer on quite a few websites and I feel like I’m pretty decent at it.

      Me too… but the reality here is what Google or similar companies hiring/interview process for the title of “front-end engineer” and their hiring managers are bent towards python/Java/server-side developers with a CS-background who learned JavaScript the language along the way — even if a UX/UI-centric developer like you and me would do well (and have) in the position.

      Either way, perhaps I’m just not sure how important the role of traditional CS data structures and algorithms is in front-end engineering — it seems that is the primary knowledge they are looking for in the above interview questions (and has been my experience as well talking with these companies and their needs). Perhaps this warrants a larger discussion…calling in nicholas zakas!

    • I’m a huge fan of ‘take-home tests’, especially before a face-to-face interview, where you’re asked to code something from a mockup/PSD and some sort of functional spec. That way they get a lot of the technical skills stuff out of the way and the in-person meeting is more about personality, culture-fit and getting questions answered. Also, it allows the developer to shine in a similar way to how they would perform working at the company, instead of being stressed out by the immediacy of the situation (and without proper resources — no one knows everything).

      The caveat to it is that the candidate may have other pressing things going on, so there needs to be communication if there is a delay in returning the coding exercise. The longer I do this stuff, the more I wonder why I’m not a part-time recruiter, haha. :P

    • Chris & Phillip are 100% right. There is way too much emphasis on academic intelligence (regurgitation of information based on academic learning & experience) rather than what I’d call common sense (application of experience and ingenuity).

      Almost NO ONE interviews people for the latter, like Phillip said, they want you to solve ridiculously inappropriate logic puzzles or explain algorithms that made me want to commit seppuku.

      I’ve only been a web dev for 3 years – 2 freelance, 1 full time. Last year I spent 3/ 4 months looking for my first full time job (in and around London) as a “Front-End developer”, and more than 75% of the questions I was asked were completely irrelevant to what I would be doing! That’s not an exaggeration, I applied for a lot of jobs, I can’t remember how many, but it was infuriating and extremely testing of my patience!

      It was only until I found a job for a front end dev at a non-tech company, where I had a great interview that really tested my common sense, experience and knowledge. It was only the 2nd actual face to face interview I had, and I got offered the job later that day.

      It’s sad to hear to a majority of the big companies over in SF/ california etc are the same. It’s a waste of potential. I’d rather employ 100 guys/ girls who are smart, have common sense and experience over 1000 of the brightest academic brainless zombies who conform to everything they’re told to every day of the week.

    • First, great article by the OP!

      @Chris, it’s great that you chimed in here about the disconnect between front end dev /UI UX design, and computer science. I recently did an online skills test for UI UX Front end development, and the very first test was the palindrome challenge.

      In my years of experience, I have never, ever needed to deal with palindromes. I did come up with a solution on the spot, and proved my CS and logic skills, though that’s not the point. For the position I applied, I’m not going to be sifting through data in that way to analyze and compare it. You want to analyze something? Give me a question about how I would analyze a traffic funnel in Google Analytics in order to find why X-bounce rate is abnormally high.

      As another example, I need to manipulate the DOM all the time, and not a single test question even remotely touched on that. No append childs, no CSS manipulation with jQuery, nada.

      In short, I’ll be brave and raise my hand at your question “how many good front end folks are getting left out of jobs they would be good at?” and reply “I’m one of them”.

      Thank you OP for the great article, and thank you Chris for all the work you do.

    • Rylie
      Permalink to comment#

      Its more about the tenacity in how one goes about attempting to solve it.

      Kerry Kobashi – First of all, tenacity is not how one goes about attempting to solve a problem. Tenacity is the quality that drives you to continue to go after something (a solution in this case) even when no one is watching or waiting for the result. I agree that it’s not all just about getting the right answers in an interview, but I don’t think you can interview for tenacity by giving someone 4 hard problems to solve in front of you. If I didn’t get something right in an interview, I would go home and try to solve it anyway even if it didn’t count anymore. Tenacity is a quality observed over time, the kind of time you don’t have in an interview. Does not giving up for half an hour constitute tenacity, or is it an hour or 2? Will the interviewer stick with you for 2 hours while you continue not giving up? If faced with similar problems at work, I would not give up until I solved the problems (on my own or with some help), but an interviewer would not be able to observe this about me in an interview setting. You can, however, observe how someone thinks and reasons about things for themselves in an interview, but that’s not tenacity. So if tenacity is what you’re hiring for, a single interview is not gonna give you the information you need to decide whether the candidate has it or not, in my opinion.

  40. Permalink to comment#

    Chris, don’t you think that “Google stuff, gather strong understanding, etc.” which you would do for those 4 things, can also be done by the Computer Scientists for HTML, CSS and JavaScript.

    As I said, my friend at Amazon who was a C++ developer, googled things and build an HTML5 based Image editor, in just a week.

    Amazon was a customer of Aviary. Now no more, because the guy wrote all algorithms and built an awesome product that does most of the things, all Canvas transforms, filters, etc. Amazon uses that for sellers who upload images for their products.

    I agree that the app does not appeal visually, but then when Amazon wants to hire someone for making this product a visually appealing single page app, may he/she be a front end dev, Amazon will make sure that the candidate can understand & extend those algorithms.

    This is justified for all product companies.

    • I 100% agree that companies who are building apps (instead of sites) have a much greater need to hire people with a strong programming foundation.

      However, my point is that no amount of brain power is a substitute for front-end experience, especially since so much of the technology on the front end doesn’t play by the rules of logic (e.g. browser incompatibilities, inconsistent specs, etc.)

      Let me give you an example:

      A few months ago, while I was on vacation, QA found a bug in our app on iOS Safari only. The bug was that when the side navigation drawer was expanded, the users could drag the drawer closed without actually closing the drawer (i.e., without changing the internally stored state).

      Anyway, one of the smartest guys at my company started working on this bug. As far as he could tell, the problem was that the user could drag horizontally, so he decided to disable horizontal dragging when the drawer was open. He wasn’t super familiar with touch events, so he did a bunch of research and wrote a hundred lines of code or so to detect the drag event (in the horizontal direction only) and prevent default in that case.

      He checked in the code, and it worked. It was a bit clunky, but it was good enough for QA to resolve the bug.

      Then I came back from vacation, took one look at the bug, and was like: “oh, I bet overflow-x: hidden is missing on <body>“. Sure enough, the fix was as simple as that.

      The thing is, this developer is a lot smarter than I am, and he’s a better programmer, but my solution was the right one, and the reason is because I had the front-end experience to know what technology to use.

    • Duncan
      Permalink to comment#

      I don’t think that there is any doubt that a great developer can create great applications, but (anecdotally) haven’t we seen great developers lost without bootstrap or some kind of front end framework, creating really inflexible front end code that doesn’t respond well through a range of device sizes, and breaks with the slightest change?

      Front end development, where it overlaps with UX and information architecture, is a very different beast from where it overlaps with program logic and back end structures. I think the main takeaway of the article and most of these comments is not “These companies don’t know how to interview a front end developer” but “these companies might not end up hiring the best front end developer”. That is, if they don’t ask the right questions (and as I said before, I maintain that a front end developer’s workflow ad process is far more valuable to examine than their retained knowledge).

  41. mmcgu1966
    Permalink to comment#

    Chris, I just realized that this forum could really use a ‘like’ button, or something like stack overflow’s rating system.

  42. Fascinating article. Anyone interview at SF companies like this for ‘Front End Development’? Where do front end developers who migrate from design fit? Or do the googles dismiss non-CS degreed candidates?

  43. Permalink to comment#

    I had an interview with Microsoft and I was asked to sort an array of bytes on one pass through in real time. It was for a front-end position. After the fact I realized it required a hash map or something like that. I was coding in JavaScript in the online environment we shared for the interview.

    A lot of positions I am seeing online in my job search want 4+ years experience in Java or C# with HTML/CSS/JavaScript skills being listed as a plus!

  44. Brenton Thomas
    Permalink to comment#

    After three decades in this game I have found it is the same as music. Its not what they do 9 to 5, its what they do to wind down.

    So do you hire the musician or sound engineer etc that knocks off from writing ad jingles to play in a band. Or do you hire the guys who plays music 9 to 5 and goes home to do something.

    Same with code – Do you hire the code cutter who does it 9 to 5 or do you hire the guy who is going to cut code whether you hire him or not whether he has a job or not because – well just because.

    You can learn code, but you can’t learn passion – and the passionate it will always learn the code better.

    • Some of the best front-end guys/gals I know call it a day after leaving work, unless working on freelance stuff at home. IMHO, I don’t think passion is defined by the hours you keep, it’s more of how you feel when you’re doing it.

  45. Permalink to comment#

    Weird to ask those questions for a front end specific role.

    Part of the challenge is that the role of a front end developer, or for that matter any web dev role has a wide ranging definition.

    Back in the day, front end dev meant HTML/CSS skinning and knowing browser rendering rules. Now there’s more emphasis on JS and building Single Page Apps where knowledge in typical programming/logic problems is more relevant.

    • No, the really “back in the day” was when Design, HTML and CSS meant: Web Designer, and PHP, Java, ASP, Python, Perl, JavaScript [insert other programming languaged here] meant: Web Developer.


  46. Permalink to comment#

    @Philip, I agree. I have seen more funny cases where developers have come out with long coding lines solving a simple problem, which could have been solved using a single line of JavaScript, sometimes just by re-arranging the HTML elements.

    It therefore turns out that experience working on Frontend cannot be compensated with intelligence and contemporary hard-work.

    But, experience cannot compensate foundational intelligence as well. The perfect blend would therefore be, a developer who is intelligent as well as has kept up his hard work and interest in Web & frontend. And I believe, most FE developers who are good, fall into this category.

    If a guy asks me binary tree or finding middle element in a linked list in JAVA, for a Frontend position, I should definitely splash coffee on his face. But if a guy asks me to build an Excel like application in the browser, I find that interesting.

    Also, some brain twisting puzzles tickle me.

    And most companies who are good, know this thing. I have given FE interviews at both Atlassian and VMware, and was surprised to see that they identified me anti-JAVA, and were very specific about my FE skills, even though the product was completely in JAVA.

    They literally drilled down on Prototypal inheritance, AJAX, CSS positioning, layout, etc. Also made me to write JS memoize function, unique function, call & apply tricks, and so on.
    One of the questions was the requestAnimationFrame – passing a JS callback when CSS transition ended, that I was surprised to be asked.

  47. Permalink to comment#

    The plight of the companies lacking good FE developers is also true.

    I am a frontend dev at core. And I would never work for a company who says “Frontend dev with background on Java“, even though my background was Java. Coz I know tht such companies do not have any way to identify intelligence of an FED or appreciate his experience, other than asking Java questions, or lame FE questions.

    Sometimes I have literally laughed right in the interview at stupid Frontend questions by Java guys, claiming to be good FEDs. I got the “candidate is too aggressive” feedback :). Most of the times I tried to prove them that how pitiful their knowledge is on the Client Side.

    One of the guys thought that .ajax() is a native JavaScript function.

    After a long debate, I finally told him – sir you need to go back and check both jQuery and normal JavaScript. He took it hard and complained about me !!

  48. Kiran
    Permalink to comment#

    Good one

  49. Camaron
    Permalink to comment#

    This was a great article with some insight on how companies are weeding out great developers. I at one point interviewed for a position at a company doing SQL code writing and mostly basic database development. At my interview I was asked questions about my military record, where I served, how long I served, who my favorite actor was, etc etc… The only question I was asked that was even slightly technical was what bevel meant… I hadn’t realized that at the time I had sent my creative resume to them instead of my developer resume. I was completely offset because I knew the answer but my mind had been focused on other parts of the interview that I wasnt thinking about 3d development and or graphics design.. I was embarrassed because I couldn’t give a clear description… Even though I have used the tool hundreds of times and can tell you the hotkeys to access it.. Interviewers have a way of imbalancing you to see how you act under pressure… Lesson learned. For me.

  50. Permalink to comment#

    YES YES YES.. This article is exactly what I have been going thru, verbatim.
    People ask why is it so hard to get jobs doing what I do. THIS is why. We have all this great talent and great companies but there is a disconnect. Thats why I went independent for so many years. So this just proves that its not WHAT you know but WHO you know. Thanks for writing this. I couldn’t have said it better myself.

  51. Permalink to comment#

    Very insightful write up. Kind of scary- I would think that when you get interviewed at a company like the ones you describe they would ask more specific questions. I guess they just assume that if you have the logical / problem solving skills than they can teach you the rest.

    Thanks for the post, Philip!

  52. Jeff Ratcliff
    Permalink to comment#

    I understand the tenacity argument, but the problem is that real-world tenacity isn’t measured by what you do in an hour, it’s often measured in unpaid weekends.

  53. Todd
    Permalink to comment#

    Great article. Sounds like yet another ‘fusion’ of tech positions. I see this more and more with agencies that hire temp and temp to perm, where they ask for a front end web dev that is proficient at C#/VB, Java, JS, jQuery, PowerShell, etc. And it’s an entry-level position, but they want 3-5 years experience.


    And I understand the whole, tenacity and thinking on your feet thing, but there are front end developers that aren’t CS/Math grads that think, sleep and eat FE that have the same drive and desire, that create mind-blowing stuff all day, every day, too. Liike the guy that runs this site, Paul Irish, Nick Gallagher, etc.

  54. Ramesh Chowdarapally
    Permalink to comment#

    Simply great article. Of course simple questions can brings the real talent.

  55. I usually run the front end interviews in my company and I’m following your logic – if you want a front-end engineer – ask front-end questions. Depending on the position the person is interviewed for I have a wiki page with all sorts of questions – basic, advanced and senior level. I start with the easy ones just to “probe” the candidate and then move on. Most of the time I don’t really need my list and ask questions depending on the answers of the potential colleague. My favourite question is: “If you can change one rule in the CSS world, what would it be?” :)

  56. Kaleberg
    Permalink to comment#

    One problem is that the Stanford Mafia are the people who invent things like JQuery, so they tend to ask questions to size up whether you are up to inventing KQuery or whatever the marketing team later decides to call it. Hey, someone has to invent this stuff or we’d all be programming in raw machine code.

    There is something to hiring people who have exactly the right skills for the job. A front end developer who knows HTML and CSS and Javascript inside out can be a treasure, but a lot of high tech companies want people who are jacks of all trades and perhaps masters of one or two. After all, when it comes to computer languages, as Kipling put it, “the Colonel’s Lady an’ Judy O’Grady are sisters under their skins”. The job is to find people who realize this and can work from this viewpoint, even if they have to use some Google fu for the details.

    When I was a programmer, we had all sorts of computer science problems. I can’t remember how many times we ran into performance problems and it took some graph theory or clever rethinking to get things down to O(n log n). Maybe front end developers never run into resource problems, but I’m guessing that one who is aware of what is going on is worth two who are unaware. Even as a retired hobbyist, I’m constantly running into CS problems. There are dozens of languages in use these days, and understanding the relationship between closures and objects and the like sure make it a lot easier to jump from one to another or learn a new one in a reasonable amount of time.

    • Shruts
      Permalink to comment#

      JQuery is created by Rochester Institue of Technology Alumni John Resig. He is not from Stanford. And RIT CS department college doesn’t have any US news ranking too.

  57. Sandeep
    Permalink to comment#

    Nice discussion though…..:)

  58. Jack Scotty
    Permalink to comment#

    To touch on several comments above in just one response…

    I agree with @Michael Whyte some solutions to the logic questions in javascript would be great!
    Here’s my take on “Given an array of integers (positive or negative) find the sub-array with the largest sum.”

    var integerArray = [random array of integers here],
    a, b,
    maxSum = 0,
    maxArray = [];
    for (a = 0; a  maxSum) {
        maxSum = integerArray[a];
      for (b = (a + 1); b  maxSum) {
          maxSum = currentSum;
          from = a;
          to = (b + 1);
    maxArray = (to > integerArray.length) ? integerArray.slice(from) : integerArray.slice(from, to);

    @Henri Helvetica I would also love to here what Philip thinks about Darcy Clarke’s Front End Interview Questions

    Lastly, I second @mmcgu1966 this comment forum could really use a thumbs-up/rating system. Typing out this particular comment/replies wouldn’t have been necessary.

  59. Jack Scotty
    Permalink to comment#

    Errors above… wish I could edit

  60. This was a really good read. I must say, that I am fairly surprised that major “big boy” companies would be asking irrelevant questions like the ones mentioned in the article. As other have mentioned, there seems to be a broad misunderstanding of what “front-end” engineering entails. If someone successfully answers a bubble sorting algorithm problem, that does not mean they would qualify as a good front-end engineer. It would be better if the employer asks the front-end interviewee about how they typically solve problems between browsers, ask them about their build workflows ( like GruntJS), or have them talk about what frameworks/libraries they use, and ask them why they are useful.

    And yes, another front-end engineer should be asking questions during the interview.

  61. Permalink to comment#

    To the reverse, a few large companies, including ones in the Bay Area, have been looking for a jack of all trades or just don’t even understand the scope implied by the title.

    Whatever happened to “middleware”? Man, these days I am writing my own web services and fighting to justify MVC so I don’t have to do everything with JS and HTML, even at large enterprises. I do WAYYYY TOO MUCH Java these days.

  62. VS
    Permalink to comment#

    This is exactly what I am feeling right now.

    I recently made the move from Creative Department – Graphic Designer to Engineer – Front End Developer in my company. I made the move because I was asked by one of the Execs if I was interested for a front end dev position because they don’t want to hire out. I thought it would benefit my career by being next to other front end devs. I was hoping I would be able to learn javascript. I know that I am decent with HTML, CSS, and know basic jQuery. So I took the chance, made the move with high hopes that ill become an awesome front end. However, I feel completely lost in the department among my peers. My first week, one of the upper management of the Engineer department said that I should learn C#, ASP.NET because we don’t have enough HTML, CSS work here. A few weeks in and I still feel very unproductive. I don’t know any of the terms that they use. I don’t have a CS degree like everyone here in the engineer dept, I’ve learned the web from friends and blogs like this one. I am thinking about moving back to Creative Dept. What do you guys think?

    • Based on your side of the story it’s clear you were mislead.

      A Front End Developer has nothing to do (not necessarily at least) with C#, ASP.NET or any other Back End programming languages. They want you to become a Back End Developer, but they masked the whole thing telling you Front End Dev.

      The person that told you that there isn’t enough HTML, CSS work there is because he certainly has no damn clue (sorry for my Spanish) what’s going on. I bet that person doesn’t really know much about HTML and CSS in the first place. Just stay away from people like that, they’re not worth any effort from your part.

      Now, when you say “move back” to the Creative Dept., I personally don’t see it as “moving back”. I see it as “focusing” your energies in what the Creative Dept. does and how you can add more value… and maybe have others appreciate that value you bring, since, well, the “Engineering” Dept. didn’t.

      The question for you here is: After this experience, do you think is still worth staying there since you already know there’s no chance of growing in the Front End Field?

  63. Many companies prefer to hire people right out of school for several reasons:

    1) They want to indoctrinate them into their corporate culture/best practices
    2) They are less expensive to employ – not just because of salary, but other costs like health insurance.
    3) They want work to be the center of your life.

    If you are 40 with 2 kids, you are much more likely to have other priorities, as well as a perspective that the world will not end if something is not done RIGHT NOW!

    I worked in silicon valley for 20 years. I’ve worked at large companies and start-ups. I have an EE degree – the web didn’t exist when I was in school – so I never had to develop algorithms. But I have been an information architect/UI designer/front end developer/requirements analyst/project manager/QA engineer.

    I’ve always been able to figure out what needed to be done, how to get it done and learned from my mistakes. I have a great work ethic. – and I’m a damned good front-end developer.

    But IF my resume got past the software that filters out non-CS degrees, and IF I could manage to hide the fact that I’m not under 30, I wouldn’t get past the first interview if they asked me to write a function to merge two sorted lists into one. I may have needed to do that using Fortran in CS101, but not since.

    But life IS too short. I’d rather not have to work with a bunch of arrogant Stanford grads anyway. :^)

  64. NiM
    Permalink to comment#

    One of the most interesting articles/comment threads i’ve had the pleasure to read in quite a while. Kudos to all of the above :)

  65. Good article. Found some interesting thoughts from the recruiting side that might be of interest here: interview with Laszlo Bock at Google
    Not specifically front-end related, but anyway.

  66. Mohannad Khasawneh
    Permalink to comment#

    Very insightful :)

    I couldn’t agree more on this

    “good front-end engineers tend to be very self-motivated. Since browser technologies aren’t usually taught in schools, most front-end engineers learned this stuff on their own”


  67. Shruts
    Permalink to comment#

    I do agree with Philips. Why DS and algorithms is asked in front end interview questions. Even I have been interviewed by Bay Area companies and faced with DS and algorithm questions. Once the interview gets over I do question them “Where in the front end do they use DS or Algo in their firm ?” or “As a developer to developer have used it anywhere in front end development”, after their reply my following question is “than why do you people ask Algo’s question?”. To that the most common reply is “you are master’s student you should know this?”. The only company that didn’t bother to ask me DS and Algo’s is LinkedIn. The whole interview process was on HTML5, javascript and CSS3. Mostly their questions ranged from loop optimization, data-attributes, event listener in short optimization and downloading of website on browser. The interview process really changed my perspective of LinkedIn and I have started to have more respect for them than Amazon, than Google. Now I can understand why Amazon sucks in their UI. CSS3 and HTML5 have developed so much in the coming year that you can actually ask tricky questions in them. That may reduce loading time too.

  68. Answered on this on StackOverflow :

    Here it is, line by line:

    ("#nav a") – finding matched elements is O(N) task in general. Consider that #nav is assigned to the body element and all you have in your document are <a>s. You need to scan all of them against “a” selector.

    .addClass("link") – that’s O(n) task for just to walk through the list. But it has hidden cost – by changing class of element you are asking browser to recalculate style of the element and all its descendants. So in worst case all DOM elements will be affected. Considering that cost of style recalculation is O(N*S) task (N – number of DOM elements,S – number of style rules in all style sheets) then total price will be O(N*S).

    .attr("data-initialized", true) – that in principle has the same price as above.

    .on("click", doSomething) – that is O(n) task (n – number elements in the set) + it has a cost of allocating memory for event binding structures. Each element in the set will have new binding and so additional memory allocated.

    So overall answer is O(N*S) for computational complexity and M(N) for memory consumption.

    UAs usually do some optimizations but worst case mandated by CSS selector structure is like that.

  69. Rylie
    Permalink to comment#

    Instead of asking someone to write a function that adds two dates, have them build a simple calendar widget to go along with it.

    Add 2 dates? Hmm. What does it even mean to add 2 dates (Jan 11 + July 4)? I can see why you would subtract one date from another, or add x days to a date, but for what purpose would you add 2 dates?! What am I missing?

    And then, build a “simple” calendar widget to go along with, what, the sum of 2 dates? Huh? I’m still trying to figure out what the sum of 2 dates represents, now I gotta write a calendar “widget” to go along with it?

    Also, the term “widget” is so overloaded. Do you mean a generic widget, or a jQuery UI widget, or a WordPress widget, or something else? I may have to know an API depending on what you mean by “widget”. And is there really time in an interview to write a calendar “widget” from scratch (when you’re already nervous to begin with), now you gotta do the math to figure out leap years (years divisible by 4 but not 400) and daylight savings time (taking into account locales where there is no daylight saving, e.g.), etc. plus styling the table in which to place the calendar data?

    I agree that interview questions should be tailored to the job position, but I don’t necessarily agree that your replacement questions (at least 2 of them) are any more useful. The one above makes no sense to me. And the jquery complexity question- for me anyway, I think it would be easier to talk about the complexity (Big O) of a merge sort than your jquery expression. At least, a merge sort is a well known algorithm. How many people know what algorithm was used to evaluate a jquery expression. You’d have to dig into the jquery source and count the possible “steps” it would take to evaluate a particular expression as the markup got infinitely large, represent that in an equation, and then apply Big O to that equation. Or maybe I’m just not understanding the question.

  70. Em
    Permalink to comment#

    Does anyone know where I can find front-end developers for a permanent and full-time salaried position in Ontario Canada?

  71. This is so true. I think interviewers are more keen to highlight their own knowledge (even if they dont have) in front of the candidate instead of knowing about candidate’s knowledge.

  72. Gene Kim

    wow…glad to see that I am not the only one experiencing the perplexing tech interviews for Front End Dev positions. I too come from design and have been at it for over 14 years. I know what I know and am intrigued by new technologies. I have found it difficult to find a group where I am not the lone Front End Dev with either a back room full of Java engineers or an office of mediocre managers and me developing by committee…sheesh. Most of all I find that I do not know anyone that talks in terms that are brought up in these interviews. I simply tell the interviewer that I don’t geek that way and those that do…I probably wouldn’t hang out with them anyway. Still, the challenge is real and pressing on me to learn more and adapt to the changing requirements. I feel that I will have to do it on my own terms which still might not be understood by the pompous proud. In closing I choose to quote one of the greats:

    “I hate to advocate drugs, alcohol, violence, or insanity to anyone, but they’ve always worked for me.”

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".