The State of FE Interviews

Nicholas recently wrote a piece about the rise of the front end engineer (FE) as a legitimate engineering discipline in the age of the Internet. It’s a fascinating read, and I highly recommend anyone working with FE engineers to read both that article as well as his other post on working with software engineers. He briefly touches on some of the frustrations FEs deal with as they try to break into an industry driven by technical brilliance, but I feel that’s just the tip of the iceberg.

I recently went through a number of interviews at numerous companies around the valley, and one of the most frequently asked questions from both recruiters and prospective employers was “Why have you stayed at Yahoo so long?”. It’s a pointed question, and it was usually asked with a sense of both curiosity and incredulity. It’s easy to see why outsiders would have such an impression. Yahoo is consistently painted in a negative light to serve as an omen to other tech giants in the valley, as if to say “hey, this is what happens when you become complacent!”

My answer to the recruiter’s question was simple: talent. Because of the way Yahoo embraced FE as a rigorous discipline nearly 10 years ago, it became a breeding ground for the best FE talent in the valley. I don’t think I need to repeat what Nicholas said, but the huge amount of FE talent that was unearthed from within the depths of Yahoo is unequaled. Even as these pioneers left the nest, an incredible plethora of knowledge was passed on and retained, allowing Yahoo to become a haven of learning for the FE discipline. The fact that I was hired specifically as part of a special program to groom FE gurus says so much about the kind of culture that Yahoo has fostered.

With the explosion of HTML5/CSS3/JS and its acceptance as the UI stack of the future, I felt that FE had finally reached the grand stage. It seemed like heaven; there were numerous FE opportunities across the the Bay Area, and many companies had disciplined FE organizations due to the influence and migration of ex-Yahoos. Speaking with recruiters was also an empowering feeling! It was as if the industry had finally come to accept FE for what it was – a mix of engineering and creative, all rolled up into one neat package.

However, diving into phone screens and interviews I soon realized this to be only half true. Despite applying for a FE position, with a FE centric resume, I was subject to various questions asking me to demonstrate mastery of algorithms such that I could solve for X in O(n) time. I can appreciate the technical complexity of these types of questions, but I think asking these kinds of questions is extremely problematic. First, as a FE these are not the types of problems I solve on a day to day basis. To ask a FE to solve algorithmic problems is like asking your electrician to be your new personal plumber. Second, the unhealthy focus on technical chops over various other interpersonal skills sidelines a lot of really great candidates. I would much rather work with someone who is an effective team player and communicator, than a hero who is out to prove his technical brilliance. This is not to say there isn’t a bar, but the bar shouldn’t be set only by their technical ability (this however, is the topic of another post altogether…. perhaps we’ll come back to that later).

I’ve heard from many FE engineers that with the exception of the interview process, they have never again worked with algorithms within the scope of their work. So my question to interviewers out there: why is that we vet FE engineers by asking them to write algorithms and optimize database queries? Do we vet back end engineers by asking them to design CSS frameworks and optimize client code? What do we expect to gain from having potential FE candidates solve these types of problems? I understand the need to verify a good foundation of technical skills, but I don’t believe this is the right way.

The only answer that seems reasonable is to assume that “traditional” computer science concepts are still the most important pieces of knowledge an engineer can demonstrate. Even if that means biasing against the entire FE community, who have built their careers on skills learned on the job (or on personal time). I don’t want to call it elitism, but it is my opinion that many other disciplines including UI/UX/Product Development, are all negatively affected by this mindset to some degree. A few years ago Yahoo began an initiative to change this attitude by cooperating with iCarnegie to offer FE courses as part of a proper college curriculum. This would allow both current students as well as working students an unparalleled opportunity to better prepare themselves for a career in web development. It was a great idea, and one I wanted to pitch to my alma mater, UVa. I wrote to both the Dean of the Engineering School as well as residing UVA CS legend Anita Jones, neither of whom bothered to respond to my email. It was rather disappointing, although not entirely unexpected.

In my opinion, the rise of FE as a legitimate discipline means we must also find methods in which to vet FE engineers correctly. The algorithm based interviews are a pointless exercise which results in nothing useful for either side. I would much rather interviewers take a gander at Darcy Clark’s compendium of FE interview questions. It’s far more relevant to a FE engineer’s duties, and also serves as a much better indicator of a candidate’s overall mastery of FE concepts. As a prank, I would love to use this material to interview a BE engineer. Just the thought of a squeamish BE engineer tickles my bones. :)

