Summary

A front-end developer with over 10 years of experience reflects on a job interview that extensively covered foundational JavaScript concepts, ReactJS, and the evolution of asynchronous programming in JavaScript.

Abstract

The web content describes a conversation between two front-end developers, where "A," the interviewee, recounts his experience being asked about basic JavaScript language and ReactJS framework questions during a job interview for a lead front-end role. Despite his extensive experience, "A" was caught off guard by the depth of the foundational questions. The interview also delved into the history of JavaScript frameworks, object-oriented programming in JavaScript, the importance of the virtual DOM in ReactJS, and the evolution of asynchronous programming patterns from callbacks to promises and then to async-await. "A" and his friend discuss the reasons behind such questioning, suggesting that interviewers may test a candidate's depth of knowledge and understanding of core concepts, especially when the CV does not provide enough discussion points. The conversation includes detailed explanations of JavaScript's prototype system, the differences between Redux and MVC design patterns, and the benefits of ReactJS's component-based architecture. The friend offers encouragement and insight, emphasizing the importance of being able to discuss the "histories" of technology and the need for a solid foundation in the basics, even with extensive experience.

Opinions

• The interviewer's focus on foundational JavaScript and ReactJS concepts indicates a desire to assess "A's" depth of understanding, which is crucial for a lead role.
• The interviewer may have found "A's" CV lacking in specific details, prompting a shift to more general technical discussions.
• "A" acknowledges that while he did not prepare for such basic questions, the interview provided an opportunity to demonstrate his comprehensive knowledge.
• The friend suggests that the interviewer might have been unfamiliar with "A's" CV or wanted to extend the interview by discussing general topics.
• The discussion highlights the importance of a strong command of foundational technologies, even for experienced developers, to succeed in interviews.
• The evolution of JavaScript from callbacks to promises and async-await reflects the language's maturation and the industry's shift towards more readable and maintainable asynchronous code.
• The friend's perspective implies that understanding the historical context of JavaScript frameworks and patterns is valuable for senior developers.

And They Asked Me a Couple of Tough Questions

Last week

My friend is a front-end lead who has 10yrs+ exp and wants to change jobs, recently he interviewed with a few companies.

“Today, my interviewer dived deep into some basic questions about the JavaScript language and the ReactJS framework itself. It was the first time someone asked me these kinds of questions,” my friend, whom I’ll call “A,” said.

“Perhaps they see that you’re pursuing a lead role and want to test your understanding of foundational concepts. Did you manage to answer all the questions?” I asked.

“Only some of them. I never prepared that much,” he replied.

“It’s not necessarily about your interview preparation. It could be that the interviewer wanted to ensure you both had a common understanding of the basics. Sometimes they still have time and find nothing specific from your CV to discuss, so they test your depth of knowledge on general topics, especially if they are well-versed in them,” I suggested.

“Why did he find nothing from my CV to discuss, there is a bunch of experience!” He asked.

“Well, maybe he doesn’t know them well, haha,” I said.

“I see, or maybe they are not interested in my recent projects haha,” A said.

“I’m not sure, or maybe you answered all their questions too fast but there was still time. They wanted to get you, so they wanted to talk with you more. It depends. What did they ask you?” I asked.

“They asked how I know about ReactJS, given my 10+ years of experience. They wanted to know all the JavaScript frameworks I’ve been through on my road and how I think ReactJS differs from others. They talked about the pros and cons. They also asked about object-oriented programming in the JavaScript language itself, from the old-school days until now, and also about async-await and more. You know, all these are basic but if we want to talk about this histories for each could be tough to answer,” A recounted.

“Wow, sounds tough. Maybe we can discuss the details one by one, and I can share them with other front-end developers who are preparing for interviews like you,” I offered.

“Sure,” he agreed.

JavaScript Frameworks You’ve Used

My friend started in 2008 with old-school libraries like jQuery and ExtJS, then moved on to HandlebarsJS, EmberJS, KnockoutJS, AngularJS, and now ReactJS (he also tried VueJS a few years back). Based on design thinking, we can categorize them into three groups:

Binding-Based

• KnockoutJS: It uses two-way data binding to connect the UI to the underlying data model. Changes in the model automatically update the UI and vice versa.
• AngularJS: This framework also utilizes two-way data binding, making it easy to keep the model and view in sync. It allows automatic synchronization of data between the model (business logic) and view (UI).
• Pros: These frameworks reduce the boilerplate code needed for DOM manipulation, making it easier to create dynamic applications.
• Cons: Mixing the JS logic in HTML goes against the principle of Separation of Concerns, which may also introduce complexity and performance issues in large-scale applications due to excessive DOM updates.

