Original text: davidshariff.com/blog/prepar…

By David Shariff (UI Infrastructure Team Leader, Amazon)

Crazy tech nerd

Over the years, I’ve interviewed a number of front-end engineers at Amazon and Yahoo. In this article, I want to share some tips to help you prepare.

Disclaimer: The purpose of this article is not to give you a list of questions you might be asked in a front end interview, but consider it a knowledge base.

Interviews are hard work. As a candidate, you are usually given 45 minutes to show off your skills. As an interviewer, it is also difficult to assess whether the person is right for the job in such a short period of time. When it comes to interviews, there is no one size fits all, and interviewers often cover a certain area, but beyond that, they decide for themselves what questions to ask.

No matter which side of the interview table you sit on, this article will try to cover the most important areas of front-end development as much as possible.

Common misconceptions

One of the biggest mistakes I see interviewees make is preparing trivia questions such as “What is a box model?” “Or” Tell me the difference between == and === in JavaScript?” And so on. It’s great to know the answers to these questions, but they don’t tell the interviewer what you’re really capable of.

Instead, prepare for the interview with some very practical preparation that really demonstrates your JavaScript, CSS, and HTML coding skills. Preparation for the interview includes implementing the UI, building widgets, or implementing features common to libraries such as Lodash and Underscore.js, for example:

  • Build the layout and interactions of common Web applications, such as the Netflix browser site.

  • Implement gadgets such as date pickers, wheelcasts or e-commerce shopping carts.

  • Write functions like debounce or deeply clone objects.

Another common mistake when it comes to libraries is that people like to rely entirely on the latest framework to solve interview problems. You might be thinking: Why reinvent the wheel when I can use jQuery, React, Angular, etc., in development? Why can’t I use it in interviews? That’s a good question, technologies, frameworks, and libraries will always change over time — I’m more interested in the fact that you need to understand the fundamentals of front-end development rather than rely on higher levels of abstraction. If you can’t answer interview questions without relying on these libraries, I hope you can at least thoroughly explain and speculate about what the libraries are doing behind it.

In general, you should expect most interviews to be very practical.

JavaScript

You need to know JavaScript, and in depth. In the interview, the more advanced the person, the higher the expectation of the depth of language knowledge. At the very least, here’s what you should be familiar with in JavaScript:

  • Execution context, especially lexical scope and closure.

  • Promotion mechanisms, function and block scopes, and function expressions and declarations.

  • Bindings – specifically the call, bind, apply, and this keywords.

  • Object prototypes, constructors, and mixins.

  • Combinatorial functions and higher order functions.

  • Time to delegate and bubble.

  • Typeof, instanceof and Object. The prototype. ToString.

  • Handle asynchronous calls with callbacks, promises, await, and async.

  • When to use function declarations and expressions.

DOM

How to traverse and manipulate the DOM is important, and if they rely on jQuery or write a lot of React and Angular type apps, then this is something most candidates should be working on. You probably don’t do this every day, because most of us use abstract sorting. But if you don’t rely on third-party libraries, you should know how to do the following:

  • The use of the document. The document of querySelector and older browsers. GetElementsByTagName to choose or find nodes.

  • ParentNode, node.firstChild, node.lastChild and node.childNodes.

  • Left and right traversal: Node.previousSibling and Node.nextSibling.

  • Operations: Add, delete, copy, and create nodes in the DOM tree. You should know how to modify the text content of nodes, and how to switch, delete, or add CSS class names.

  • Performance: Manipulating the DOM can be expensive when you have many nodes, so you should at least be aware of document fragments and node caching.

CSS

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

  • Layout: elements that sit next to each other and how to put elements in two and three columns.

  • Responsive design: Change the dimensions of the elements according to the browser width.

  • Adaptive design: Changing the size of an element based on a particular breakpoint.

  • Specificity: How to calculate the specificity of a selector and how cascading affects attributes.

  • Use the appropriate namespace and class name.

HTML

