Anchal Gupta

Hi. My name is Anchel Gupta. I have 6.2 years of experience. I have mostly worked on front-end development in my career. I have worked in two companies. First one was MAQ Software, and then I worked there for 3 years. Then I joined Techmojo Solutions for 3.2 years where I worked on different kinds of projects. My technical skills include React JS, JavaScript, HTML, CSS, TypeScript, and I have used Jest for testing purposes. From the last 1 year, I am leading a team of 7 members, 5 developers, and 2 QA engineers. I help them resolve issues. I help developers resolve issues. In my roles and responsibilities in that company is to review peers, end-to-end project management, assigning tasks to developers and QA, assigning story points, discussing issues and team issues with upper management, assigning tasks to team members, assigning OKRs to team members. And other than that, I have worked on a fantasy gaming application, which was based on React JS and JavaScript, HTML, and CSS. So I have majorly worked on React JS in my career. I have worked on different domains. I have worked in the gaming domain. I have worked in the finance domain, even management system, employee management system kind of things. I have worked on Power BI visuals, migrating the Power BI visual from jQuery and JavaScript to React JS. I have worked on performance optimization of applications. In my previous project, I worked on optimization techniques where the load time for the application was around 10 seconds, and I reduced it to 4 seconds. I developed a team of members, and we documented the approach to optimize the performance of the application. I have used several techniques, such as memoization in React, code splitting, code lazy loading. So these kinds of techniques I have used. And before my leadership role, I was working as a senior software engineer in Techmojo Solutions where I worked as an individual contributor, and I was also helping team members. I was also mentoring the team members there.

Critical factors for choosing different NPM packages for a project can be the size of the NPM package, first and foremost, and how many downloads that NPM package has, and what certificate that NPM package has, and what dependencies it uses, and what security reasons are associated with the NPM package, and how often it is updated, like what is the version in each year or how often they are updating the NPM package, and what capabilities that NPM package has, and what is the size of the NPM package, how much it is compatible with my project, is it fulfilling all my needs or not. If not, then I will go to other NPM libraries and check which one is more compatible for my requirements. Yeah, that's it.

To refactor a JavaScript code base to TypeScript, to minimize disruption and ensure type safety, the first step I will take is I will first refactor the service files, the API files. So I will first refactor the API response. Like, I will convert the API response from JavaScript to TypeScript. I will create different types for the response type and the request body type. I will create different interfaces and types wherever needed. I will create the global types if we are reusing them multiple times. So I will put them into the global type file. And then after the API files, I will go to each component one by one, and I will go on the child level first, the leaf node, and then I will first convert that component from JavaScript to TypeScript. And then I will go to the above level in the hierarchy, then the above, like, I will go one by one in the hierarchy, and I will update all the components one by one. After that, once the components are done, I will go to the pages if we have any pages folder, which will have the highest level of parent component. So then I will update there, and I will make sure that the TypeScript interfaces and types we have created have proper names, and we are extending wherever we are getting repeated. So I will create inheritance. I will use the principle of inheritance there. So that kind of thing I will do to ensure type safety, and I will also use ESLint. So we can add a rule there so nobody can use any, no one can use any project and disable the ESLint. This kind of plugin we can use. So everyone in the team is following the TypeScript things.

Types of features to consider essential for maintaining a large code base and why. Like, I will use types and interfaces. So, like, we can extend them. We can use the usable code there. We can use the same thing multiple times, and we can use the same thing. And instead of creating different interfaces or types, we can make use of the previously defined types or interfaces. So the reusability factor will come into picture. And second thing is, like, IntelliSense, the visual code editor will provide IntelliSense, and developers can code better and faster. They have the idea of what will come next and what property each object has. We can make use of tuples. We can make use of the union operator. So that feature, I think, is easy and everybody can use it. And one of the main features is the inheritance. Like, inheritance is a very essential feature for the large code base because we will have too many interfaces or types if inheritance is not in the picture. We have to create too many interfaces or types. By inheritance, we can directly inherit one type and then add new properties. So we can do this in TypeScript for maintaining the large code base. And TypeScript basically provides code that is not error-prone. In JavaScript, the type is not defined. So anybody can write anything. If a function is accepting a string as a parameter, you can pass a number as well, and it will accept that one as well. But in TypeScript, if you have defined the type with a colon like dot colon string, the code editor will itself give you an error that it is defined. Like, if the parameter passed should be a type of string, so that helps and will come handy for developers to write code.

