What do the front-end interviews of the big companies like to ask?

Over the past few years, I've interviewed a lot of web developers and software engineers at Amazon and Yahoo focused on front-end development, and in this article, I'd like to share some interview tips to help candidates prepare for the interview.

Disclaimer - This article is not intended to list all the questions that might be asked in a front-end interview, but it can be considered a baseline of knowledge.

Interviewing is not easy, and as a candidate, you often need to show what you can do in 45 minutes. A s an interviewer, it is also difficult to assess the suitability of a candidate in such a short period of time. There is no one-size-fits-all approach to an interview, and the interviewer usually asks a range of questions, but beyond that, they can decide for themselves what other questions to ask.

As a former candidate and interviewer, I'm trying to cover in this article the most important front-end development knowledge you might be asked about in an interview.

Common misconceptions

One of the biggest mistakes I've ever seen a candidate make is == to prepare trivial questions, such as "What is a box model" or "What's the difference === a JavaScript. It's good to know the answers to these questions, but it doesn't tell the interviewer much useful information.

Instead, in a real interview, you might want to write code using JavaScript, CSS, and HTML. D uring your interview, you may need to implement a UI, build widgets, or write common utility functions using libraries like Lodash and Underscore .js. For example:

• Build the layout and interactions of common Web applications, such as those on Netflix sites.
• Implement widgets, such as date selectors, carousels, or e-commerce site shopping carts.
• Write a function similar to a debounce or depth clone object.

Speaking of libraries, another mistake I see candidates often make is that they need to rely entirely on the latest framework to solve interview questions. Y ou might think, if I could use jQuery, React, Angular, and so on in a production environment, why wouldn't I use them in an interview? T echnology, frameworks, and libraries change over time - I'm more interested in whether you understand the underlying principles of front-end development than relying on higher levels of abstraction. If you can't answer interview questions without them, I hope you can at least fully explain and speculate on the principles behind these libraries.

In general, most interviews involve actual coding.

JavaScript

You need to know JavaScript, and you need to know it thoroughly. T he higher the position you are interviewing for, the higher the requirements for language knowledge. Here are the JavaScript knowledge points you should be familiar with:

• Execution context, especially lexical scope and closure;
• promotion, function and block scopes, and function expressions and declarations;
• Bindings - especially call bind apply and this
• Object prototypes, constructors, and mixin
• combination and higher-order functions;
• Event delegates and bubbling;
• Type conversion using typeof instanceof and Object.prototype.toString
• Use callbacks, promise await and async to handle asynchronous calls;
• When function declarations and expressions can be used.

DOM

It's important to know how to traverse and manipulate doMs, and candidates who rely heavily on jQuery or develop a lot of React-Angular-type applications may struggle with this issue. Y ou may not come into direct contact with DOM every day because most of us use various abstractions. Without using third-party libraries, you need to know how to do the following:

• Use document.querySelector to select or find nodes and use document.getElementsByTagName in legacy browsers;
• Up and down - Node.parentNode Node.firstChild Node.lastChild and Node.childNodes
• Left and right traversal - Node.previousSibling and Node.nextSibling
• Action - Add, delete, copy, and create nodes in the DOM tree. You should know how to modify the text content of a node and to switch, delete, or add CSS class names;
• Performance - When there are many nodes, the cost of modifying the DOM can be high, and you should at least know how to use document fragments and node caches.

CSS

At the very least, you should know how to lay out elements on a page, how to use child elements or direct descendant selectors to locate elements, and when to use classes and when to use IDs.

• Layout - arranging the location of elements adjacent to each other, and how to arrange elements into two or three columns;
• Responsive design - changing the size of elements according to the size of the browser width;
• Adaptive design - changing the size of elements according to a specific breakpoint;
• Specificity - how to calculate the specificity of the selector and how cascades affect attributes;
• Appropriate namespace and class naming.

HTML

Know which HTML tags best represent what you're displaying and related properties, and you should have manual knowledge.