Template-Based

• HandlebarsJS: This is a way to build dynamic HTML pages by embedding expressions in HTML. It allows developers to create reusable templates for rendering content.
• EmberJS: Uses a templating engine similar to HandlebarsJS to render dynamic content. Ember’s template system automatically updates the DOM when the underlying data changes.
• Pros: Simple. These frameworks focus on separating the presentation layer from logic, promoting a clear separation of concerns. They simplify rendering by using templates to bind data to the UI efficiently.
• Cons: When projects get bigger, you still need to write a lot of code, and much of the logic is duplicated. There are no reusable components, which can lead to code bloat and difficulty in maintaining a consistent structure across large applications.

Component-Based

• ReactJS: Focuses on building reusable UI components. It uses a virtual DOM to optimize rendering performance.
• VueJS: Combines the best of Angular and React with a component-based architecture that is flexible and easy to integrate.
• Pros: These frameworks promote reusability and maintainability by encapsulating functionality within self-contained components. This modular approach simplifies the development of complex applications.
• Cons: There is a learning curve, especially when integrating advanced features like state management and routing. Additionally, because React and Vue are libraries rather than full frameworks, developers must make more decisions about which additional tools and libraries to use, like redux.

Why Did You Choose ReactJS for Your Team?

1. Strong Community Support/Flexible Ecosystem: React has a large and active community that contributes to its ecosystem, making it easier to find solutions, libraries, and best practices; allows developers to choose their own tools and libraries, making it adaptable to various project requirements.
2. Virtual DOM Design: React’s virtual DOM improves performance by batching updates and reducing the number of direct manipulations to the actual DOM.
3. Integration with Redux: React can be seamlessly integrated with Redux, which follows an event-driven and immutable design pattern.

You Mentioned Redux Design, How Do You Think It Differs from Others, Like the common MVC pattern?

MVC

• Model-View-Controller (MVC): This is a common structure that has been used for many years. The idea is simple: the model holds the state, the controller handles business logic, and the view is responsible for presentation.
• Model: Manages data and business rules.
• View: Displays data and sends user inputs to the controller.
• Controller: Processes inputs, calls the model, and updates the view.

Redux

A completely different flow.

• Action: An action is dispatched, representing a change or event in the application.
• Reducer: The reducer function takes the current state and the action, processes the update, and returns a new state. The state is immutable, so a new state object is created rather than modifying the existing state.
• Store: The store holds the entire state tree of the application. When an action is dispatched and processed by the reducers, the store updates and notifies all components subscribed to it.
• Component: Components subscribe to the store and react to state changes by re-rendering, ensuring the UI reflects the current state.

Key Differences

State Management

• Redux: Centralizes state management using an event store, allowing easy tracking of all state changes, every change is immutable which serves as a single source of truth. This centralized state management approach is missing in traditional MVC patterns.
• MVC: The State is often managed within individual models, leading to scattered state management in large applications.

Data Flow

• Redux: Enforces One-way data flow. The flow starts from an action, dispatches changes to the store, and updates subscribed components.
• MVC: Often involves bidirectional data flow. Changes can propagate from the view to the controller, updating the model and vice versa. This can lead to complex, intertwined dependencies.

Complexity and Reusability

• Redux: Encourages reusable components and logic due to its centralized, generalized approach to state management and one-way data flow simplicity.
• MVC: As applications grow, it can become difficult to maintain clear data flow and state management across multiple views and models, leading to potential duplication of logic and less reusable components.

And Why is the Virtual DOM Important?

Reflow and Repaint are both heavy.

The Virtual DOM boosts performance by minimizing browser reflows and repaints. Reflows are particularly expensive because they involve recalculating the layout of the page. Without the Virtual DOM, each of the X DOM operations would trigger a reflow and repaint. However, with the Virtual DOM, holding a “diff-tree” for the dom-difference, these operations are processed in batches, resulting in only one reflow and repaint.

An Example.

Let’s say we have some JS code directly manipulating the DOM 100 times; the difference is significant (1 reflow vs. 100 reflows):

https://readmedium.com/today-i-interviewed-for-a-lead-front-end-role-d4845e5ddd2e