In my experience, closures are a topic that always comes up. It is also important to know how to handle a closure inside of a for loop. I've been asked about "this" binding, coercion, and CSS specificity. I've had to solve problems that required me to know about how to use stacks, trees, and nested for loops. Other topics that have come up are how to architect an app, concurrency, memoization, building out and handling api endpoints, and pass by reference vs. pass by value.
You may not think databases are a front-end topic, but I have been asked about them on more than one occasion. Prepare to talk about sharding, natural primary keys, what your favorite database is and why, etc.
Something that has been extremely useful for me is to have a project that I've built myself to show and talk about during the interview. Although I have had one interview where I was asked to talk in detail about how I built some of my projects that are in my github, I like to respond to general technical questions while referencing something I've built. A lot of times the interviewer will then use my app as a starting point into a discussion for how I would scale it. Here's an example of an app I built quickly and have used for discussion in interviews: http://moviemap.xyz/ More here: http://valeriemettler.com/
> In my experience, closures are a topic that always comes up.
Opinions will differ, but IMHO closure is a great concept to divide those who know JS at a conceptual level (or at least have crammed for the interview) from those who don't.
I agree. We always put the little 'for loop that creates a list of functions that spit out the current number of the iteration' exercise first in all of our interviews.
Generally, when people solved that one fast, they also did well in the rest of the interview and if they struggled there, they also had a hard time coming up with an elegant solution for most of the other tasks.
What I also like about it is that a closure isn't the only way to solve it. You can use `let` for example to make sure the variables are block scoped, or use `bind` to partially apply a function with the number.
So in the end it's a conceptually very simple exercise that can give you a very good insight into how much the candidate knows about how JS actually works.
I'm also in the process of interviewing for a front-end engineer position, so thank you for replying and providing feedback.
I'm assuming it has to be written this way because the function being pushed was referencing i, which was within the scope of the closure. Turning it into an IIFE breaks out of that. Thoughts?
// Assuming pre-ES6
function iterate(k) {
var funcs = [];
for(var i = 0; i < k; i++) {
(function(num) {
funcs.push(function() {
return num;
});
})(i);
}
return funcs;
}
var itTest = iterate(4);
console.log(itTest[0]()); // 0
console.log(itTest[1]()); // 1
console.log(itTest[2]()); // 2
console.log(itTest[3]()); // 3
If you can figure that out during an interview, you're solid on the question. That's the gist of it, and knowing that you can use `let` to make it work is good too.
Try writing the same thing without a computer why don't ya.
As an interviewer I can see why you would want to force someone to jump through arbitrary hoops like that but if someone can show me `() => i` and explain why that works, that would be good enough for me.
No need for the snark. There is still way more ES5 code being written than ES6. The point is demonstrating knowledge of closures and variable lifecycle, the how is irrelevant. I replied specifically because he said "I don't see the problem" - if you start with ES6 I can imagine it doesn't look like a problem at all.
If you can explain why that ES6 code doesn't share the problem, that's as good at demonstrating the knowledge you're looking for as restricting the candidate to an older subset of the language. I would accept "okay, now explain what distinguishes arrow functions from regular functions" as a follow-up question, but "now do it in ES5" seems arbitrary.
In fact I would argue it's important that if the candidate shows practical knowledge of ES6 you need to make sure they also grasp the actual semantics (i.e. they won't rely on implementation details of Babel and run into errors in native ES6 environments).
That said, if you are hiring for a dedicated frontend developer role, the majority of JS you write will have a build step. If it has a build step, you should use modern tooling. If you use modern tooling, you might as well include Babel to make the developers' lives less of a pain.
If you did that without first asking about what Ecmascript version you should support I would prompt the question myself, and if you didn't find a different way then I would consider it a very bad sign.
Tip: You can stick to `const` when declaring `i` in the loop header (at least as far as the ES spec is concerned -- mileage may vary on current implementations / transpilers).
If you set `i` as a constant it can't be changed, so it'll always remain 0. (the loop will end immediately after the first iteration with an error so no infinite loop)
If the anecdotes I read here are correct, you should be prepared to implement a red-black tree in C, followed by an A* pathfinding algorithm on the whiteboard.
I think the best preparation you can do is to spend several hours reviewing your old projects.
For each project, recall and be prepared to explain in depth:
- The biggest technical challenge you faced and how your team solved it
- The technical tradeoffs your team made in the implementation, and whether you would make the same tradeoffs today
- What your specific contributions were to that project.
- If you can bring code that's great; if not then have the high-level design in your head and be ready to outline and explain it.
If you're anything like me, for three or four projects that represents a couple days or more of preparation.
There's a pretty good repository of potential questions for front end developer interviews on GitHub[0]. I'd suggest skimming through the list and making sure you've got a decent grasp on most of them.
Ideally you'll get mostly questions that are relevant to what your job will be, but I wouldn't be surprised to see some CS stuff in there as well (basic data structures & algorithms). Good luck!
You should at least be familiar with the major front-end libraries and frameworks - React, Angular and Ember. You don't necessarily need to "know" them, but at least know about them.
You should be familiar with what ES6 is and what Babel does. These technologies probably won't be specific questions per se but if they come up and you can't speak about them, it'd be a red flag.
Even for a front-end developer you should have a basic knowledge of data structures like linked lists, binary trees, min/max heaps, depth/breadth first search, tries, recursion, hash tables, etc. These often come up in whiteboarding questions.
Practice whiteboarding on an actual whiteboard so you get used to writing code then practice on hackerrank so you get used to quickly writing code that actually compiles. Some companies only use whiteboards, others want your code to run.
Make sure you think of test cases for your problems. TDD in an interview is usually a good sign.
Usually knowing this stuff and having some sample code will usually get you through most of the interview. Knowing the specific things mentioned in other comments is useful, but I can't imagine not hiring someone because they didn't know some specific CSS selector or how to use flexbox.
Other tips - don't get visibly flustered, talk your way through problems. Stay postive about past employers. Good luck!
> Even for a front-end developer you should have a basic knowledge of data structures like linked lists, binary trees, min/max heaps, depth/breadth first search, tries, recursion, hash tables, etc.
I would never care about these if I was specifically hiring a front-end dev. I've never once seen any of them come up in the context of front-end work in my entire career. And in fact an interviewer asking questions about them would be a huge red flag for someone who prioritizes nerd-cred over actual business needs, and is therefore likely to make poor decisions.
I don't understand how that's possible. For example, in a recent project I needed to implement a path-finding algorithm to draw connections routed around arbitrarily-placed boxes. More recently, efficiently snap a line to the nearest edge from an in-memory set of (again, arbitrarily placed and changing) objects as the mouse moves. I'm having to use and think about some item from that list on a daily basis. Where's the disconnect here - are we talking about different kinds of front-end work?
> Where's the disconnect here - are we talking about different kinds of front-end work?
Yeah I would assume so. Of course if know the job requires such knowledge, you should interview for it. But I'm thinking of more average front-end work, where you'd be building forms or dashboards or ordinary websites.
It sounds like you're building a complex application that just happens to be hosted in a browser. Although even then, I'd argue that while your knowledge of when to apply those algorithms is important, you still shouldn't be writing them yourself. You should be finding a well-vetted library and taking the function from there.
Not sure I understand the question... are you suggesting the concept of using vetted libraries is somehow faulty? Anyway, the answer is generally "a large community" or "some big company like google or facebook."
I think GP was referring to a situation where no such library exists or the needed modification would be prohibitive. Not that uncommon scenario once you are inventing new kinds of visualizations. Libs like d3js help, but they are pretty low level.
People knowing about algorithm+implementation details? Definitely not front-end developers. (Not trying to implicate that front-end devs can't do it... you get the point)
I don't really get the point. If you're writing an app to do X, and you require functionality Y for your interface, if a library doesn't exist, or is just some random persons GitHub dump minidress and no other committees, what do you do?
We may be on the same page here. I don't like the way dev interviews are run and I think the focus on textbook algorithms is misplaced. I would say if your interview process can be aced by somebody hitting the books for a month, you're not testing for hard enough things.
I was just a little surprised about those particular items because I feel like they're such an essential background for all software development. But I don't think they should be quizzed for in an interview.
So, so many people do things the hard and reliable way, or don't do them at all and sacrifice some desired feature, because they don't recognize a well understood computer science problem lurking underneath a business problem or a UI implementation.
I'm not saying that's what anyone in this discussion is doing, just that I see it everywhere (and have done it myself). 1000s of lines of incomprehensible code because no one realized that this drag and drop flow chart creation interface can be understood as a graph.
> I would say if your interview process can be aced by somebody hitting the books for a month, you're not testing for hard enough things.
I'd say if someone can independently learn the things you think are important enough to interview around in a month then they're the sort of person you should be hiring, unless you don't expect new problems to ever emerge you'll need people who can develop their knowledge anyway.
This is why SV needs to stop abusing the term "engineer" - because this is indeed work that can be done on the front end, but under no circumstances should you expect front end developers to know how to do this. If you have a specific need, or you're building something very complex, then you probably want an engineer -- most companies (including any of the big ones) typically only need developers. It's good to have engineers tinkering with stuff though, that's how you wind up with things like React.
Oh yeah absolutely - not trying to take anything away from developers particularly. Different skill sets, but practically the same outcome most of the time. That's a great example of why knowing how to create a BST from scratch isn't the only knowledge needed to build great software.
I think OP's list of essential algorithms is a bit too long. I agree that knowing what a binary search is, or graph traversal, is something that everyone writing code should know, and something that does come up reasonably often. (And recursion, heh.)
But binary trees? Last time I needed them was in a CS class. Linked lists? They only came up when I had to convince a coworker that we really don't need to implement one in JS, we only have 50 items here, and someone is going to forget to update a linked list if we use one.
There ends up being a wide range of skills that fall into any classification and "front-end developer" is no different from what I see. For the majority of jobs, knowing html/css/js and modern js/css frameworks probably covers it. Your case sounds a little bit more specialized.
Then sometimes you see a "front-end developer" role and you find out it's actually a designer role.
I don't have a ton of actual front-end dev experience but when I get to do it in my consulting role I like it. So I'm trying to move into a role like that but the comments here make me think I don't have those skills. I don't have a strong CS background but was hoping I could still do front-end dev work. Then people are talking about algorithms and being a math minor and I'm not sure I could do that.
I think it is always good to know what kind of skills a candidate has besides what will be his average work, but could add to the skill set of the team and might come in handy.
Be that knowledge of data structures, algorithms, ui design, ux, project management or advertisment. Especially in startups where you can't afford dedicated teams for every aspect.
If the team is already strong on the design/ux front, I might favor a candidate with better cs fundamentals. And if my team mostly consists of the latter, I might favor a "worse" programmer but one who knows and cares about typography, color harmony, paper prototyping etc.
> I would never care about these if I was specifically hiring a front-end dev.
I would find these things very relevant if you were working on apps that deal with large datasets as picking the wrong data structure can lead to slow execution. It's also good to know what the limits of the candidate's knowledge is.
I've said it before and I'll say it again: "Ask every developer I've worked with at every job I've had in the industry questions related to these topics on the spot and 95% will fail."
An interview shouldn't be purely theoretical, but I disagree that there's no place for this stuff.
As an incredibly simple example that comes up all the time, if you get back a collection of items from an API do you store them in a hash keyed by id or in a list? If you can't reason about how e.g. lists are ordered but a hash has O(1) access, and use that to decide which is better in a particular case, you won't be a very strong front-end dev.
Not to mention if you need to dig into performance issues, e.g. dropping frames in animations or something.
I've also seen a lot of frontend bugs related to not thinking about/dealing with asynchronicity well. That's not a data structure problem per se, but you need a working knowledge of some basic CS concepts like threads, concurrency patterns, queues, etc.
I think the key in interviews is that this stuff shouldn't be evaluated like a school exam, where you need immediate recall of all the terms without stumbling. It's all about being able to work towards the right answer and it's fine if that involves a bit of asking or googling to double-check your ideas.
Expecting somebody to know the difference between a hash and an array is reasonable but you can hardly complain about a lack of qualified people if you disqualify JS applicants for not knowing what a trie is.
Agreed. Front-end developers should have experience using libraries that encapsulate collections, trees, sets, hashes, etc... and know when to use certain data structures.
But unless they're being hiring to develop a library, they don't need to have these algorithms memorized.
I'm confused. You've never even seen a hash table come up before? What sort of front-end work are you doing?
I just find this extremely unlikely if not borderline impossible. Hash tables are one of the most universal data structures in practical software development. This is just as true in JavaScript for front-end work as it is anywhere else.
Expecting somebody to know what a hash table is and understand the time complexity of inserting and looking up elements is fair. Expecting them to build one from scratch on a whiteboard is just ritualized hazing.
I don't see anyone mentioning requiring one to build all these data structures from scratch. I'd agree with you that this is a less useful exercise for interviews, in particular front-end interviews, but I don't think it's fair to assume that this is what the poster above meant. Only "basic knowledge" was mentioned.
I use js objects, of course, which are hash tables.
Would I hire a front-end developer who didn't know that, or didn't know that they had O(1) lookup time? Very possibly. Because there are so many things that are more important than that knowledge when you are actually building software for a business. Things like experience with usability testing, JS/CSS build tools, unit testing and refactoring, a decent eye for graphic design (even if they won't be doing that work themselves), an open-mind and lack of ego -- just off the top of my head, these are all things I'd consider orders of magnitude more important than knowing technical details about hash tables.
So, the first-half, no... never use. But depth/breadth first search, tries, recursion, hash tables... Absolutely use these as much in front-end as in back-end.
Can somebody provide a real example of where you'd need to use "linked lists, binary trees, min/max heaps, depth/breadth first search, tries, recursion, hash tables, etc" in your typical everyday front end angular/react/ember project?
Depth-first and breadth-first graph traversal does come up. Example: you're implementing a task tracking system, where tasks can have dependencies. Boom, that's a graph. You want to display a whole graph of dependencies of a task (and dependencies of dependencies, etc.). Boom, there's graph traversal. You need to limit the number of tasks displayed in that graph, because someone added a thousand dependencies somewhere and now the graph rendering is choking up. Boom, traverse breadth-first and stop displaying more tasks after some preset number. This is an actual issue I ran into in actual code.
Now, about most of the other things that were mentioned… I'm not convinced.
> Now, about most of the other things that were mentioned… I'm not convinced.
Your graph example could just as well also be a tree example depending on the structure of the dependencies. Hash tables show up everywhere. Recursion is a natural and general programming technique. That only leaves linked lists, tries, and heaps from the original list. I'd agree that these are less likely to pop up in general front-end development, but it's not impossible to imagine them being useful.
I'd rank the concepts from the list in this order (obviously very subjective):
- Hash tables. Universal concept in programming. If you don't know this, you don't know how to program.
- Recursion. General technique for structuring code. Not understanding this indicates a severe lack of exposure to code in general.
- Graphs. Lots of data is naturally structured as a graph. I think it's natural to include trees in this category as well.
- Linked lists. Classic data structure. They're mainly worth knowing about in order to be aware of their performance shortcomings with lots of data. It's less about knowing when to use one and more about knowing when not to use one.
- Heaps. When useful, they tend to be incredibly useful. But they're not all that useful for front-end development.
- Tries. Similar to heaps in this regard.
Personally, I think for a purely front-end role that won't be focusing on the development of new libraries but just the usage of existing ones, I'd focus only on hash tables from this list and use the rest of the interview for more targeted questions.
Right, recursion is elementary, I missed that one. (It's even pretty much a prerequisite for depth-first graph traversal.) As far hash tables, I agree it's important to vaguely know how they work and to know the performance characteristics, but I wouldn't consider it critical to know how to implement one from scratch.
I've used hash tables a fair amount in an order processing front-end app. In our batch order processing component, it was useful to hash the orders returned from the API on their "order_id" for fast and easy access to them in various stages of processing. You don't want to be using Array.find() every time you need to refer to an order.
> Even for a front-end developer you should have a basic knowledge of data structures like linked lists, binary trees, min/max heaps, depth/breadth first search, tries, recursion, hash tables, etc. These often come up in whiteboarding questions.
Most of these have not come up for me ever when interviewing with a strong frontend bent, even at companies like Google. Recursion has come up for me some (mostly for senior or higher positions), and knowing space/time complexity, but otherwise nothing super specific for frontend.
In the past year or so, I've been asked to live code various UI components at a fairly dependable clip, whether it be a typeahead/autocomplete, components with iteration (i.e. containing lists), and aligning various elements horizontally and vertically. Oftentimes these questions lead to various other questions while carrying out the implementations, probing for knowledge on various approaches and various tradeoffs/benefits of each approach.
Aside from all the technical questions, don't underestimate the importance of knowing about the company you are applying to.
I've hired several developers over the last 10 years, and by the final round, there are often candidates with similar technical ability. The applicant that really understands the company they are applying to work for (the current state of their app, their competition, the direction you think they may need to go) will have an edge.
I'm in the process of doing this and was told I needed to know sorting algorithms (among other things) so I made a barebones redux project to stuff it into. Not sure if this is your case but if it helps, take a look:
https://github.com/Outc4sted/AlgorithmAtelier/blob/master/sr...
Having gone through this situation before, my biggest mistake while performing this type of interview was not actually having candidates build something with the team. Frontend development is usually very visual and UX-oriented, so it's important to see what they can build and their attention to that type of detail. There's plenty of knowledge questions that can filter candidates down by experience, but until you get them working in your setting, you won't be able to see whether they can build something you actually want and get along with others in a team-oriented way. My suggestion is to give them a small project they can build during an interview with you/your team.
Couldn't agree with this more. When I originally read the OP's question, I assumed he was asking how to prepare as a candidate, and you gave a great answer for how to prepare as an interviewer -- the question is ambiguous and even on re-reading I'm not sure which he meant.
To add to your answer, having them build a clone of a simple game in 1-3 hours, especially when they have to balance a bare bones look with more features versus a slicker look with fewer features, and deciding which to cut and what's important to them and how they think about it -- all that can be revealing.
Before Babel, I often used to ask about code organization/modularization, mostly to filter out candidates who haven't been on a big project and have only copied and pasted jQuery snippets together; today I'd ask if you use Babel modules and why/why not.
As other people have said, closures will surely come out.
A favorite of mine is array functions: map, forEach, filter.
Also, promises, callbacks, workers.
Finally, xhr throttling.
Hopefully not! Surely _.debounce would be more appropriate to avoid locking out your UI - or worse, returning out of date responses - but even then you would potentially want to handle the responses more robustly.
Not to mention needing to handle .fetch()s lack of abort if you're not using xhr.
I usually supplement the interview with a take home project, because front end web dev (emphasis on web) is about building interfaces and managing state really well and that is hard to test in an hour!
Some of the more domain specific stuff is about building a scalable components library that your team can use, testing your code, building assets in the most elegant way possible (gulp, webpack, grunt). So make sure you're very honest with your resume!! (dishonesty is bad).
For the case of front end web, here is what I would ask from the top of my head (thinking aloud):
- A good interview will have some pair programming. I usually like to give a very simple mock. These mocks will have a simple task where I will ask you to implement me a two column layout, or a popup window. Therefore I'd like to see that you have strong fundamentals of CSS, HTML, and Basic DOM manipulation using JavaScript. Nice interviewers will allow the use of google!
- You should understand how a network request and response works. I'll probably ask you to teach me what an AJAX request is to start. I hope to have a good conversation because I forget things often and like to learn from others.
- I will probably ask you what are some ways to implement components that won't produce side effects in a large codebase.
- I will probably ask you questions about how you plan to work with Design and other product stakeholders to ensure that you're able to iterate quickly on the front end. This is because requirements and design changes frequently (more common with companies that are focused on product versus growth/retention).
- I will ask you how you approach testing, and how do you ensure your interface will work cross browser, cross device.
- If you're really a generalist and you have no front end experience but a lot of other programming experience, I'll probably ask you to serialize a network response with JSON, where you'll create a map of ids and their resources (for fast access!) and walk through an object tree to do this. We can probably pseudo code this if you've never touched JavaScript and know nothing about its data structures (this jon snow case is rare, like jon snow).
- If you're really junior I'll ask you a generic algorithm question because I'm probably going to train you on the job anyways. No one should be punishing junior people for being junior with stupidly difficult domain specific questions. Don't work somewhere where they punish you for being junior because they won't realize how much potential you have (you have a lot).
Last note: Good luck and have fun, remember to be yourself and try your best.
Im not an expert in frontend but key concepts kind of remains same across frontend design: MV*, pub-sub patterns, what not to do in a UI-thread, lifecycle of a page/view load, talk through on how candidate goes about representing a given json/xml data to a web page - can candidate show his skills in choice-and-usage of UI elements here.
Data structures.
Then specifics about language and framework.
Knowledge based questions like comparing frameworks - pros and cons. Technical challenges overcome in previous roles.
For general programming questions I found https://www.interviewbit.com/ very good. It is both a tutorial and programming questions at the same time.
I was asked to describe the important properties of a hash map in a telephone interview. The interview contained less technical questions but various developers asked me about all areas of my CV. There was also a HTML/CSS/JS coding exercise to create a small application to a spec that they gave.
So expect to get questions on anything that you've put in your CV. If you're not familiar enough with it - take it out of your CV.
It heavily depends on the company and area I'd say.
At my company, an IT-Consultancy in Germany, the junior-position-baseline is a solid understanding of HTML and CSS, and at least a basic grasp of Javascript.
For mid-level-positions I expect "fluency" in all of those areas, plus a good knowledge of standard-tools and accessibility.
I also look for a good foundation in either design or CS, depending on the interviewees background.
The interview is the same for every level, though we look for different things of course. We ask the applicants to set up a basic front-end-file-structure and to start coding a design we created specifically for interviews. During that we ask them to think aloud and talk about the reasons they do things the way they do.
The second exercise is a palindrome-function in JS (or on the whiteboard for juniors).
They seem like simple tasks, but you wouldn't believe how many interviews we had where the person couldn't even code an img-tag from mind.
I understand that at Valley-Companies/Start-Ups, Frontend-Development includes many more advanced topics than in our case.
It really depends on the job you're applying for. If you're applying for a job at a company that provides SaaS on a particular software stack that's gonna be really different than applying at a work-for-hire web development house. There's really not enough information here for me to give you any kind of useful advice. If you'r qualified for the job you should know the basics that are applicable to just about any front end web developer job.
I'd try to find out as much as you can about what the company you're applying to does so you can get familiar with that stuff.
I got one of my best roles like this. Admittedly there was also a part where I was asked to share my laptop's screen and after one look the guy said "ok you're hired."
I'm a front-end dev going through the hiring process right now. Here's a list of some of the questions I have been asked in technical interviews:
- What is a clojure?
- What is a callback?
- What is an IIFE?
- How can you use scope to keep a copy of i in a loop?
- What is going on when you click a link to go to a website?
- Difference between classical inheritance vs prototypical
- Difference between object-oriented programming vs functional
- Knowing what 'this' is referencing at different points inside a function/class
- Difference between <p>, <div> and <span>
- Difference between css selectors: '.classA.classB', '.classA .classB', '.classA > .classB'
- Difference between 'x is undefined' and 'x is not defined' error messages
Programming problems:
- Calculating fibonacci numbers
- Depth-first binary tree search
- Turning a hashmap with multiple levels of embedded hashmaps inside-out
- Handling API response data to create new objects
- Creating a login form
- Using media queries to make responsive pages
- Determine if word is a palindrome
- Using recursive functions
Knowing methods to reduce computation time and space with hashmaps and arrays is important. You will also be asked to state the computation time and space of your solutions
Framework-specific questions:
- What is the difference between a component and a directive? (AngularJS)
- What is the difference between a service and a directive? (AngularJS)
I'm sure there's more I've forgotten.
https://www.interviewcake.com/ and Hackerrank can prepare you for programming problems but outside of the giants you don't often get asked these.
Same way you prepare for any other interview - you don't.
There are a ton of developer positions, after going through about 5-10, you'll know every question they ask you, off the top of your head.
So there's no need to stress or prepare - you'll screw up the first few and it'll get easier going forward.
The mindset you should be coming in with is I'm a new guy, willing to learn and work the extra hours. I don't know everything and will need a little mentoring to get me going - if you don't offer that, that's ok, there's plenty of other places that do.
You're just starting out - you'll get screwed on salary and get worked to the bone for the first few years until you learn to say no. The advice I'd give is have a little more confidence in your inner voice that tells you when you're getting fucked - and know that you're right.
In general, don't pretend to be someone you are not. If you don't know something, just say "I don't know this, but I learn quickly". Being flexible, open-minded and easy-adapting is much more important today than knowledge of specific languages, algorithms or frameworks. Google knows everything, you only need to be able to ask it right questions and handle the answers. So, just be ready to prove that you are such kind of person.
Most modern production quality software systems there days are implementing fibonacci algorithms as part of their core business rules, controlled via a red/black tree. Usually it's held together by a fizzbuzz architecture so as a minimum you should be able to whiteboard fizzbuzz. You should understand all these things well, and really if you are doing modern software development these things hould be day to day tasks anyway so they should be top of mind.
Ah interviews; when you realize all your programs have been opening all the files they need to for months and you can't remember the exact syntax for opening files in any of the half-dozen+ languages you've written production code in.. :D
Fizz/buzz, graph traversal, and etc actually come much more easily for me haha.
Honest question: People always joke about this, but is it really so widespread? I only had one job interview in my life until now, and that did not have any tech questions because my CV and open-source portfolio made it reasonably clear that I can, in fact, write working programs.
In Europe, it is mostly the cool startups that think they are in Silicon Valley that ask for fizzbuzz, tree balancing algorithms, optimization algorithms for HD access and such.
Most business do ask for technical questions, but more like how do the UML diagram of some architecture, how to write SQL queries, implement some code to make their unit tests green, describe what is virtual method dispatch and so on.
I agree that it's far from what is needed in everyday tasks, but in defense of that process: if you are unable to implement fizzbuzz, Fibonacci numbers, etc., I am almost sure you can't understand react sagas or dependency injection properly. Mixed with more open-ended questions (why was React built? how does it compare to Angular? What's a generator function?), I believe this isn't the worst type of interview.
See the other side: a significant number of applicants can't implement fizzbuzz, Fibonacci sequences or anything, but ask for ridiculous salaries and their portfolios appear to be mostly borrowed plumes. We need a process that isn't too time-consuming to id the chaff, allowing for false negatives (people who are good at Fibonacci numbers and interview questions, but not much else), but keeping the false positives low (I explain the Fibonacci sequence first so it doesn't become a math riddle rather than a programming task).
When you aren't being forthright with the position you held on a development team. If you were a late onboard to a project and spent your time firefighting bug reports, you could perhaps lend cachet to your resume by omitting the relatively minor role you had in the project. Then you'd be borrowing the "plume in your cap" from your team, who deserves more of the credit.
edit: this is my best-fit guess. I have no idea what I'm talking about.
All of this advice is especially relevant to a Front End Developer role. You'll want to go into this thing having a solid grasp of Big-O notation runtime efficiency of your favorite UI algorithms.
I had to demonstrate how to inverse the value of an immutable object hashed data stream whilst ensuring that the dilithium matrix array was phase decoupled.
Seriously just be yourself, don't over think it. If you don't know something, don't be afraid to so, but you're keen to learn if it is something useful. You can't know everything, no one can, just be confident in the things you do know. Nothing worse than a faker, you'll be caught out anyway, you're going to be judged on your strengths not your weaknesses, unless the employer is crappy, and you wouldn't want to work for them anyway.
Here are a few questions/problems I was asked in from-end interviews a couple months ago:
Write a function that accepts an array of ints and a target number. If two of the numbers in the array can add up to the target, return their indices. (aka Two Sum)
Write a function that accepts an int x and prints a spiral of "#"s so that the number of "arms" in the spiral equals x.
Write a function that accepts a month and a year, and draws a calendar view of that month.
Given a non-negative int x, repeatedly add all its digits until the result has only one digit.
I think I was also asked something that involved a tree structure, but I can't remember the specific problem.
I thought all of those questions were fucking stupid. The good interviewers, IMO, gave me a "take-home" problem of building some mini front-end app that hit an API, and the really fun one involved reverse engineering an unpublished API - that's how I got my current job.
I spent a lot of time studying the h5bp Front End Interview Questions[1], and the only front-end specific question I was asked was, "What is an SVG sprite?" during an initial phone chat with a CEO.
>>The good interviewers, IMO, gave me a "take-home" problem of building some mini front-end app that hit an API, and the really fun one involved reverse engineering an unpublished API - that's how I got my current job.
I agree with you, but whenever this subject comes up, a lot of folks here on HN complain that they have full-time jobs and families and don't have time for "take-home" questions.
I understand that point, but I just personally hate the stress and the irrelevance of the "over-the-shoulder" algorithm problems that a recent CS grad would be almost more suited to answering. If I'm really interested in working for a company, I have no issue spending a couple hours building a little app to prove my chops.
Next, if things are going well, I have the candidate transform a JSON collection response to match some arbitrary requirements using Lodash/Underscore.
After that, I focus on the candidate's experience and talk about projects they've worked on, their process and what they're looking for in their next position.
If you're a front-end candidate that's solid at design, visualizations or complex layouts, I'd encourage you to bring your personal laptop and show off some of the work you've done on your own.
It's not meant to be difficult. You'd be surprised how many people don't pass this. The most important part of the interview for me is when we advance to talking about what a candidate has actually done.
That's my point, I've read many times that I'd be surprised how many times people don't pass this (and I agree) but I'd love to know how many. Could you share please?
Generally the candidates that don't pass that first question don't have sufficient experience with JavaScript. Sometimes this is because they have more experience on the backend and for whatever reason said they knew JavaScript on their resume and found themselves in the frontend portion of a fullstack interview. Other times the candidate has a lot of experience with CSS and layouts, but doesn't have much experience with JavaScript beyond jQuery. Out of five candidates, two might fail this... but it comes down to the candidates in the pipeline. Working closely with your recruiters can take that number down to zero. I've found that filters like this become more necessary when there are a lot of positions to fill.
This would work, but attrs should really be an object (i.e. var attrs = {};), not an array, since you're storing string keys, and stylistically you can just use e.g. attrs.name instead of attrs['name'].
145 comments
[ 2.5 ms ] story [ 202 ms ] threadYou may not think databases are a front-end topic, but I have been asked about them on more than one occasion. Prepare to talk about sharding, natural primary keys, what your favorite database is and why, etc.
Something that has been extremely useful for me is to have a project that I've built myself to show and talk about during the interview. Although I have had one interview where I was asked to talk in detail about how I built some of my projects that are in my github, I like to respond to general technical questions while referencing something I've built. A lot of times the interviewer will then use my app as a starting point into a discussion for how I would scale it. Here's an example of an app I built quickly and have used for discussion in interviews: http://moviemap.xyz/ More here: http://valeriemettler.com/
Opinions will differ, but IMHO closure is a great concept to divide those who know JS at a conceptual level (or at least have crammed for the interview) from those who don't.
What I also like about it is that a closure isn't the only way to solve it. You can use `let` for example to make sure the variables are block scoped, or use `bind` to partially apply a function with the number.
So in the end it's a conceptually very simple exercise that can give you a very good insight into how much the candidate knows about how JS actually works.
If you haven't already read them, I highly recommend the You Don't Know JS series of books. One of them covers this exact question.
https://github.com/getify/You-Dont-Know-JS
As an interviewer I can see why you would want to force someone to jump through arbitrary hoops like that but if someone can show me `() => i` and explain why that works, that would be good enough for me.
In fact I would argue it's important that if the candidate shows practical knowledge of ES6 you need to make sure they also grasp the actual semantics (i.e. they won't rely on implementation details of Babel and run into errors in native ES6 environments).
That said, if you are hiring for a dedicated frontend developer role, the majority of JS you write will have a build step. If it has a build step, you should use modern tooling. If you use modern tooling, you might as well include Babel to make the developers' lives less of a pain.
I think the best preparation you can do is to spend several hours reviewing your old projects.
For each project, recall and be prepared to explain in depth:
- The biggest technical challenge you faced and how your team solved it
- The technical tradeoffs your team made in the implementation, and whether you would make the same tradeoffs today
- What your specific contributions were to that project.
- If you can bring code that's great; if not then have the high-level design in your head and be ready to outline and explain it.
If you're anything like me, for three or four projects that represents a couple days or more of preparation.
I think the front-end interviews I’ve been to and run are different to the ones you have.
I don't know about that, but you should at least know the algorithms necessary to traverse the DOM.
Ideally you'll get mostly questions that are relevant to what your job will be, but I wouldn't be surprised to see some CS stuff in there as well (basic data structures & algorithms). Good luck!
[0]: http://h5bp.github.io/Front-end-Developer-Interview-Question...
You should be familiar with what ES6 is and what Babel does. These technologies probably won't be specific questions per se but if they come up and you can't speak about them, it'd be a red flag.
Even for a front-end developer you should have a basic knowledge of data structures like linked lists, binary trees, min/max heaps, depth/breadth first search, tries, recursion, hash tables, etc. These often come up in whiteboarding questions.
Practice whiteboarding on an actual whiteboard so you get used to writing code then practice on hackerrank so you get used to quickly writing code that actually compiles. Some companies only use whiteboards, others want your code to run.
Make sure you think of test cases for your problems. TDD in an interview is usually a good sign.
Usually knowing this stuff and having some sample code will usually get you through most of the interview. Knowing the specific things mentioned in other comments is useful, but I can't imagine not hiring someone because they didn't know some specific CSS selector or how to use flexbox.
Other tips - don't get visibly flustered, talk your way through problems. Stay postive about past employers. Good luck!
I would never care about these if I was specifically hiring a front-end dev. I've never once seen any of them come up in the context of front-end work in my entire career. And in fact an interviewer asking questions about them would be a huge red flag for someone who prioritizes nerd-cred over actual business needs, and is therefore likely to make poor decisions.
Yeah I would assume so. Of course if know the job requires such knowledge, you should interview for it. But I'm thinking of more average front-end work, where you'd be building forms or dashboards or ordinary websites.
It sounds like you're building a complex application that just happens to be hosted in a browser. Although even then, I'd argue that while your knowledge of when to apply those algorithms is important, you still shouldn't be writing them yourself. You should be finding a well-vetted library and taking the function from there.
I was just a little surprised about those particular items because I feel like they're such an essential background for all software development. But I don't think they should be quizzed for in an interview.
I'm not saying that's what anyone in this discussion is doing, just that I see it everywhere (and have done it myself). 1000s of lines of incomprehensible code because no one realized that this drag and drop flow chart creation interface can be understood as a graph.
I'd say if someone can independently learn the things you think are important enough to interview around in a month then they're the sort of person you should be hiring, unless you don't expect new problems to ever emerge you'll need people who can develop their knowledge anyway.
linked list, binary tree, dijkstra's algo - which one did you use? Why did you not settle with a O(n^3) or worse brute force?
But binary trees? Last time I needed them was in a CS class. Linked lists? They only came up when I had to convince a coworker that we really don't need to implement one in JS, we only have 50 items here, and someone is going to forget to update a linked list if we use one.
Then sometimes you see a "front-end developer" role and you find out it's actually a designer role.
I don't have a ton of actual front-end dev experience but when I get to do it in my consulting role I like it. So I'm trying to move into a role like that but the comments here make me think I don't have those skills. I don't have a strong CS background but was hoping I could still do front-end dev work. Then people are talking about algorithms and being a math minor and I'm not sure I could do that.
Be that knowledge of data structures, algorithms, ui design, ux, project management or advertisment. Especially in startups where you can't afford dedicated teams for every aspect.
If the team is already strong on the design/ux front, I might favor a candidate with better cs fundamentals. And if my team mostly consists of the latter, I might favor a "worse" programmer but one who knows and cares about typography, color harmony, paper prototyping etc.
I would find these things very relevant if you were working on apps that deal with large datasets as picking the wrong data structure can lead to slow execution. It's also good to know what the limits of the candidate's knowledge is.
As an incredibly simple example that comes up all the time, if you get back a collection of items from an API do you store them in a hash keyed by id or in a list? If you can't reason about how e.g. lists are ordered but a hash has O(1) access, and use that to decide which is better in a particular case, you won't be a very strong front-end dev.
Not to mention if you need to dig into performance issues, e.g. dropping frames in animations or something.
I've also seen a lot of frontend bugs related to not thinking about/dealing with asynchronicity well. That's not a data structure problem per se, but you need a working knowledge of some basic CS concepts like threads, concurrency patterns, queues, etc.
I think the key in interviews is that this stuff shouldn't be evaluated like a school exam, where you need immediate recall of all the terms without stumbling. It's all about being able to work towards the right answer and it's fine if that involves a bit of asking or googling to double-check your ideas.
But unless they're being hiring to develop a library, they don't need to have these algorithms memorized.
I just find this extremely unlikely if not borderline impossible. Hash tables are one of the most universal data structures in practical software development. This is just as true in JavaScript for front-end work as it is anywhere else.
Would I hire a front-end developer who didn't know that, or didn't know that they had O(1) lookup time? Very possibly. Because there are so many things that are more important than that knowledge when you are actually building software for a business. Things like experience with usability testing, JS/CSS build tools, unit testing and refactoring, a decent eye for graphic design (even if they won't be doing that work themselves), an open-mind and lack of ego -- just off the top of my head, these are all things I'd consider orders of magnitude more important than knowing technical details about hash tables.
Now, about most of the other things that were mentioned… I'm not convinced.
Your graph example could just as well also be a tree example depending on the structure of the dependencies. Hash tables show up everywhere. Recursion is a natural and general programming technique. That only leaves linked lists, tries, and heaps from the original list. I'd agree that these are less likely to pop up in general front-end development, but it's not impossible to imagine them being useful.
I'd rank the concepts from the list in this order (obviously very subjective):
- Hash tables. Universal concept in programming. If you don't know this, you don't know how to program.
- Recursion. General technique for structuring code. Not understanding this indicates a severe lack of exposure to code in general.
- Graphs. Lots of data is naturally structured as a graph. I think it's natural to include trees in this category as well.
- Linked lists. Classic data structure. They're mainly worth knowing about in order to be aware of their performance shortcomings with lots of data. It's less about knowing when to use one and more about knowing when not to use one.
- Heaps. When useful, they tend to be incredibly useful. But they're not all that useful for front-end development.
- Tries. Similar to heaps in this regard.
Personally, I think for a purely front-end role that won't be focusing on the development of new libraries but just the usage of existing ones, I'd focus only on hash tables from this list and use the rest of the interview for more targeted questions.
Most of these have not come up for me ever when interviewing with a strong frontend bent, even at companies like Google. Recursion has come up for me some (mostly for senior or higher positions), and knowing space/time complexity, but otherwise nothing super specific for frontend.
In the past year or so, I've been asked to live code various UI components at a fairly dependable clip, whether it be a typeahead/autocomplete, components with iteration (i.e. containing lists), and aligning various elements horizontally and vertically. Oftentimes these questions lead to various other questions while carrying out the implementations, probing for knowledge on various approaches and various tradeoffs/benefits of each approach.
That's a nice thought, but what if your past employer was Oracle? Doesn't honesty count for anything?
I've hired several developers over the last 10 years, and by the final round, there are often candidates with similar technical ability. The applicant that really understands the company they are applying to work for (the current state of their app, their competition, the direction you think they may need to go) will have an edge.
To add to your answer, having them build a clone of a simple game in 1-3 hours, especially when they have to balance a bare bones look with more features versus a slicker look with fewer features, and deciding which to cut and what's important to them and how they think about it -- all that can be revealing.
var a = 10; var fn = function (x) { return x + a}; fn(10); ==> 20 var a = 1; fn(10) ==> 11 //WAT ??
Is the above fixed with ES2015 ? Closures need to enclose values and not references.
1. You can solve that already in ES6, by returning fn from a function, also avoiding the global variable;
2. Your ES3 linter should warn you about the redefined variable.
Not to mention needing to handle .fetch()s lack of abort if you're not using xhr.
Some of the more domain specific stuff is about building a scalable components library that your team can use, testing your code, building assets in the most elegant way possible (gulp, webpack, grunt). So make sure you're very honest with your resume!! (dishonesty is bad).
For the case of front end web, here is what I would ask from the top of my head (thinking aloud):
- A good interview will have some pair programming. I usually like to give a very simple mock. These mocks will have a simple task where I will ask you to implement me a two column layout, or a popup window. Therefore I'd like to see that you have strong fundamentals of CSS, HTML, and Basic DOM manipulation using JavaScript. Nice interviewers will allow the use of google!
- You should understand how a network request and response works. I'll probably ask you to teach me what an AJAX request is to start. I hope to have a good conversation because I forget things often and like to learn from others.
- I will probably ask you what are some ways to implement components that won't produce side effects in a large codebase.
- I will probably ask you questions about how you plan to work with Design and other product stakeholders to ensure that you're able to iterate quickly on the front end. This is because requirements and design changes frequently (more common with companies that are focused on product versus growth/retention).
- I will ask you how you approach testing, and how do you ensure your interface will work cross browser, cross device.
- If you're really a generalist and you have no front end experience but a lot of other programming experience, I'll probably ask you to serialize a network response with JSON, where you'll create a map of ids and their resources (for fast access!) and walk through an object tree to do this. We can probably pseudo code this if you've never touched JavaScript and know nothing about its data structures (this jon snow case is rare, like jon snow).
- If you're really junior I'll ask you a generic algorithm question because I'm probably going to train you on the job anyways. No one should be punishing junior people for being junior with stupidly difficult domain specific questions. Don't work somewhere where they punish you for being junior because they won't realize how much potential you have (you have a lot).
Last note: Good luck and have fun, remember to be yourself and try your best.
Data structures.
Then specifics about language and framework.
Knowledge based questions like comparing frameworks - pros and cons. Technical challenges overcome in previous roles.
I was asked to describe the important properties of a hash map in a telephone interview. The interview contained less technical questions but various developers asked me about all areas of my CV. There was also a HTML/CSS/JS coding exercise to create a small application to a spec that they gave.
So expect to get questions on anything that you've put in your CV. If you're not familiar enough with it - take it out of your CV.
At my company, an IT-Consultancy in Germany, the junior-position-baseline is a solid understanding of HTML and CSS, and at least a basic grasp of Javascript. For mid-level-positions I expect "fluency" in all of those areas, plus a good knowledge of standard-tools and accessibility. I also look for a good foundation in either design or CS, depending on the interviewees background.
The interview is the same for every level, though we look for different things of course. We ask the applicants to set up a basic front-end-file-structure and to start coding a design we created specifically for interviews. During that we ask them to think aloud and talk about the reasons they do things the way they do.
The second exercise is a palindrome-function in JS (or on the whiteboard for juniors).
They seem like simple tasks, but you wouldn't believe how many interviews we had where the person couldn't even code an img-tag from mind.
I understand that at Valley-Companies/Start-Ups, Frontend-Development includes many more advanced topics than in our case.
I'd try to find out as much as you can about what the company you're applying to does so you can get familiar with that stuff.
Programming problems: - Calculating fibonacci numbers - Depth-first binary tree search - Turning a hashmap with multiple levels of embedded hashmaps inside-out - Handling API response data to create new objects - Creating a login form - Using media queries to make responsive pages - Determine if word is a palindrome - Using recursive functions
Knowing methods to reduce computation time and space with hashmaps and arrays is important. You will also be asked to state the computation time and space of your solutions
Framework-specific questions: - What is the difference between a component and a directive? (AngularJS) - What is the difference between a service and a directive? (AngularJS)
I'm sure there's more I've forgotten.
https://www.interviewcake.com/ and Hackerrank can prepare you for programming problems but outside of the giants you don't often get asked these.
There are a ton of developer positions, after going through about 5-10, you'll know every question they ask you, off the top of your head.
So there's no need to stress or prepare - you'll screw up the first few and it'll get easier going forward.
The mindset you should be coming in with is I'm a new guy, willing to learn and work the extra hours. I don't know everything and will need a little mentoring to get me going - if you don't offer that, that's ok, there's plenty of other places that do.
You're just starting out - you'll get screwed on salary and get worked to the bone for the first few years until you learn to say no. The advice I'd give is have a little more confidence in your inner voice that tells you when you're getting fucked - and know that you're right.
That's more important :)
Fizz/buzz, graph traversal, and etc actually come much more easily for me haha.
Most business do ask for technical questions, but more like how do the UML diagram of some architecture, how to write SQL queries, implement some code to make their unit tests green, describe what is virtual method dispatch and so on.
See the other side: a significant number of applicants can't implement fizzbuzz, Fibonacci sequences or anything, but ask for ridiculous salaries and their portfolios appear to be mostly borrowed plumes. We need a process that isn't too time-consuming to id the chaff, allowing for false negatives (people who are good at Fibonacci numbers and interview questions, but not much else), but keeping the false positives low (I explain the Fibonacci sequence first so it doesn't become a math riddle rather than a programming task).
I don't understand this phrase. What do you mean by borrowed plumes?
edit: this is my best-fit guess. I have no idea what I'm talking about.
Seriously just be yourself, don't over think it. If you don't know something, don't be afraid to so, but you're keen to learn if it is something useful. You can't know everything, no one can, just be confident in the things you do know. Nothing worse than a faker, you'll be caught out anyway, you're going to be judged on your strengths not your weaknesses, unless the employer is crappy, and you wouldn't want to work for them anyway.
Good luck.
-Variable hoisting
-Es6/Es2016
-Experience with react, angular, or another modern js framework
-Do you understand build tooling? Webpack? It's becoming a standard.
Css:
-Given a task of basic ui animation, are you still using js or have you adopted css transitions and animations?
-Do you have experience with sass or less? Opinions?
Html5:
-Know it.
Http2
-How will this affect your life as a front end developer?
Tradecraft:
-What can you do when working with designers to make handoff easier?
-When is something good enough to ship?
-how do you learn a new, complicated code base?
Write a function that accepts an array of ints and a target number. If two of the numbers in the array can add up to the target, return their indices. (aka Two Sum)
Write a function that accepts an int x and prints a spiral of "#"s so that the number of "arms" in the spiral equals x.
Write a function that accepts a month and a year, and draws a calendar view of that month.
Given a non-negative int x, repeatedly add all its digits until the result has only one digit.
I think I was also asked something that involved a tree structure, but I can't remember the specific problem.
I thought all of those questions were fucking stupid. The good interviewers, IMO, gave me a "take-home" problem of building some mini front-end app that hit an API, and the really fun one involved reverse engineering an unpublished API - that's how I got my current job.
I spent a lot of time studying the h5bp Front End Interview Questions[1], and the only front-end specific question I was asked was, "What is an SVG sprite?" during an initial phone chat with a CEO.
1. https://github.com/h5bp/Front-end-Developer-Interview-Questi...
I agree with you, but whenever this subject comes up, a lot of folks here on HN complain that they have full-time jobs and families and don't have time for "take-home" questions.
Write a function that enables the following API...
Next, if things are going well, I have the candidate transform a JSON collection response to match some arbitrary requirements using Lodash/Underscore.After that, I focus on the candidate's experience and talk about projects they've worked on, their process and what they're looking for in their next position.
If you're a front-end candidate that's solid at design, visualizations or complex layouts, I'd encourage you to bring your personal laptop and show off some of the work you've done on your own.
var createOlympian = function() { return (function() { var attrs = []; // private variable for our olympian attributes
};