Akash Priyadarshi

Hi. My name is Akash Pedarshi. I'm a full-stack developer with 4 years of professional experience in building scalable web applications and AI-driven solutions. My technical expertise spans the monostack, MongoDB, Express, React JS, and Node JS. I'm proficient in Python for back-end API development and machine learning workflows. I've built various projects during my job and also during my master's and B.Tech. So the first project that I built during my job was an AI car parking management system. It was a real-time parking slot allocation system using ArcGIS Node, integrated with a predictive AI model built with TensorFlow. The next project that I built during my master's was a chatbot for contextual customer interaction. It was an advanced chatbot system powered by GPT-3 and integrated with Socket IO for real-time communication. Also, I'm working on a personal research project. It's a dark matter mapping AI model developed with a Python-based deep learning pipeline for cosmic shear analysis, combining PyTorch, NumPy, and NextShares for interactive visualization. My dissertation for my master's degree was a stock market price forecasting bot. I created a machine learning model using a LSTM network in Python, with AI developed in Node JS for real-time data fetching, and I also used AutoML from Azure for training the model and comparing which algorithm was best and more performing. Also, my technical strengths include front-end technologies such as React JS, Redux, HTML, CSS, MUI, and Tailwind. For back-end, I use Node JS, Express JS, Python, Flask, Django, and RESTful API development. For databases, I have worked with NoSQL and MySQL, like MongoDB and MySQL. For cloud and DevOps, I have experience in AWS, Lambda EC2, Docker, Kubernetes, and Azure and Google Cloud. Also, for AI and ML, I have experience with TensorFlow, PyTorch, scikit-learn.

In React, what method would you say is essential for properly unmounting components that involve ongoing API requests? So, in React, properly unmounting a component is crucial to avoid potential memory leaks or errors. We can use the useEffect cleanup function. It is an essential method we can use to handle this. The key approach is to use an abort controller. The abort controller API allows us to cancel any ongoing API request when the component unmounts. This is particularly useful for fetch-based API calls, and we can use proper useEffect cleanup. React's useEffect hooks allow us to return a cleanup function. This function is executed when the component unmounts or when the dependencies of useEffect change. It is essential to prevent memory leaks by stopping API calls that are no longer relevant. Also, it cleans up event listeners, subscriptions, or any interval associated with a component. We can also use a cancel token for Axios. If you are using Axios for API requests, you can use cancel tokens for managing API request cancellation. Some important points to use for unmounting components include always using a cleanup function in useEffect to cancel API calls when the component unmounts, using an abort controller whenever possible for fetch-based requests and canceling console access. This approach will always ensure proper resource management and prevent any unexpected errors during mounting.

When building a React dashboard that needs to display a large dataset, for example, 10,000 rows, ensuring smooth rendering and efficient performance is critical to ensure a greater user experience. So the strategies that we can use are virtualization, which is also known as windowing. Rendering 10,000 rows at once can cause significant performance issues. So using virtualization ensures that not only the rows currently visible in the viewport are rendered, but also these libraries allow you to render only a small portion of data, the rows in view, which also improves the performance. And the next thing we can use is navigation. We can break the dataset into smaller chunks that can be fetched and rendered on demand. For example, we can use a library like Material UI or another design library to get data already loaded in the browser, and we can fetch rows in chunks from the server using the backend API. Also, we can use lazy loading or infinite scrolling. Instead of fetching and rendering all the rows at once, we can implement lazy loading or infinite scrolling to load more rows as the user scrolls down. We can fetch and append new data as the user scrolls near the bottom of the list. And we can use memoization. React components re-render by default, which can lead to performance issues when dealing with such large datasets. So we can use the React Memo to prevent unnecessary renders of table rows. Also, we can use memo to memorize expensive calculations or derived data. Also, we can use efficient state management. If the data is updated frequently, we can ensure the state changes are actually efficient and localized. So we can use React Context API or libraries like Redux or Zustand to manage the dataset without causing unnecessary re-renders. Also, it only updates specific rows that change rather than the entire table.