About these ads

7 responses to “The State of FE Interviews

  1. I have been in the very interesting scenario where the corporate recruiter described a position as more UI design and implementation only to put me through to an interview with a developer intent on testing me on my core Ruby programming proficiencies (of which I have very little by comparison). It was very embarrassing for me and left me wondering if the communication inside the company compromised.

  2. @Rachel: Unfortunately, every web developer has experienced this at some point or another (God knows I’ve been through many of them). I completely agree with you, it is an extremely embarrassing situation, and often leaves the interviewee feeling rather helpless.

    While recruiting takes some of the blame, I feel the problem lies directly with the hiring manager as well as the interviewer. They are the ones putting out the req; they are also the ones conducting the interviews. It is in their best interest to conduct relevant interviews, but I would posit that until a change in interviewing culture can be effected, we are unlikely to see any improvements.

    Some companies are slowly coming around, but the vast majority are still stuck in textbook mode.

  3. I find myself torn on this stuff. On the one hand I hear what you’re saying, that FE work rarely requires “pure” CS stuff like implementing search and sort algorithms. On the other hand web apps are tending towards greater complexity, and on that basis I think there is great validity to knowing performance characteristics of various solutions.

    I myself did a CS degree but worked as an FE for the past 8 years. Time and again I’ve been helped out by my CS training to guess that a solution I’m considering isn’t ideal. But I’ve also learned a ton of things by doing the job; things nobody could’ve told me in a lecture hall.

    For me I would say that the algorithmic questions are good, with the rise of IndexedDB perhaps so are the database query questions. But if they are the sole basis on which a person is hired (or not) then yes I think we would be making a mistake.

    • That’s an interesting point you make about the rise of IndexedDB, Paul. Although I won’t rule it out as becoming a part of the realm of FE developers, who’s to say that instead of pushing FE developers into these BE roles, that database people shouldn’t be pulled back into becoming responsible for it as well?

      I think that’s why it’s at least a little bit important that everyone can go a little ways out of their comfort zone—at least to the point, like you said, where you can understand that your solution isn’t as good as it could be and you can call on someone else to set you back on course (as opposed to doing everything for you).

    • My personal take is that the “pure” CS stuff is a value add. FEs stumble across these types of problems every now and then, so I think it’s fair to expect that they can at least recognize that there’s a problem. I think it’s also fair to expect FEs to think about how to avoid said problems during both design and implementation phases. However, the context in which FEs deal with these performance and complexity issues is almost never the way it’s presented in interviews. To penalize candidates for not being able to answer something in their area of expertise (as indicated by their resume) seems rather silly.

  4. Totally agree. I was doing a phone interview with Amazon and all they asked me about were algorithms and data structures… topics that, as an FE, I had rarely touched on since college. I actually stopped the interviewer about 20-30 minutes in and ended the interview as the job was clearly not a match to any that I had applied to. I didn’t want to waste another 30-40 minutes of both the interviewer’s and my time on a completely incompatible job. Totally blame the Amazon recruiter for that embarrassing experience.

  5. I have just experienced this frustration. I have been a front-end developer for over a decade and have a vast amount of experience building some of the biggest sites on the web, and a portfolio to demonstrate that. Apparently this is not enough for some employers and one insisted that I take one of these tests. As you have described it was completely irrelevant, had nothing to do with my skillset or that which the job was supposed to require. After spending too much time and effort on the first question I did what any of us would actually do in the real world. Rather than sit there trying to recall all the possible ways of manipulating arrays and writing mathematics algorithms I Googled for the best answer, improved it where possible, and in the spirit of full disclosure I then told the recruiter that I had done that, and why I had done it.

    The interviewer then cancelled the scheduled interview.

    His loss, as far as I am concerned. He’ll never hire the right person for the job because he will end up hiring a straight programmer who is good at maths and array manipulation rather than a resourceful one who recognises that doing things properly and efficiently usually means building upon the work of others rather than reinventing the wheel.

    I shall simply refuse to take any more of these tests in future, as asking me to do one simply demonstrates that the recruiter has no appreciation of my skills, me discipline or my value, and is therefore not someone for whom I ever wish to work.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s