For the webpack to improve the load time of our web application, we can include tree shaking. So it will, like, it will remove the unused code at the time of build time, it will remove the unused code. We can define the source map. So if the environment is production, we can define whether we want to show the code, like, we want to bundle the whole code or not, so that we can define in the webpack. So we can define that. The entry point also we can define. So entry point and output point also we can define. To leverage Webpack to improve the load time of a web application, tree shaking is one of the things that comes to mind right now. It has Webpack's entry point, output file, and it has the loaders. So plugins also we can define in Webpack.

An instance where you improve the performance of a web application by modifying its separate configuration. Yeah, so an instance was like in one of the applications, the build had unused code as well. So, to remove the unused code, I used six modules and included tree shaking inside the Webpack. For CSS code, I used CSS purge and applied it inside the Webpack configuration. So, if the CSS file or any style code wasn't used, it was removed at build time. For the code part, we can define depth and source map, or use something else instead. This way, the whole code won't be bundled. Only the required part will be bundled. We can't implement code splitting to improve the performance of the web application.

The road record snippet explained by this might cause unnecessary re renders. And how would you optimize it? So first of all, return doesn't have anything. We should return a GSX from a component, so it doesn't have anything. And second thing is, the function which we have does something is not present inside the useCallback. We have useCallback as the optimization technique, which React uses to optimize the performance of an application. It uses useCallback, the function will not be recreated on each and every render. So that part is missing here, and that's why it is causing unnecessary re-render. And inside the return statement, we are not passing anything, so that's why it doesn't return anything. That's why it is causing the re-render because return doesn't have any JSX elements to return.

In this JavaScript snippet, the potential error and what could occur is that items is an array of length 5, but here we are shortening the length of items dot length equals to 3 in line number 2, and we are trying to access the items at the 3rd index. So that means we are trying to access the 3rd item present inside the array. But on line number 2 items dot length equals to 3, the item the array is getting shortened to 3 items only. So that's why it is getting an error. Like, we are getting a potential error that items is 3 because the index out of bound error will be there for this. My suggestion is, like, we can update the line second line item dot length to 4, and then we can access the 3rd item, the item at index 3, we can access. Otherwise, we can access any other element instead of array index out of bound.

Discuss your experience with direct testing in real applications and how you ensure that TypeScript types do not interfere with test cases. So in unit testing in a React application, I have used it in all of my applications. And what we have done is followed test-driven development. So first, we design the test cases, then we start writing the code. So, we also check the test coverage. We have used toner cube to test the test coverage, and I was using Jest testing library to create the unit test cases in a React application. And it was like we render the component, and we give some props to it. We have to cover all the lines inside the component and also test the branches present inside the component. What we do is use the same types we have created for the component for the test cases as well. And by using that, it will not interfere, and the test case will also pass, and the component will also render properly. We use the same types present inside the component, so it will also match through it. And for the mock object, we use the same types and create similar kinds of objects, whatever we will be getting in the component.

So, principles of progressive enhancement, have you applied the principles of progressive enhancement in one of your web development projects? Yes. I have applied progressive enhancement in one of my web development projects. So, I have applied the HTML5 principles like the semantic markup I used to develop my application. I have used accessibility as well. Security features, I have also used in my projects. Optimization techniques, I have used. I have used ES6.

So, give an example of a time when unit tests I wrote for a React component found a critical issue. Okay. So what happened once, I developed a component long back, and another feature came up, which, so, for developing that feature, the application was very big. So to develop that feature, one of the developers changed that component. that component is reusable, which is why I was using it on multiple places. So the developer had written a task to update the component for one feature, but he had not tested that component on each and every place because, what happens, we receive data from CMS. So for one feature, the toggle was off. So the application was not breaking at that time, in the local environment of the developer. So once he tried to push the code, we have a build setup, we have the NPM run test command. So once he was trying to push the NPM run test command, it ran and it failed one of my test cases. For that feature, I had written. So it failed, and then the developer found that, okay, he had broken the code. So that's how we found a critical issue, which we prevented by writing unit test cases.