Given the React component state managed approach, one potential issue for this thing is the state updates may be asynchronous, and there is a binding issue. The increment count function is not bound to the component instance. This, when passed as a callback or event handler, will be undefined leading to runtime error. Also, React's set state function is asynchronous, meaning multiple calls to set state may be batched together. This can cause issues when the next state depends on the previous state as this state, as the component's this.state.count may not always refer to the latest state. Also, the code uses a class component, which is less commonly used in modern React development compared to the functional components with hooks. So, this approach increases boilerplate code and may not align with the current best practices. So we can use the callback version of set state to ensure the state is updated based on the latest state. Also, the binding issue is there. The fix for the binding issue is to bind increment count in the constructor or to use an arrow function for the method, which is more preferred. Also, we can use modern React. For example, the use of functional components with hooks for state management. We can rewrite this component using the use state hook. Also, we can use event handling best practices. For example, we can ensure that the event handlers like on click are bound or defined in line correctly. If using the modern function approach, this issue is inherently resolved. Also, finally, we can use modern React practices. For example, we can write it like: import React, { useState } from 'React'; and then we can declare the function, my component, function start without any parameters and then const count, set count equals useState(0); and then const increment equals to [() => set count(previous count => previous count + 1)], which returns the result. And then in the end, we can use export default my component.

okay we have to examine this examine this JavaScript function that is intended to return intended to return so the JavaScript function provided is intended to return a new array where each element of the input array is squared while the logic is mostly correct there are areas for improvements I mean there's an out of bound error so the for loop condition uses I is less than equals to error length which will cause an out of bound error on the last iteration as array indices range from 0 to array dot length minus 1 so the condition should be I less than array dot length instead also the variable declaration the var keyword is used for the squared array and the I loop variable it is better to practice to use let or const to avoid issues with variable scoping in modern JavaScript also the function can be rewritten using modern JavaScript features like array dot prototype dot map for better readability and functional programming yeah that's it

So, to efficiently execute complex queries in MongoDB that need to read and write data in a Node.js application, we can use optimized query design. This ensures proper indexing to speed up query execution, analyzes query patterns, and creates indexes on frequently used fields for filtering, sorting, and joining. There are many methods, but one approach is to use MongoDB's powerful aggregation pipeline for complex queries. This allows you to filter, group, project, and transform data very efficiently. We can also use connection polling to reuse existing database connections instead of creating a new connection for every request, reducing overhead and improving performance. For writing-intensive queries, we can use bulk write to perform multiple insert, update, or delete operations in a single command, reducing the number of database calls. Asynchronous query execution can also be used, along with promises to handle queries in a non-blocking way, ensuring the application remains responsive. We can also optimize the aggregation pipeline by limiting the number of documents processed early in the pipeline using a match or limit, and by using project to include only necessary fields, reducing the amount of data passed through the pipeline. Additionally, sharding can be used for scalability, and transaction management can be used for ensuring data consistency. Monitoring query performance is also essential.

Sorry, no. It's hard. No. Your React app's performance has degraded significantly. As data volume grew, what step would you take using reactive tools and MongoDB profiling to identify and solve the issue? Where to identify and solve performance integration in a React app as data volume grows, a combination of React and dev tools and MongoDB profiling can be used. So, the React tools that we can use is, first, we can identify components that rerender. For example, we can enable React dev tools profiler. Okay? We can look for wasted renders. We can check if components are rerendering due to unchanged props or state. We can inspect state management. We can analyze how state is being managed in the app. Is it global state being updated too frequently, or are large amounts of data being stored unnecessarily instead of being passed down via props? Also, we can analyze component hierarchy. We can look for components with deep nesting that trigger renders across the tree. The solution we can implement if this is happening is to split components into smaller ones and leverage lazy loading or code splitting to reduce the rendering overhead. Also, we can check virtual DOM updates. So we can use the highlight updates option in the React dev tools to see which parts of the app are rerendering frequently. Now, for MongoDB profiling, we can enable MongoDB profiling. We can set a profiling level to capture slow queries. We can use db.setProfilingLevel and set it to 2, to capture slow queries over 100 milliseconds. Also, if queries take longer than 100 milliseconds, it will be logged, helping to identify slow database operations. We can analyze query logs, check for slow queries or inefficient operations like missing indexes, navigation scanning, large collections, or fetching excess data. Also, we can optimize queries, optimize aggregation, profile execution, and query plans.

Okay, describe a scenario where an atomic operation in MongoDB is critical within a Node.js application, and how would you achieve it. So, suppose you are building an ecommerce application where inventory stock levels are managed in a MongoDB database. When a user places an order, the system needs to verify first, verify the product stock. Second, deduct the product quantity automatically to prevent over-selling. So, here, the atomic operation is critical to ensure seamless transactions, for example, multiple users purchasing the same products do not result in risk conditions where more stock is sold than available. So, in this situation, atomic operation becomes very critical because it prevents overselling. It ensures that a stock level reflects all transactions accurately even under high concurrency. Also, it prevents partial updates or data corruption in case of system failure. We can achieve atomic operation in MongoDB. MongoDB provides atomicity at a document level for more complex operations across multiple documents. Or, you can use transactions or atomic operators like $inc. We can use $inc for single document operations. If all inventory data for a product is stored in a single document, we can use the $inc operator to automatically decrement the stock. The $inc operator automatically increments or decrements a field value. So, it is the best option. The find one and update operation ensures that only documents meeting the condition are updated. For example, if stock is less than or equal to quantity to buy, it is updated. This approach is very suitable for managing stock data, where all data resides in a single document. Another approach is using MongoDB transactions. If the inventory data spans multiple collections or needs to update multiple documents, we can use a MongoDB transaction. A MongoDB transaction has atomicity, which ensures that either both operations succeed or neither does. It also has consistency, which prevents partial updates when the application crashes or steps fail.