• Semantic markers;
• Tag properties, such as disabled async defer and when to use data-*
• Know how to declare doctype (most people don't write new pages every day, so they might forget this) and what meta tags can be used;
• Accessibility issues, such as ensuring that the input check box has a larger response area (use the label for There's also role="button" role="presentation" and so on.

System design

In system design, knowledge such as MapReduce, distributed key-value storage systems, or CAP theorems is often involved. W hile front-end engineers don't need to have a deep day-to-day understanding of how to design such systems, you shouldn't be surprised to be asked to design front-end architectures for common applications. T hese questions are often vague, such as "Design a website like Pinterest" or "How do I build a shopping checkout service?" ” 。 Here are some things to consider:

• Rendering - Client Rendering (CSR), Server-side Rendering (SSR), and Global Rendering;
• Layout - If you are designing a system that is used by multiple development teams, you need to consider componentization and whether you need the development team to use components by specifying tags;
• State management, such as choosing between one-way traffic or two-way data binding. You should also consider whether your design uses a passive or reactive programming model and how components relate to each other, such as Foo-> Bar or Foo->Bar;
• Asynchronous - Your components may need to communicate with the server in real time. Y ou need to consider using XHR or bidirectional calls when designing. I f your interviewer asks you to support an old browser, you'll need to choose between hiding iFrame, script tags, or XHR. If not, you can recommend using websocket, or using a server to send events (SSE), which is better;
• Separation of concerns - Model-View-Controller (MVC), Model-View-ViewModel (MVVM) and Model-View-Presenter (MVP) modes;
• Multi-device support - Does your implementation support both web, mobile, and hybrid applications, or does it provide a separate implementation for each scenario? If you're building a website like Pinterest, you might consider using three columns on the web, but only one on a mobile device, and how your design will handle this problem;
• Asset file delivery - In large applications, it is common for independent teams to have their own code base. T hese different code banks may depend on each other, and each often has its own pipeline to publish code changes. Y our design needs to consider how to build (code split), test (unit and integration tests), and deploy asset files based on dependencies. You also need to consider how to reduce network latency by delivering asset files through CDNs or inline them.

Web performance

In addition to common programming best practices, you should expect visitors to review your code or design and its performance impact. It used to be enough to put CSS at the top of the document, and JS scripts at the bottom of the page, but the web is moving fast, and you should be familiar with the complexity of this area.

• Critical rendering path;
• Service Worker；
• Image optimization;
• Delay loading and bundling splits;
• THE GENERAL MEANING OF HTTP/2 AND SERVER PUSH;
• When to pre-pick and preload resources;
• Reduce browser backflow and when elements are promoted to the GPU;
• The difference between browser layout, composition, and drawing.

Data structures and algorithms

This may be a bit controversial, but having a basic understanding of Big-O time complexity and common runtimes such as O(N) and O (N Log N)) won't be a bad thing for you. S ingle-page applications are now very common, so it's helpful to know something about memory management and more. For example, if you are asked to build a client spell checker, understanding common data structures and algorithms will make your task much easier.

I'm not saying you'll need to take a computer degree, but the industry has moved from building simple web pages to computer science. There are many resources on the Internet that can give you a quick grasp of the basics.

General web knowledge

You need to master some of the technologies and paradigms that make up the Web.

• HTTP requests - GET and POST, as well as related headers such as Cache-Control, ETag, Status Codes, and Transfer-Encoding;
• REST and RPC;
• Security - When to use JSONP, COR, and iFrame.

summary

For a Web developer or engineer, building a Web application requires a lot of knowledge. Don't be limited by the depth of knowledge, but keep an open mind to learn all the complex parts.

In addition to the technical topics covered here, you'll need to discuss past projects, describe what interesting things have happened, and what trade-offs have been made.

The source of the article | Top of the front end

To learn more about programming, go to the W3Cschool website and learn programming anytime, anywhere.