Know which HTML tags best represent the content you’re displaying and the attributes associated with them, and have the skills to write HTML by hand.

  • Semantic markup.

  • Tag attributes, such as disabled, async, defer, and when to use data-*.

  • Know how to declare your doctype (many people forget this because they don’t write new pages every day) and what meta tags you can use.

  • Accessibility issues, such as ensuring that the input checkbox has a larger response area (using the label “for”). Role = “button”, role = “presentation”, etc.

The system design

Interviews for backend systems design often involve MapReduce, designing distributed key-value stores, or require knowledge of the CAP theorem. While your front-end work doesn’t require an in-depth understanding of how such systems are designed, don’t be surprised to be asked to design the front-end architecture of common applications. Often the questions are vague, like “Design a site like Pinterest” or “Tell me how to build a checkout service?” . Here are some areas to consider:

  • Rendering: Client rendering (CSR), server rendering (SSR) and general purpose rendering.

  • Layout: If you are designing a system for use by multiple development teams, you need to consider building components and whether teams need to follow consistent specifications to use them.

  • State management: such as choosing between one-way data flow or two-way data binding. You should also consider whether your design follows a passive or responsive programming model and how components should relate to each other.

  • Asynchronous flow: Your components may need to communicate with the server in real time. Your design should consider XHR and two-way invocation. If the interviewer asks you to support older browsers, your design will need to choose between hidden iframes, script tags, or XHR for messaging. If not, you can suggest using WebSockets, or you may decide that server send events (SSE) are better.

  • Separation of concerns: MVC, MVVM, and MVP patterns.

  • Multi-device support: Will your design use the same implementation for the Web, mobile Web, and hybrid applications, or will it be implemented separately? If you’re developing a site like Pinterest and might consider using three columns on the Web, but only one column on mobile, how should your design address this?

  • Delivery: In large applications, it is not uncommon for independent teams to have their own code base. These different code bases may depend on each other, and each usually has its own pipeline to release changes to the production environment. Your design should consider how to build these resources using dependencies (code splitting), tests (unit and integration tests), and deployment. You should also consider how to distribute resources through a CDN or inline them to reduce network latency.

The network performance

In addition to general programming techniques, you should expect the interviewer to look at your code or design and its impact on performance. It used to be enough to put CSS at the top of the page and JS scripts at the bottom, but the Web is evolving rapidly and you should be familiar with the complexities of this area.

  • Critical render path.

  • Service workers.

  • Image optimization.

  • Lazy loading and bundle splitting.

  • General meaning of HTTP/2 and server push.

  • When to prefetch and preload resources.

  • Reduce browser rearrangements and when to render elements to the GPU.

  • Differences between browser layout, compositing and drawing.

Data structures and algorithms

This may be controversial, but not knowing the basics of high time complexity and common runtimes such as O(N) and O(N Log N) can be confusing. Understanding aspects such as memory management is very helpful for the single-page applications that are very common today. For example, if you are implementing a spell checker, understanding common data structures and algorithms will make your job much easier.

I’m not saying you need a CS degree, but the industry is no longer about writing a simple page. There are lots of resources on the Internet that you can learn the basics in no time.

Common Web knowledge

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

  • HTTP requests: GET and POST and associated headers such as cache-control, ETag, Status Codes and transfer-encoding.

  • REST with RPC.

  • Security: when to use JSONP, CORs, and iFrame policies.

conclusion

As a Web developer or engineer, you need a lot of knowledge. Instead of getting bogged down in the depth of knowledge needed, keep an open mind and learn all the complex techniques needed to develop.

In addition to the technical topics covered in this article, you should also talk about past projects, describe interesting tangles and trade-offs.

I know there are a lot of things I missed in the front end of the interview, so I’d love to hear about your experience, or the important things you think I missed when you were asked during the interview.

The original article was first published on jingchengyideng public account: Jingchengyideng

Follow the public account Jingchengyideng, reply “6”, and get a big picture of the knowledge system mentioned in this article. Find out what skill points you need to fall short of making $400,000 a year.