Payal Pagariya

so hi. My name is. I'm working as a full stack developer in GeoPlatforms Limited. my tech stack is comprises of MongoDB, Express JS, React JS, and Node JS. so I mainly my work comprises, in two parts as I'm required to do, front end or, back end. So it depends on the project to project. so, this is my tech stack.

so if you look at the component, there are, the biggest problem is, the use effect is not, use effect that it is using count inside the effect, but there is no dependency added provided. That means this effect will run on every single render. and the, when the count changes inside the effect, you are also making a fetch call. So every render triggers the network call and perform which will lead to performance issue, which and, also, set count is being used in incrementals. You are calling the set count plus one twice in the same function. In React, the state updates are batched. so count here is a stale value. So both updates are based on the same old account. and in decrement function, the condition is check is written incorrectly, but the comparison operator seems broken and the misstep code is shown. the if that operator is wrong, the condition will either throw an error or behave unexpectedly. Another is with fetch is, like, you're sending post for it. But in, method you're passing method post and the data, but, fetch API data is not a valid option. It should be body, and you also need headers like content type, application JSON, and start. So yeah.

So this one is So for this function, I would think about test cases by walking through every decision branch and every condition that can change the written value. First, I'd like the scenario where the service is down. If service is down, then it should return true. The function should immediately return service two, regardless of whether user is premium, preferred service is passed, or load splitting. next type test, the service, is not down and preferred service is provided. In this case, the function should return, preferred service directly without evaluating the load splitting logic that where it should be split. I test both the premium and non premium users here and to confirm premier status doesn't affect this path. Then I'd move to should split load branch. I'll test, I'll test when, it, returns that function returns through. The request is time consuming with the prime user. In that case, the function should return service one. I'd also test, should split load, being true, but either the request is not time consuming or the user is not premium, where the expected, result should be service two. After that, I test the split load only for premium. if it is premium, when this returns two and the and the user will be premium, and the function should return service one. If the user is not ready, it should call back to service two. I for the default fallback scenario, if none of the condition max service is, not down, no preferred service is passed, no load splitting is also done. no. no. In this case, the function should always, return service two.

Are there inbox and so that returns total number of occurrences? we are increasing global count by the number of one second. first of all, I'd say the major bug in this is the use of global variable. The global time count since this variable, lives outside of the function. the value is shared and across the multibar. That means if this function is called more than once, the count will keep accumulating instead of starting fresh for each time. And this makes it non deterministic and unsafe. second function the secondly, the function is supposed to return the number of occurrences of b in array, but when the match is found, the global count is that plus is equal to b. this is incorrect. Should be increment the count by one. and if b is something like five, then the result becomes complete wrong. Right? and the third, and if the a lens is less than or equal to zero, we are not returning any value. so it returns undefined, which is also inconsistent. Naming convention for bad function is also there, and very it's like a poor design, I would say, the variable names and everything. We are not returning the, consistent values also.

so the MongoDB that find query is like a simple query, but, it can, it can scan through all the documents. We have to add the, like, indexing of keys on the customer. Right? We can add indexing on customer ID. And, also, like, single field index on customer ID. So that ensures that MongoDB only scans through, all the orders with customer instead of scanning the entire collection. next, the for the query that filters by status, and takes the total amount greater than value, I'd create a the burn index on status and total amount. This will allow MongoDB to efficiently apply the filter on the status first and then use the range query on total amount without scanning unnecessary document. for the third, is, like, most expensive because it filters by customer ID and then status and then stored by total amount. for this, I will add the compound indexes on customer ID status and then total amount. This index supports both filtering and sorting. And so MongoDB doesn't require the, yeah, in memory sort. And, usually, it is like a major performance bottleneck. and after adding these indexes, I will check the execution stats to confirm that query using index's scans instead of collection scans. And beyond indexing, I'll make sure that we are returning the required fields using projection and reduce the document size. I check the data distribution to index, ensure that indexes are selective enough.

so the complexity of this problem is n square because we are, run running a loop inside a loop. for every element, we are checking, other elements, so to find the target. so it is like a two some problem we are facing here. So I'll I'll will be add, like, I'll add, like, a hash map where, I'll keep a track of target minus, ith index of array. If that, is present in map, then I'll find that, there is a element which will add with the in ith index. I'll get the target. So I'll use a hash map, for it. So in the n, like, o of n time, I can pass through all the elements from the array, and, the space complexity will be also o of n, because I'm using hash map. So, yeah, extra space will be added. So the hash I'll what I'll do is I'll take the I think I'll pass through all I'll pass through the array. One by one, I'll check if target finest element is present in map or not. If it's not present, I'll add the add it add the I th index to it, element of I th index in the map. And after parsing, when I'll reach the point where there is an element where I can see that target minus I th element is present in the map, then I got those two, and I'll return the two. So in the one parse, all of end time, I'm accessing elements and all of, like, extra space, I'm adding as well.

I'm finding that election. Okay. So the complexity of this function is n squared for checking, if it element on the, in a so the current implementation is, like, o of n squared. The like, you, we have, like, two nested loops. One over it reads over array one and one it reads over array two. In the worst case, this already gives you a time complexity of n into m, where n is the length of array n, m is the length of array two. and on top of that, inside inner loop, we are calling intersection dot includes. I verify. This includes the method itself, the linear operation, but it scans intersection array only. In the worst case, it can add another of where k is the size of intersection array. So overall worst case time complexity becomes of n into m into k, which can like, a cubic time. To improve this, my main goal is to avoid nested loops, and the optimal approach is to use hash based data structure like set. First, I'll convert one of the arrays usually array into set. This takes o of n times. then you can loop through array once and check if the element exists in the set, and set lookups are, like, o of one. So to avoid duplicates, in the results, you can also store intersection in the set instead of an array. With this approach, the total time complexity becomes o of, n plus m, and space complexities of m.

First, I'll make sure that each line segment is in a valid order by treating it as start or end. The two line segments overlap if the start of one segment is less than or equal to the end of the other. and at the same time, the end of the first segment is greater than the equal to the start of other. So in simple terms for segment, if they overlap is when maximum of start of first line one start and line two start is, should be less than or equal to minimum of line one end and line two end. So because the endpoints are inclusive, even touching at the single point counts as an overlap. If this condition is true, the segments overlap. Otherwise, they do not. So the line one start, the maximum of line one start and line two start, is less than or equal to the minimum of matter minimum of line one end and line two end.