So very hard. Oh my god. K. Demonstrate how would you design a fault-tolerant system using Node.js and AWS for a critical application. Very hard question. Okay. So, basically, a fault-tolerant system ensures availability, reliability, and scalability, even when parts of the system fail. So, we can design a fault-tolerant system. We can use the first is, if you're talking about availability, so we can use load balancers. So, AWS Elastic Load Balancer to distribute traffic across multiple nodes, multiple instances. So, it is available even if the traffic is very high. Also, auto scaling group, we can ensure new instances are launched automatically if the current instance fails. Also, fault-tolerant database using Amazon RDS, multi-AZ, or DynamoDB for replication. Also, a stateless Node.js instance, we can make. So, it maintains a stateless architecture so that any instance can handle incoming requests. We can use caching there. We can use Amazon Elastic Cache or maybe Redis together with Node.js to reduce the database load. Also, we can use message queues. We can use Amazon SQS for asynchronous processing and decoupling services. We can use Amazon CloudWatch for logs, alarms, and performance monitoring. So, if something goes wrong, we get to know quickly. Also, we can use Route 53 for DNS failover to redirect traffic in case of region failover. And we can regularly backup the snapshot of the database and file storage using Amazon S3 and lifecycle policy. Also, for fault-tolerant design, we can design the Node.js server instance to be stateless, use external storage. For example, S3 for sessions and other stateful data, we can ensure that there is no dependency on individual instances. So, we can easily replace them or maybe scale them. Also, using load balancers to distribute traffic across multiple Node.js instances. We can also make it fault-tolerant. We can use performing elastic load by balancer, ELB, performance. Sorry. We can perform health checks of our load balancer and route traffic away from unhealthy instances. Also, for auto scaling, auto scaling was the last thing. No. To design a fault-tolerant system, we should also consider auto scaling. So, configuring auto scaling groups to ensure a new Node.js instance is launched if an existing one fails. Auto scaling can also handle sudden spikes in traffic by automatically provisioning resources. Also, we can use Amazon RDS with multi-AZ deployment for relational databases, for example, MySQL or PostgreSQL. For NoSQL, we can use DynamoDB with global tables for multi-region fault tolerance.

If you have a memory leak in your Node use application, how would you go about diagnosing and solving it? Memory leaks in your application. Well, before jumping into diagnosis, recognizing typical signs is the best option. So, we can increase memory usage. The memory footprint keeps growing over time without stabilizing. Also, the application slows down as memory consumption increases. The garbage collector runs more often, but memory is not reclaimed efficiently. Also, the process runs out of memory. These are the symptoms of memory leaks. After confirming the symptoms, we can then diagnose. We can identify memory users. We can use a process-dot-memory-users to check the memory usage of our application. And if the memory usage steadily grows over time, it indicates a potential leak. We can also use memory monitoring tools. For example, we can get a real-time view of our application's memory usage. Node.js inspector, Chrome dev tools, and third-party tools like Datadog or Prometheus can be used. We can use these tools. We can create a heap snapshot. We can take a heap snapshot to identify memory usage patterns and objects retained in memory. We can attach Chrome dev tools or use Node.js inspector. Then we can navigate to the memory tab and capture a heap snapshot. Then we can look for objects that persist across the snapshot but should have been garbage collected. We can also use the node-head-pump package to generate a snapshot programmatically. We can analyze the heap snapshot to identify detached DOM nodes, objects referencing DOM nodes no longer in use, functions retaining references to objects unnecessarily, or unremoved event listeners that prevent objects from being garbage collected. Common culprits in this case are unclosed database connections or file streams, global variables unintentionally holding large objects, or catch blocks growing indefinitely without cleanup. We can use profiling tools because they provide insights into memory allocation and object retention. We can use clinic-dot-js, which is a powerful suite for diagnosing performance issues. To fix it, we have to first close event listeners if there are any. We have to manage catches properly. We have to limit our data retention. We should correct every kind of global variable. We have to fix data connection leaks. If there are any, we should throttle or debounce requests, which will prevent memory leaks.