Q1: What should a full-stack developer know?

Ans: Full-stack developers should start with the following:

• Programming Languages:  A full-stack developer must be fluent in more than one programming language, such as Java, Python, Ruby, C++, and so on. Based on the programming language, one must be familiar with various techniques to plan, develop, implement, and test the project.
• Front End:  Front-end technologies such as HTML5, CSS3, Angular, and others must be learned. Understanding third-party libraries like jQuery, Ajax, and SASS provides additional benefits.
• Frameworks:  Proficiency with development frameworks such as Spring, Spring Boot, MyBatis, Django, PHP, Hibernate, js, yin, and others.
• Databases: It is necessary to be familiar with at least one database. It is adequate if you are familiar with MySQL, Oracle, and MongoDB.
• Design Ability: Knowledge in prototype design, such as UI and UX design, is also required.

Q2: Explain Prototype Inheritance in Javascript

Ans: In a language that supports classical inheritance, such as Java, C#, or C++, you begin by establishing a class–a blueprint for your objects–and then you may either generate new objects from that class or extend the class, defining a new class that augments the original class. In JavaScript, you construct an object first (there is no idea of class), then you may alter it or generate other objects from it.
.
In Javascript, every object has a prototype. The inheritance mechanism in JavaScript is prototype-based rather than class-based. When a message reaches an object, JavaScript will first try to locate a property in that object. If it is unable to locate it, the message will be forwarded directly to the object's prototype, and so on. This is referred to as prototype chain or, in certain cases, prototype inheritance. .
.
When it comes to constructing prototype chains in JavaScript, Constructor functions are the preferred method. When we use the keyword new, JavaScript inserts an implicit reference to the new object being created. It also entirely returns this reference at the end of the method.

Q3: What is the difference between git pull and git fetch?

Ans: Git pull, in its most basic form, does a git fetch followed by a git merge.

• When you used to pull, git attempts to perform your job for you. Because git is context-sensitive, all pulled contributions will be merged into the branch you are now working in. Pull merges the commits without allowing you to examine them beforehand. You may have frequent disputes if you do not closely control your branches.
• When you fetch, git collects any commits from the target branch that do not exist in your current branch and saves them to your local repository. It does not, however, combine them with your current branch. This is especially handy if you need to maintain your repository up to date but are working on something that could fail if your files are updated. Merge is used to incorporate the commits into your master branch.

Q4: What do you think of AMD vs. CommonJS?

Ans: Both are methods for implementing a module system, which was not native to JavaScript until ES2015. AMD (Asynchronous Module Definition) is asynchronous, but CommonJS is synchronous. CommonJS is geared toward back-end development, whereas AMD, with its capability for asynchronous module loading, is geared toward browsers. .
.
Most people would find AMD syntax rather tedious, whereas CommonJS is more akin to writing import statements in other languages. Most of the time, I think AMD is unneeded since if you served all of your JavaScript in a single concatenated bundle file, you wouldn't get the async loading properties. Furthermore, CommonJS syntax is more similar to the Node style of module creation, and there is a less context-switching cost when moving between client-side and server-side JavaScript programming. .
.
I'm relieved that we can finally stick to one technique with ES2015 modules, which enable both synchronous and asynchronous loading. Although it has not been completely implemented in browsers and Node, we can always utilize transpilers to transform our code.

Q5: What is long polling?

Ans: Long polling is a good way to create a steady server connection without utilizing the WebSocket or Server-Side Events protocols. It works on top of the traditional client-server paradigm. It is worth noting that Node.js uses the same method as the following development model. .
.
The client submits the request, and the server answers until the connection is closed since it includes new and unique information. A request to the client can be sent as soon as the server responds. When the data is ready, the server will respond with a query. It is activated when the client application terminates, and the server terminates requests.