We were hiring a non-senior full-stack developer recently and I noticed there were no "frontend" questions on the list, so I added what I thought would be a question that any developer with frontend experience could answer, and would also pave the way for some more interested discussions for an advanced candidate. The question was something to the effect of "In JavaScript, what is the value of 'this' in a method?"
I would have accepted an answer as simple as "The value of 'this' depends on how the method is called" or even "The value of 'this' confuses me because it's often not what I expect."
It was a disaster. We may as well not have asked the question at all. Nobody seemed to even be aware of anything about it.
I've been doing Javascript for a few years and recently answered a few StackOverflow questions. One was regarding "this".If anyone wants to hire my ass feel free to contact me. One of my techniques for learning has been by going on interviews and flopping, then going back and learning all the interview question material on my own time. Wash and repeat.I've been doing this bullshit since the first day I started teaching myself. It all began with an interview that required knowledge of strictly HTML & CSS. Suffice to say after I tried to mimic an unordered list with 12 div blocks I didn't get the gig. Things are better now. I promise! Where am I? Whats this padded wall doing here? !!!!
I found this heartening. I've recently transitioned from Mechanical Engineering to Web Dev and am beginning to interview. Just had my first interview, and I feel like everything discussed made me better.
It only works if you have a shit ton of humility. The problem is there is really no other way I've found to acclimate oneself with the assumptions and culture of the discipline in a manner that is real-world and cuts through the small talk/cruft .
I hate HN. Instead of watching action flicks on flights I now read books picked up from HN threads. I've got Platinum Medallion this year and I'm still behind my reading queue.
Agreed. I cannot recommend that book enough. It's a natural extension of The Good Parts and should be considered required reading (in the same way that Effective Java is for Java developers).
I always include something around `this` behaviour in my interviews if the position is Javascript related. You cannot possibly have a decent experience in JS without have been bit by this.
And I'm always amazed by the amount of developers that just do not understand how it works, and bind every possible methods.
Sorry, but the semantics of "this" in JavaScript are crazy — and I think that's being generous. There are a few common use cases that trip people up, e.g., situations where "this" becomes bound to another object like the global window object, and I'd expect an experienced JavaScript programmer to know those.
It depends on what you mean by "down cold," obviously, but if your standard is "either they have the semantics of the 'this' keyword down cold or they're incompetent" then virtually all JavaScript programmers I know (including myself) are incompetent.
Now, hold on there. These "anyone who" statements chafe me; like the junior dev who exclaimed "anyone who doesn't write unit tests shouldn't call themselves an engineer" in a meeting filled with people 15 years his senior who had collectively shipped far, far more successful software than him, without writing tests.
Several years ago, I led two different front-end web teams at a large, well-known company. I wrote a lot of JavaScript then. In fact, I wrote the core JS framework for one of the apps. I probably understood "this" at that time. I couldn't begin to tell you now, because I've been working on hit iOS games since - probably without knowing a lot of the nuances of Obj-C at times! There was no disaster back then - we shipped high-quality sites on time. There would be no disaster now, because if I went back to JS I'd crack a book.
The most important skills I bring to any project are a lot higher-level than the details of a particular language. I haven't made my career on one language or platform, but dozens of them. For the details, I work with reference material handy. After a month, I probably have a good grasp of whatever I'm working with. A year after that project, I probably don't, but I could bring it back easily.
It's only upon reflecting upon "this" recently that I realized that it is (effectively) a global (thread-local) variable set by the X.Y() syntax. (I mean, I understood to be the case, but I just didn't realize the impliciations for understanding "this".)
The ECMAScript committe are taking steps to make "this" more useful, but the current semantic is so insane that I don't it's particularly surprising that people who aren't language lawyers don't understand it.
(*) Given that Javascript uses a single-threaded model.
Likewise, I ask it also. When someone has spent the last 3 years as a "JavaScript developer" and doesn't have a basic grasp of context in JS, them it's a red flag.
From the top of my head, from someone who currently seeks work as a full stack (Rails) developer:
I would ask if you by "method" mean function defined on an object. If so, this refers to the method's object. If not, this can take on 5 values. In the global scope it is the global object; in a constructor it is the newly created object; in a function (not defined on an object - and also goes for functions defined within methods defined on objects) it is the global object; in a method (defined on object) it is the object, and finally it can be set explicitly with functions like call and apply.
How did I do? (Serious question. I think my answer is good, but I also struggle with a serious form of imposter syndrome.)
Not quite right. :-) JavaScript is not truly OO. You can have a prototype method called from a callback and find that 'this' will not necessarily be the value of the object it was prototyped onto.
It's really tricky, and I often have to .bind functions after I've noticed they're not working.
I've been in this position also. Same question. I also added what the difference between setTimeout() and setInterval() is, and example usages of both. It's incredible that a question where the primary answer is right there in the function names causes such confusion on people that are supposedly "front end engineers with years of experience".
Off course, disaster is an understatement. All three questions where the demise of 100% of our interviewees. We ended up hiring a sql programmer and teaching him what he needed to know.
Heh. The second question makes me feel a lot better about my JS knowledge. I could probably answer what 'this' is when given some code (eg are we inside a class? or a jquery event handler?) but would be hard pressed to discuss it in the abstract... whereas setTimeout and setInterval have specific differences to point to.
I'm curious, should answering this question be expected of a non-senior dev? This kind of knowledge is acquired by running into broken code - that is, by chance. I'd think someone with a couple years experience only could conceivably not, for example, have called a method directly and had this refer to a global object instead. Until then one might just assume Javascript's this works like this in other languages. In fact, that's what I did until your post just made me look it up (though I only code for side projects, not professionally).
I'm also surprised to hear that people learn jQuery and omit Javascript. Personally I resisted using jQuery because I didn't understand what was happening nor would you read the code easily. Plus, it was actually extra work because if you knew another language you could pick up Javascript easily. With only jQuery you are pretty much limited to what's already made for you.
If anyone wants to look at one of my sites, I'd be curious how I stand as a developer.
This kind of knowledge is acquired by reading 'Javascript the Good Parts'. It goes without saying that someone who considers themselves a good frontend engineer has read this book.
edit: I am a frontend tech lead (not even in SV!!) and my most junior engineer will answer the question correctly. I can't even fathom how one could contribute to a non-toy app without knowing this.
People tend to remember things that they do, not what they read, much less from what they hear in lecture. The odds that I'm right is high because nobody was able to answer the question satisfactorily.
I had to do a short javascript project at work and the differences between the various function invocations was one of the first things I learned. That and how to deal with the disastrous scoping issues.
The answer the interviewer was looking for seems to expect knowledge of how 'this' is different in Javascript versus other languages, and how things can go wrong. That is different from simply knowing that 'this' refers to an object.
Since this is for a junior position, conceivably an applicant could be a recent CS grad with no formal JS training, and hacked some projects on a side or job. And thus never by happenstance run into this issue, even if he read it somewhere sometime.
As someone that is self-taught via books, websites and finding stuff out on Stackoverflow, etc. I feel like everyone should know this. I hear all languages have their quirks, but this is emphasized so much in JS that if you don't have at least a passing familiarity with it I'd wonder how learned the language. However, most people are way smarter than me and maybe they're learning through reading code and just building. In this case, sure, maybe they've never run into the issue.
Yes, interviewing developers for front-end positions has been a nightmare for me too. I interviewed about 40 developers to fill 3 new positions. Yikes.
"This is how its done in JQuery" is not a acceptable answer! I expect atleast some basic knowledge of DOM manipulation without using a library.
I wonder how many front-end people out there currently believe that JavaScript is jQuery and don't have a solid grasp of the language, instead focusing on use of a single library.
From my interviews over the last few months, apparently it is a large number of developers. I've had interviewers check that when I say javascript I don't mean jQuery.
I have trouble understanding how someone would call himself a JS developer and not knowing it.
I'm not at all a JS developer (even though lately I've been knees deep in nodeJS code) and most of my experience is away from the browser, but even I knew this. I was responsible for hiring at a previous company and I did see some people passing as Senior SQL developers without knowing how to do a join correctly, but I always passed it as a local thing (culture here is as long as you graduated you don't need to learn anything new) but not in other more competitive places.
A state government agency about 2 hours south of Seattle, WA. What happens is that Microsoft, Amazon, etc can offer 50 to 100 percent higher salaries and more interesting problems than we can, so most of the really skilled devs go there (I don't blame them). So out pickings are almost always slim.
On the one hand, that makes me want to decry the state of the world and of our profession. On the other, it's kind of heartening to know that that's the state of the competition (so to speak) when I want to change jobs.
Saying you're a Javascript developer without understanding the behaviour of `this`, is like saying you're a C developer without understanding what a pointer is.
You can get by without knowing how 'this' works, if you use CoffeeScript and change -> to => when @ doesn't work the way you thought it would the first time :)
Are algorithm questions really that useful when looking for a candidate? I find myself being really nervous about applying to other jobs because I'm not formally trained in CS.
My job and side projects are mostly web sites that require knowledge about how to architecture software but I very rarely write complex algorithms.
If something comes up where I need to optimize something I can usually spend some time Googling for some insights on how to improve it, but it's been 15+ years since I've written a sort algo. The idea of being forced to come up to a solution to an unknown problem on the spot makes me feel inadequate.
When interviewing engineers at my last gig, we tried to find people who will "get things done", which in turn depends a lot on your specific job role. For a good majority of the software dev positions we had, getting things done didn't require in-depth knowledge of arcane data structures or algorithms. We just needed the candidates to be smart, and ideally have some experience in what they were being hired for.
So for say an iOS dev position, we would pick the candidate who had released two apps on his own but maybe didn't know much about say red-black trees, vs. the candidate who knew all his CS theory but hadn't yet written a single line of iOS code. We also valued good communication skills, and what Linus refers to as "good taste".
However, we did have a few roles (machine vision, big data, etc) where algorithmic knowledge was essential to getting things done. And for these roles, we always favored candidates who had excellent math & algorithmic chops.
So it depends. I think the problem really is that most interviewers run all candidates through an identical "favorite list of questions", regardless of what the role is. This is quite unfortunate.
No offense taken, but I'm curious as to why you hate that phrase.
"Getting work done" is essentially what we're hiring people for right? As long as you can get done what you were hired to do, it shouldn't matter whether you suck at algorithms, are not a "ninja", don't fit "culturally", and whatever other weird things companies look for in candidates. It's as prosaic as it gets, and IMO it's the absolute correct metric to use.
It's as different as it gets from "changing the world", which honestly very few companies are actually doing, and is hence a source of irritation for me as well.
It's important to make a distinction between two different types of "get things done" here. There is one type where the candidate figures out what needs to be done to complete a feature in an application and does it. Then there's the type where the candidate figures out what is the least work (ie fastest way) and does that without trying to understand the potential outcomes. Given that the slapdash candidate is great at patching bugs I would maybe consider him/her, but frankly I prefer people who measure twice and cut once. I know that sounds like a separate concern --it is-- but some business cultures confuse work ethic and results along the lines of "gets things done".
> Are algorithm questions really that useful when looking for a candidate?
I go back and forth on this. I do machine learning/backend large scale engineering stuff. I have typically found that very rarely do companies actually really grill me on these things. It is mostly computer science theory (a.k.a algorithms/data structures). It used to annoy me a bit especially many questions have embedded tricks that make them dramatically easier. E.g. checking the validity of a BST is as simple as checking that the invariant left subtree is smaller than the root and right subtree is larger than the root is maintained. How you choose to implement that might trip you up, even if you stumble upon the fact that recursion is necessary and key.
On the other hand, once you intensively go through the process of studying these problems. You become aware of how incredibly rich the field of practical usage is. For example, order statistics can be efficiently organized using a rank tree. These are clever tricks that it is nice to have floating about in memory. Because they help you know what to google for.
I'm a full stack developer. Currently focusing on iOS. Interview questions should really depend on the expectations of the type of software being developed.
I've been to a couple interviews lately and this has been the first time (in my career) that I have been tested (with time constraints too, mind you). I was either pointed to a whiteboard, or sat in a room with nothing but a couple sheets of blank (unruled) paper, a non-erasable pen, and a list of ~10 algorithms questions with a few to be implemented and their running time, and memory footprint to be explained.
I was not prepared, at all.
I have been developing software for about 17 years. Do you have any idea how many times in my career I have been asked to write a heap sort, a trie, or create a power set? Never. So, I had forgotten some of the specifics of how to implement them. Let alone on paper. A quick note... My handwriting is atrocious. I'm 41 and I am extremely embarrassed as to how bad it is. I can play classical guitar, but I screw up everything I write or attempt to draw. I thought it was a dyslexia thing or something, but I don't seem to have enough of the symptoms for that. That's pretty much why I liked using a computer when I was younger; I could fix my mistakes. So, needless to say, when I am asked to write stuff down I kind of freak out.
Anyway, there is a reason I have reference materials and the Internet. If I don't remember the specifics of something, I go look it up. I know what a lot of data structures and algorithms are, but I just don't bother memorizing all their specifics. I know what to look for. I read the description and can decide what the best thing to do is. Sure, I remember the basics of the major algorithms and data structures, and some of their their Big O characteristics. Implementing these isn't really what I do on just about any given day.
So, what have I been doing about it? I've been spending the last couple weeks going back over the "Algorithms" book (http://algs4.cs.princeton.edu/home/) and grabbed all the videos from the Coursera courses on the same book/topic.
I admit it's all my fault. I have written a lot of very successful applications over my career. These have fulfilled requirements for power generation, real estate, healthcare, search engine, and marketing companies. Using higher level abstractions (like using an OO language) with industry tested APIs for sorting, lists, trees etc.. kind of makes you push that stuff to the side because for 95% of the development, that kind of low level detail is just not necessary.
Now, of course, this really depends also on what type of development you do. Sure, if you are writing a lot of C code, you may need to manually write these structures. Or, if you are writing low level code (game event loops, collision detection, file system stuff, you know) that needs to run as optimally as possible, sure. A lot of us write applications that take in data, and spew it back out. Heck, a lot of developers are forced to write just a hell of a lot of SQL queries and they'll never see a data structure beyond a class file, an array list, and a result set.
Again, I am attempting to better myself now. I don't know how long it will be before I can answer some of the more crazy questions I have been asked though.
The problem is that there is a belief in the industry that 15-30 minutes of technical interviewing tells more about a candidate than that person's entire career history. I have seen no actual data to support this belief.
I think someone who has a history of having built successful applications is far more likely to be qualified than someone who happens to have a good memory for algorithmic solutions and performs well under the stress of an interview situation.
This interviewing approach may make sense for entry level candidates who have nothing more to show than what they have learned in their CS classes but applying it to an experienced professional is simply brain-dead.
> The problem is that there is a belief in the industry that 15-30 minutes of technical interviewing tells more about a candidate than that person's entire career history. I have seen no actual data to support this belief.
Actually, this is only true when there is no social proof. Once you have people who can vouch for your successful application building prowess in some form or the other, you will find interviewing to be dramatically easier.
Statistically speaking, I haven't had to look them up that many times. I've a high percentage of the JDK memorized though, and a pretty good portion of the CocoaTouch and Objective-C Foundation framework. :-)
One problem is that many people associate front-end development mainly with HTML and CSS. HTML and CSS are not programming languages.
I say this a front-end developer who has to write HTML, CSS and JavaScript on a daily basis. Yes, strictly speaking, HTML and CSS may be considered programming languages, but they lack control structures, design patterns and other interesting tenants of computer science. Like the author, I'm much more drawn toward the CS-related tasks of the job such as writing JavaScript.
To be clear, I have an enormous amount of respect for people who enjoy the design aspects. Writing CSS, using Photoshop, etc., requires a lot of skill. My point is simply that there is a divide among those front-end developers who are drawn toward programming and those who are drawn toward layout and design.
As more sites gravitate toward complex JavaScript-driven web apps, it may be useful to ditch the general term "front-end," differentiating C.S.-oriented front-end developers from those who prefer visual design.
This might make the expectations of a front-end development position much clearer, allowing for a simpler interview process.
Post author here. I agree 100% that HTML and CSS are not programming languages. However, any application that you build on the front-end is going to require your JavaScript code to interact with the HTML and CSS, so a solid understanding of how all the pieces fit together is crucial.
I can't tell you how many times I've seen back-end engineers hack together a 100+ line JavaScript solution to a problem when one line of CSS would have fixed it.
If you don't know CSS, HTML and DOM very well, then you're probably going to be over-engineering your front-end apps.
Any book recommendation? I can say I know JS as a language sufficiently well (I can write basically anything on Node), but I almost completely lack a systematic understanding how the HTML+CSS and DOM work together (layout engine, rendering, etc). I have some basic knowledge here and there, but reading "We need to make outside div relative to be able to use absolute on the inner one" leaves me staring out of the window.
The problem is, it's even more subtle than that. Sometimes, the right way to do something is by setting classes (or even, god forbid, inline styles) on the DOM using JavaScript, and sometimes it's better to use CSS. Sometimes it's debatable which way is better.
It's definitely a tricky area of development, that's for sure; pitfalls and subtleties abound.
> strictly speaking, HTML and CSS may be considered programming languages, but they lack control structures, design patterns and other interesting tenants of computer science.
They are non-Turing-Complete programming languages, and part of that is having limited control structures. "Design patterns" aren't a language feature, have nothing to do with being a programming language (architecture has design patterns -- in fact, that's where the term comes from), and CSS and HTML both have design patterns (and piles of books describing them.)
> As more sites gravitate toward complex JavaScript-driven web apps, it may be useful to ditch the general term "front-end," differentiating C.S.-oriented front-end developers from those who prefer visual design.
There's already a distinction commonly made between "front-end developers" vs "designers". What more do you think is needed?
> Wrong! CSS is in fact a turing-complete language. :) I know it sounds weird, but it's true. Turing-completeness can be formally proved for CSS.
Where's the proof?
I am aware of a supposed proof that CSS3+HTML5 is Turing complete (but it relies on specified user interactions that aren't part of the defined execution of semantics of either language), but I've never heard of one CSS itself.
I didn't mean that it can be proof to CSS independently of HTML of course. And I suppose this requirement is obvious at least because CSS is not executable without HTML at all.
Anyway it seems you are quite familiar with the topic, and I believe you heard all the recent buzz around rule110 etc. But a lot of people don't know about this interesting fact yet.
I always assumed that the term "engineer" in "front-end engineer" implied software engineering capability. Although, like usual, it's dangerous to make assumptions.
In the context of software "engineering"/programming, the term engineer has been bastardized to the point of losing all meaning. To call someone who programs at all an engineer is, in my opiinion, embarrassing, especially when juxtaposed with actual engineers (e.g. mechanical, acoustical, aerospace etc.) who went through a hell of a lot more to be able to be called an engineer than a 4 year CS program. People like John Resig, Jeremy Ashkenas can lay claim to being software engineers. Your average moron just out of college? Don't think so.
How about your average moron with an engineering degree like me?
In Canada, there's a very strict definition for engineer. If you don't have an engineering degree from an accredited university, and a professional designation, you cannot call yourself an engineer. They take it very seriously since it's a regulated profession.
Obviously everyone is free to draw their own lines (outside of Canada at least).
I always thought an engineer was someone who puts scientific or mathematical theory into practice and to solve technical problems. I'm ok with someone giving themselves the title of engineer if they do that for a living. On the other hand, they should not call themselves a "Professional Engineer" without the proper accreditation.
>I always thought an engineer was someone who puts scientific or mathematical theory into practice and to solve technical problems.
100% agree. In the US I don't think it's as strict as Canada (may be wrong) but I know one has to take an FE to be called one. People in the software field, however, running around themselves engineers are more often than not, not putting any theories into practice but instead using the tools that actual software engineers (those that create software packages/tools/languages/compilers etc) make, essentially making them a journeyman of sorts.
The FE exam is to become a licensed professional engineer. It is certainly not required to be considered an engineer, and is considered a waste of time if you are doing work that does not require it. The license is most effective for civil engineers, because building/bridge/etc designs need to be approved by a licensed engineer for regulatory purposes. It was pretty common for mechanicals to take the exam too. I assume it would be beneficial to get it if you are doing any sort of government related work.
I studied computer engineering and have no desire to take the FE exam, as being licensed is almost entirely useless in my field. As far as the difference between "engineers" and CS majors, at my school basically the only difference is math requirements, and how math is used in the higher level classes. In ECPE (computer/electrical) we differentiate ourselves from CS by studying circuits, systems, physics which are very calculus-intensive. The area where it crosses over into CS is when you get into computer architecture, digital design, assembly, which is like programming, but due to being so close to the hardware level (working with raw digital logic) it ends up being more math intensive than most high level programming.
That is actually kind of happening. People are becoming their own front-end doctors by Googling their medical problems. In fact, this is how I've handled health issues myself. I haven't been to the doctor basically since high school (just optometrist). I assume this is similar to the way a lot of people become "software engineers".
I agree completely. At the company I work for, we develop a complex client-side js app. We've got "backenders" who write Ruby, "frontenders" who write CSS + HTML, and "middlenders" who write really fucking awesome javascript.
There are only two hard things in Computer Science: cache invalidation and naming things.
CSS and HTML have to be given architectures, where we have to name these "files". What can you do with jQuery if your CSS and HTML are named and mixed up with no clear architecture? Or with an architecture that fails to harmoniously follow the JS architecture? It must be clear that one direction the future could take is that CSS classes are given interfaces to be used in JS.
CSS (as JSSS) originally did have control structures, and they're coming back as SASS/LESS. CSS is being "modernized" as it were, and so questions about the language are very important to ensure developers are maturing in light of current trends. We're now talking about CSS variables in Standards.
HTML and CSS fall dead center between "the two hardest things in computer science": How do we name these files for inclusion via AJAX? How do we develop CSS abstractions and class-based architectures? What about LESS/SASS (since no one should really be writing raw CSS anyway)?
"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."
False dichotomy. How about a smart person who knows a lot about X and is creative and logical? They do exist.
I feel like many interviewers want to categorize someone in to one of those two categories from the outset - "this person already knows a lot about XYZ, therefore, I'd rather look for a smart person who doesn't know XYZ and teach them". Sounds crazy writing it out, but it's the impression I got years ago interviewing. It's also the impression I get from friends of mine who have interviewed in the more recent few months.
It's more like, "we want smart people, so let's optimize our interview process to find smart people, and give everyone the same interview questions."
The problem here is that firms tend to prefer giving "engineering interview problems" to everyone, and do not want to segment interview questions by position.
Because that takes a lot more time for the interviewers. For a growing tech company, they could have as many open reqs as they have engineers. Crafting questions for all of those positions takes a lot of time that most companies don't have time to do.
Hiring is pretty much the most important thing you do as a company.. if you can't spend an hour per position developing applicable questions for each position, you are setting yourself up for failure.
Yet, time and time again, these posts come up and the comments contain a not-insignificant of anecdotes about hiring processes that resulted in high failure rates in interviews, so they hire someone kinda smart anyway and teach them the concepts that other interviewers failed to answer satisfactorily in the interviews. Why ask at all, then?
Ideally they should be having people in that area of expertise doing the interviewing of the candidate, since they have ready access to the domain specific information to ask relevant questions.
Related, I just found out that Darcy Clarke put this list together of good front-end interview questions. I would have included it in the article if I'd known about it ahead of time.
The ability to emulate different versions of IE. Of course, the only reason this is necessary is because of the many breaking changes that the different versions created.
I remember coming across this other "Learn Front-end" list: https://github.com/dypsilon/frontend-dev-bookmarks on HN a little while ago and thought it was a great example of just how scattered Web-FE education still is. Everyone has their own favorite "book" and there's no K&R that you just pick up and read.
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.
This!
That one sentence pretty much addressed all of your questions and concerns. So instead on hacking the apparent process, read that sentence again and get it. This is pretty much an absolute truth in almost any industry for almost any skill. It's especially true in tech because:
- "X" will be different in 2 years anyway.
- "X" will be VERY different in 4 years.
- Well funded companies want long-term talent.
- Start-ups seeking their place want long-term talent.
- Companies with long-term vision want long-term talent.
- A jack of all trades is usually better than a master of one.
- If it's so complicated to learn, it's too complicated to use.
I've done very little HTML,CSS but I feel confident that I could become proficient as a front-end dev. But it is going to take months. I assume you are saying that these companies are hiring based on expected performance at 1+ years. They don't expect the person who gets the job to be making major front end code changes the first month?
How does one go about identifying these companies that are willing to invest in smart people who might not have experience in LibraryVersion 2.1.9 or something?
Note: I work for Grooveshark, which is in Gainesville, FL, about as far away from San Francisco as you can be in the continental US...so what I'm about to talk about might not be like what is going on over there at all.
When we bring someone in for an interview, we generally already have a pretty good idea of their technical skill level. Part of the filtering process is asking to see their work, either code samples or a portfolio. For frontend engineers it is especially easy to see their work since you can load it up in the browser, inspect, interact with the console, etc.
If we are impressed by their work, the interview is 90% making sure they are a good personality fit, 10% making sure the work we looked at was actually theirs. We probably end up asking slightly more frontend-specific questions than the author experienced, but probably not much.
We find that this process generally works quite well, but a few people that we gave offers to did tell us they were surprised because they felt they had bombed the interview, assuming that since we didn't get into a lot of nitty gritty technical stuff or ask them to write code on a whiteboard, that we had already decided we weren't going to hire them.
A coworker and I wrote a script that's been through a few iterations based on feedback and tailored to whatever company I'm hiring for. Based on the participants self-rating (1-10) you can ask increasingly more nuanced questions in each area of CSS, HTML, and JS. Here's the front-end interview script I use: https://gist.github.com/potench/e71e09c882628054c119
So far it seems to do a good job at promoting conversation and identifying thoughtful and talented FE developers.
This is a good list. Can I ask you something though? I've always been curious about the value of questions like these (just to take a sample):
> On a scale of 1-10, what is your comfort level developing with HTML, CSS & JavaScript?
> How well do you think you work with other fellow developers?
> Given a choice, would you rather work alone or in tandem with someone?
What are the "correct" answers to these? Or more specifically, in your opinion what are the "wrong" answers?
On the first, the problem I see is one of self-reporting. We have seen developers self-report a 9 on something, only for us to determine later based on the interview that they were more like a 5. We didn't put value on either of these numbers, because both were relative - the "9" was presumably relative to his previous job environment, and the "5" was relative to ours. (At another company the person could've been a "2", for example.) Fact is, it doesn't really matter - we were just looking to see if the person can add value, regardless of whether they were a 5 or a 10.
On the latter two: we have had "loners" crank out incredible bits of code on their own, and "team people" do the same as part of a larger group. We have also seen people switch between the two "personality types" based on context - the specific project, their team mates for the project, and so on.
So we prefer not to ask these types of questions as we don't seem to get any relevant information out of them, but perhaps we're missing something, and so I'm curious as to what your motivations are.
As a follow-up to my earlier comment, i'm doing a phone interview right now and the first interviewer started off with questions about how IIS internals worked and some obscure C# questions. I immediately asked him "Is this a front-end position or not? I know C# and .net MVC but i'm focusing my career on Angular" his reply "I honestly don't know, they just told me to call you and ask you a series of questions on advanced C# development" Job posting title "Senior Frontend Developer with AngularJS"
It seems that JS MVC frameworks change every year, maybe they decided that asking questions on the flavour-of-the-month is not an indicator? Would expect some JS questions though.
As a bonus, finally got to talk to the hiring manager a second ago and he informed me that there would be NO javascript or front end development in this role, just converting Crystal Reports into some other obscure reporting system. So I ended the call promptly with a "Thank you for your time and good bye"
I've had similar experiences in the last month of interviews i've been through. I was asked how i'd design a secure backend API in asp.net, various algorithm questions, some basic javascript questions ("what is a closure?", "what does the var keyword do?", etc") and other very non-specific things. At the end of most of my interviews when they ask if I have any questions about the positions I tend to have to ask "Is this a Front end Developer position you just interviewed me for?" Not once have any of the interviewers been front-end devs, only SVP of Development or Director of Design or some other inflated title. I want to talk about problems i've had building Angular or Knockout apps or or cross-browser JS/CSS issues.
Interesting so I hope you said get ready to spend a fuckload of cash on state of the art secure key stores as this is the only way to properly build a secure back end.
This seems fairly typical, and I understand the rationale on both sides.
In any kind of engineering role, not just front-end, having domain experience/expertise certainly helps you be more productive from the get go. In a previous company we hired developers with good CS chops but no iOS experience to build our iPhone app - they picked it up, but it took a couple of years and numerous rewrites to get an awesome product. Thats a huge opportunity cost. You'll end up with a better product right off the bat if you hire an expert, especially with technologies which have a ton of quirks and nuances.
So why wouldn't you want to hire a front-end expert? In a lot of smaller companies flexibility can trump expertise - having an engineer who is smart and can work across the entire stack is essential in smaller teams. That doesn't mean they won't be primarily doing front-end development, but its helpful if they know their way around the back-end to some extent without hand-holding from other engineers. A good candidate needs to be smart enough to quickly pickup new tools and techniques, and it is important to determine this in the interview process.
I was just thinking about the similarities in iOS development. I have worked on a project where the original authors weren't iOS developers but were very competent front end developers, and it wasn't pretty. It doesn't just affect the code, but also things like the build environment and documenation.
My experience is that interviews only appear to be wastes of time in hindsight. They are not zero-sum, and due to the nature of the beast there is no way to figure out that you're scoring an "F" rather than a "B+".
You'd hope that before they bring you in they know that you know basic front end stuff. To be honest most front end tech is simply memorization of standards and idiosyncrasies between browsers. Anyone can go through and figure this stuff out via a simple google search. On the other hand taking say data from a Ajax call and sorting it or filtering it with custom logic takes some creative problem solving to do it gracefully.
Interviewees always forget to figure out why they interviewer and company is asking these questions or requiring particular knowledge. Next time just ask them!
Nothing against you, as I don't know you or your work, but "shipping product" does not equal doing good work. People ship crappy, buggy code every day. Just because one "ships daily" doesn't mean that what they're shipping is worth anything or means they know what they're doing. I've seen people that have no clue how to write code copy and paste crap they find all over the internet into a file and ship it. It's a slow, buggy and ugly hack, but it shipped. It will come back days later as unexceptably bad by the customer. That's the purpose of these tests. To weed out the people that have no clue how to write proper software that deals with high loads, scalability and performance criticality.
Software engineers make product, not code. I'd prefer talented developer with good practical experience in “releasing products” rather than an algo-geek who can only solve stupid hiring quizes.
Slow buggy ugly WORKING RELEASED product is a much-much better than ideal clean and effective thing not yet ready for release for a few years in row.
Not saying I disagree with that, except for releasing slow buggy code. Why not accept either of those people? There are efficient ways, as described in the article, to interview for people that are great at releasing quality code in a productive time frame. I was simply pointing out that releasing code daily doesn't mean you know what you're doing. If you can't answer at least some of the questions that were in this article, I'd question your ability to write productive code. That's not to say that only questions like that should be a determining factor for ones ability to produce.
Just want to mention also that knowing the answers to these questions does not mean that you'll write bug-free code. Bugs are a product of shipping, and occur regardless of talent or ability to answer said questions.
I had a similar experience with a well known bay area company. I was interviewing for a front end job and they gave me a live coding interview with a recursion question about assembling trees from strings (or maybe vice versa).
I had spent the majority of my time preparing for the interview preparing for front end stuff. I stuffed my brain with Javascript quirks and made sure that the stuff I already knew I could articulate really well. And I gave myself a quirk algorithms review because I knew that is something the Bay Area values.
I struggled with the first question. They asked me if I was interested in a non-dev job because apparently they liked my personality and thought I may be a good cultural fit. It struck me as odd that they liked me enough to inquire if I'm interested in other positions, but only gave me one chance to show them I could be a frontend candidate and the sole interview question wasn't even frontend oriented.
It could have been a sign that they trusted your front-end skill. If I know someone has a skill, I don't waste my time interviewing them to prove it. I try to figure out what else they can do, where they can grow, and how well they would fit in with the team.
So I'd pose the question back to you -- did you provide them a portfolio or any code samples that would have made the front-end questions redundant?
I was thinking along the same lines. I would be curious to see his resume, as the content could potentially influence the interviewer to ask certain types of questions.
Yes, I provided a detailed resume as well as my Github account for all of these. The problem is it didn't seem like the individual interviewers had taken much time to actually look at what I'd done.
If they had, then maybe I'd agree with you, but it seemed like many of them were just going through the motions. It seemed like they interview people all the time.
"It seemed like they interview people all the time."
I bet you hit the nail on the head.
At my current job, I've had weeks where I've been on an interview loop every day. At that point, I'm not going to spend much time looking at your github code in depth beforehand each day. Especially when it's a candidate whose area of expertise isn't the same as mine, so I wouldn't know what to look for. Ideally we'd be better able to match interviewers with interviewees, but if we had enough people to be doing that, we wouldn't be in the mad hiring rush that ends up with a developer doing five interviews in a single week around career-fair season. ;)
(My last job was a much smaller company where each hire was weighed a lot more, and we absolutely would've looked at all that stuff there.)
However, I always start off asking about a specific project from the candidate's resume, usually the one that I think sounds most interesting to me. Depending on how long they take to explain it, or how interested they seem to be in explaining it, I'll follow up with a more open-ended question of what their most interesting or challenging project was -- if you can sell me on that project, it's just as big an influence on me me as the coding or design question that I'd also ask.
But I have coworkers who don't ask about other projects like that, which I think kinda sucks.
I have friends who have politely refused to answer or indulge the interviewer in the algorithm questions labyrinth. As someone being interviewed, you should atleast try to divert the interview toward your strengths.
On the flip-side, if a company is interviewing you for a front-end position and not asking enough DOM, CSS questions, they're doing it wrong.
Great writeup. This is pretty much the same experience that I had when I moved to San Francisco. I got a lot of "college memorization" questions. Basically, you could read a book, memorize the answer and come up with it. I was also interviewed by some young guys out of Stanford who asked me a question that they probably spent a few weeks in class working on that I had 45 minutes to figure out. When I look at the interview process, it seems more like a battle than an actual interview, but it is engineers we are dealing with.
When I do interviews, I want to know that you can program, but I care more about whether or not I can work with you.
I am honestly a little shocked by this. I am a university student and this past semester I interviewed with around 10 companies in the Bay area, all of which were for Front-End engineering positions. I can only think of one company which did not give me any 'front end specific' questions. I was asked everything from hoisting and closures to explaining how Webkit works and various ways to improve page load time. Are you free to elaborate on what companies you spoke with?
I interviewed at both. The larger companies were more likely to give me 'programming challenges' or puzzles (usually small mockups) for me to do ahead of times while startups tended to be more conversational and, quite frankly, didn't ask as hard of questions.
Maybe offline. I'm not interested in publicly calling out any companies. I mainly wanted to shed light on the process and my experience.
I will say that when interviewing for previous jobs in the past (at smaller companies), I got asked a lot more front-end questions. Maybe it's just a big company problem.
It's true on the business side as well. Small companies ask relevant questions because they have to - their survival depends on finding someone who can do the job.
Big companies, even famous ones, have moved so far beyond their scrappy "gotta survive" days that they have become quite lost in their bureaucracy and arrogance.
Good breadth, no one gets bounced for not knowing a couple of the answers, great way to get a larger picture of what the candidate knows (or doesn't!).
Designers-turned-JSers tend not to do so well on data structures and bits and bytes.
After the five questions, I move to HTML/CSS questions: inline vs. block, what does float really do, the display property, valid values for display besides "none", visibility: hidden vs display: none, position, absolute vs. relative (with relative offset parent questions thrown in).
For the JS portion, I ask scoping, closures, global object, the values of "this" based on calling context.
I like front-end engineers who are also, y'know, engineers. I like working with people who I can say "that distributed system has performance characteristics akin to a hashtable" and they know what I mean.
As a former front-end engineering manager that has screened, interviewed, and hired tons of developers for large corps and small startups, I hear this guy's frustration and have felt it myself. I've often stepped into interviews for other departments and teams that had no FE developers to give them a hand.
At the same time, I've come across far too many developers who assume "front-end" only meant HTML, CSS, and jQuery.
NOTE: Not JavaScript, but jQuery, which are very, VERY different things. The author does himself a disservice by citing a jQuery example instead of a general JavaScript one. I get how prevalent jQuery is, but if you can't describe some of the inner workings of JS to me, then I may weed you out. That's just my preference though; other hiring managers differ.
In my particular cases, we needed FEs that knew JavaScript and server-side scripting languages - to the extent of being able to write some presentation-layer logic if necessary.
So whenever I've coached technical hiring managers who have no experience with front-end development, I'd tell them to go right ahead and ask questions on general programming logic. Even if the candidate's verbal answer is incorrect, the thought process behind trying to answer it can be helpful.
FYI, the type of phone screen questions I would ask are:
+ Why is a doctype significant? (HTML)
+ What is the box model? (CSS)
+ Describe the event model. (JavaScript)
(You'd be surprised at how many purported front-end engineers get these wrong.)
These were accompanied by general programming logic questions. They all designed to assess the developer's ability to communicate and explain, and not the developer's technical skill. For that, I looked at code samples and the results of a take-home code exercise. And the specificity and difficulty of the questions would depend on the stage of the interview and level of candidate's experience. The "What is the value of 'this' in a method?" question is a great one too.
I think these problems stem from the job posting. Like the author, I've come to love interviewing and I've conducted a good deal of interviews myself. I've noticed that a job titled "front-end developer" with a poor description casts too wide a net and wastes everyone's time.
If I see that you mentioned design experience and Backbone in your job posting and then you quiz me on Rails and database queries I'm going to feel like I'm attending amateur hour.
However, if you state that data structures, algorithms and all that other great CS stuff is fair game in the job posting or the follow-up emails – then go ahead.
Don't envy the front-end developer. At this point we have to be prepared for anything.
I believe the mindset behind this behavior is A) they take it for granted that you're proficient in your stated area of expertise, B) they're not necessarily proficient in your area of expertise, so wouldn't be able to assess your skills anyway, C) algorithm knowledge is hard to fake, so your false positive rate for hardcore engineers will be low, even if your false negative rate will be ridiculously high.
Google's publicly available prep material reinforces this third point, even if they don't say it explicitly. They recommend books, point you toward places where you can learn the concepts, and tell you if you fail once, try again in a few months.
In javascript, the number type is just number. To truly bit shift with this method, you'd need to convert the bitwise representation into a number, perform the given operation, handle the corner case of odd numbers when dividing, and the convert it back into some representation of bits.
Trying to judge people with questions like this seems like a misguided endeavor. Yes, it's probably valuable to know that bitshifting is roughly equivalent to *2 and /2. But that's more like trivia - the chances you'll actually use that in real life is really low. I've had to work with people that think bitshifting is an appropriate optimization for division/multiplication by even numbers. I then have to explain overflows, underflows, and the fact that the compiler will compile it to shifts if appropriate anyway, so don't sacrifice readability in the name of micro-optimization.
That generally sucks when you're interviewed by assholes who have no idea that the specific platform that you might work on requires.
Consider most front-end engineers ALSO to be designers, and I'd suspect thats where I would drive the interview. I would wish the same treatment.
Also lol that the interview questions are basically EITHER memorizing formulas and remembering why something was that way or trying to cram down a solution on the whiteboard in the little time you have.
The latter is more admirable, but depends on the situation at hand. 5 minutes, white board, using your fingers as eraser.
I think we are also seeing the rise of the frontend developer, where they spend most of their time on JS, with maybe some time in HTML and CSS - at least, that is what I do for work, although I am fully capable of excelling at CSS as well.
My career as a developer has been coming up through the role of front-end engineer, really from when that was first being defined as a separate role (2004-2005, around then). In hindsight now, I would never hire myself. Either you're a developer, in which case you should be able to traverse that stack (so for example JS as well as PHP/Ruby/Python) or you're a designer, and you can traverse that stack (so you design, implement your designs in HTML/CSS, maybe a little JS as necessary). But while there is crossover between the two domains, there isn't a separate role in the middle. Trying to fit development workflow around people who just do HTML/CSS/JS ends up creating too many bottlenecks, on both sides: "I'm waiting for designer A to deliver X" or "I'm waiting for back-end person B to deliver Y". When you just have people who work their whole stack, that bottleneck is removed.
It gets necessary at some point - it's not cheap finding highly skilled full stack developers, and they're not the most common beasts around. Everyone wants them, but they have their pick of jobs. It's far easier to hire for the positions separately, and if your company is in need of rapid expansion, I'd say almost necessary given the market.
While I term myself as more of a frontend developer currently, I also know CSS pretty well (I sometimes fix bugs the UI team can't figure out), and I am currently transitioning to doing some backend work at my current job as well.
All developers should strive to be full stack, and designers should strive to know code more, but realistically speaking, not everyone is there yet of course, so you have to focus on developing the talent or hiring it.
My experience interviewing "Full-stack" developers indicates that it can be a vanity title devs assign to themselves to be more marketable. Unfortunately, I've found their skillsets to be very lop-sided.
Typically, I'd interview full-stack developers with lots of front-end experience and skills (based on their projects and code samples) with very limited backend experience or skills, or they were backend engineers who knew the ins-and-outs of robust, scalable backends, familiar with AMQP etc, but couldn't horizontally center div or modify the prototype of an object in JavaScript (let alone know that JS used prototype-based inheritance).
And then of course there's the 3rd dimension to full stack which is DevOps.
If you're just starting out you need people who can do all 3, even if they're kinda mediocre at some of the parts. But when you grow, and your product starts maturing, you need expertise in all areas to really have a polished product. Otherwise, you're going to be stuck with something that either has a really polished front-end but a dog-slow and unreliable backend or vice-versa.
I was full stack at my old job, so I do phone screens for front end engineers now. It's incredible how many people claim "front end" and fail at basic JS, HTML api, or page optimization questions yet do well at algo questions. I am far from an CSS expert but if we didn't ask questions like "how would you optimize the static content of the page?" I'm sure we would end up hiring OK general devs who actually don't know anything about front end.
I interviewed for a long-term "Frontend engineer" role in June for a large cable company here in the Netherlands. I've been a full-stack developer for the past 3 years or so, and before that I was in game development, and before that still, I wrote enterprise middleware.
My frontend experience going into this interview was almost entirely jQuery, with the exception of one 2 month freelance project where I had a crash course in AngularJS.
I was asked a ton of technical frontend questions, and I was able to answer them at a conceptual level but not from experience. I got the job, and I think what was important was my broader experience as a programmer, not the answers to specific frontend questions.
The thing is, real frontend programming of large JavaScript applications is a brand new field. There are lots of people with lots of jQuery experience (it's telling that this article deals with jQuery as an example of frontend development), but not so many with serious JavaScript programming experience outside of a library or framework.
I think because of this, companies are just being realistic when they interview for frontend positions based on general programming knowledge and experience. Maybe in 5 years they will drill down more, as the pool of expert frontenders expands.
I know it's a bit off-topic, but I'm a student so anything about interviews interests me a lot. For the Bacon Number question, I'm struggling a bit to get my head around a good way to do it.
My immediate idea is to derive a graph where nodes are actors and an edge between 2 actors means they've been in 1 or more films together. I believe the shortest path between them and Bacon could then be found by breadth-first search.
It looks like that graph would be quite slow to derive though - my naive pseudocode being something like:
for bucket in hashtable:
for actor in bucket:
if actor not in graph, add a node for actor
for other_actor in bucket (up to actor):
add an edge between other_actor and actor
That looks pretty slow without deriving a running time, so I'm guessing there's some optimisation that can be made from the current structure of the hashtable. Could anybody give me a pointer in the right direction please?
Instead, your graph should comprise movies and actors as vertices (edge = actor was in a given movie), and to get the Bacon number you just halve the distance in this graph.
So you code would look like
for bucket in hashtable:
add node for bucket
for actor in bucket:
if actor not in graph, add a node for actor
add an edge between actor and bucket
add an edge between bucket and actor
If each movie contains exactly K actors, and there are N movies, then your graph has O(NK^2) edges while mine has O(NK) edges.
Ah that's awesome, really smart optimisation, thanks. I hadn't really thought of the possibility of having the two different features in the same graph but that's definitely better!
I appreciate that, but I don't see a way to efficiently do a breadth first search or some similar search routine that will find the Bacon number on it. I mean, surely you need at some point to be able to follow edges from an actor - and that's really inefficient in this format?
I have been a front-end engineer for over a decade, and if I were hiring for a position a decade ago I would understand and agree with your points. However, with the breadth and depth of skills required for great front-end engineering today, I would feel very uncomfortable hiring someone who only had the arcane skills required to "get the job done" on the front-end. If hiring for a smaller company, I would be concerned about this person's ability to contribute to more than just the tasks in their silo. If hiring for a larger company, I would be concerned about this person's potential for future growth. Also, it's usually apparent from projects or employment history that someone can do what's required on the surface for front-end work, so why would I waste interview time going over details and minutiae in that area? I'd rather take the opportunity to find out if they're a solid engineer as well.
My understanding is that this is type of 'shallow' technical interview in SF with notable companies is not limited to front-end.
A good friend recently interviewed at multiple well known and respected internet companies for an Android position. This guy is perhaps a global authority on Android. Technical questions were of the computer science type, and did little to illustrate the substance of value the companies were actually trying to hire for.
Rather than take the time to understand whether he really, really knew Android, they wanted to see if he could traverse nodes in a tree. Two companies even asked the exact same non-Android specific question.
More ridiculous than asking CS questions of a front end dev. I'm a self-taught front-end dev who has flunked numerous interviews because of a lack of CS degree and being able to get through the sorting algorithm questions. I then went home and have spent lots and lots of time teaching myself those fundamentals, if only to interview better. Those fundamentals have made me a vastly better front end dev, able to efficiently solve problems I wouldn't have been able to solve a year ago.
I have had the exact same experience with the author of the article regarding a total absence of actual front-end related questions, though. Not sure how to feel about not getting those gigs.
I was recently asked a "making change" question [1] in a front-end interview, and once I finally understood it, it really really helped my comprehension of how to properly dissect tree-recursion-branching problems. Here's the code, https://gist.github.com/derek/8073844.
Another one that popped up in an interview was sub-string matching, which I bombed, but after learning Boyer-Moore-Horspool I have a much greater understanding of efficiently designing algorithms. It is the algorithm some browsers use under the hood for String.prototype.indexOf [3]. Here's that code, https://gist.github.com/derek/8035740.
Well, if the developer is creating custom components, or simply manipulating data, then they need to know some good algorithms (at least know they exist and what to look for). Like when creating a table that needs to sort the rows. If you don't know how to do this, then you could have a really bad 0(N2) algorithm that just kills the browser with even a small list of items. Or, if you need write an algorithm to pack a bunch of rectangles on a screen (like a day calendar) so they don't overlap.
Yes, there are computer science topics that apply to the front end. If you are writing Javascript (not just marking up stuff and applying CSS), then you want to know how this works. This isn't the 90's simple form submission javascript. It's a completely different world in the browser now.
Well, given the new trend of fat JS clients, if you have no clue about algorithmic complexity, you can fairly easily end with a very sluggish application, even under Chrome.
I don't expect from a front-end engineer to just drop random jQuery plugins on top of each others.
I interviewed at a well-known place here in Portland and they seemed really disappointed that I didn't already know Rails. That was surprising to me, since like the author, I am more familiar with the mindset that you prefer smart people rather than people who know technology X. Beforehand I spent all this time reviewing data structures, algorithms, etc, but they just cared about Rails. I also got one of those goofy OO-design questions about Human inherits from Animal. Not at all what I was expecting.
Just wanted to share that I had a very similar experience interviewing as a front-end engineer last year, and had made many of the same assessments about the process as you have.
It is interesting that the company I ended up at-- while they did ask some standard algorithm and 'how do you think' type questions-- there were also many questions probing my front-end skills, including some quick JS coding problems. The interview just felt SO different than anything else.
Hey. I work at Twitter. I think that at certain companies the "front-end" role is not as specialized as assumed, and you tend to interview for a specific team that has an opening, rather than for a generic position among a hoard of similar developers.
Having said that, I'm surprised there was only one CSS question, and the suggestion to combine questions with front-end specific knowledge might be a good way to ease into the interview.
>"A 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."
How does the referenced jquery statement represent basic CS principles? OOP? Definitely not that.
The referenced jQuery statement gives the candidate a chance to speak on: selector complexity (id look ups vs traversing to find descendant elements), first-class functions (passing a function reference to the .on() method), regular expressions (to add class names to an existing class attribute in older browsers that don't have .classList property on elements). There are probably other things but those are just a few off the top of my head.
I'm almost entirely backend, but I can relate to the travails of interviewing in the Bay Area and dealing with unprepared interviewers.
The engineers were like anywhere else-- and a fair proportion of them were very good-- but there are just a lot of arrogant people in the managerial ranks of the Valley. After you get an offer and you get to the negotiation phase, most Bay Area firms try to lowball you because-- even if you're from an objectively better place like NYC or Austin-- obviously everyone wants the privilege of working in California. (Expensive housing even in the suburbs, nightmarish traffic, and the most aggressive homeless population in the U.S. Where do I sign up?)
Then there was one silly game company (which, presumably unrelatedly, is now being sued) that wanted me to sign a full NDA just to do a coding test. Not an NDA over the material of the test (which I would have signed) but one that included a one-year non-solicit covering all employees of that firm.
I could be generalizing negative experiences, but it seems to be like they didn't prepare for your interview (recognizing that you were a front-end engineer) because of that obnoxious (and completely false) assumption that, if you were any good, you'd already be in the Bay Area. Obviously they had enough interest to take time out of their day, but not enough to prepare.
In New York, there are a lot of startups that are of low quality; but the arrogance of Silicon Valley is unparalleled. Wall Street's reputation would have you expecting it to be worse but, by and large, it's not.
I haven't really seen the assumption that "if you were any good, you'd already be in the Bay Area."
I have seen sort of the opposite, though -- if you are experienced, you likely have a family and there is no way in hell you are moving to the Bay Area.
I would have accepted an answer as simple as "The value of 'this' depends on how the method is called" or even "The value of 'this' confuses me because it's often not what I expect."
It was a disaster. We may as well not have asked the question at all. Nobody seemed to even be aware of anything about it.