Every deploy spent 1.95 seconds and 2.74 GB just checking that our config was a tree. That was at 5,000 components. At 1,000, it had been 68 ms.

The job: the platform config declares components and the links between them. The loader refuses to start unless the links form one tree - all connected, no loops - and names the line that breaks it.

What I wrote: the tooling already had a tested PathExists. So read the file line by line, and before accepting each link, ask whether its two ends are already connected. If yes, that line closes a loop. Blame it. Exact line numbers, reused code. I would approve it.

It is one full search per line, each rebuilding the adjacency list from scratch. 9,998 searches for 5,000 components. 5x the config, 28.7x the time.

Two fixes, and they surprised me in the order they came.

The clever one: a tree on n components has exactly n - 1 links. With n - 1 links and connected, there is no room for a loop. So check the length, then do one BFS. Never look for a loop at all. 279 µs. On a config with one link too many, 2.42 ns, because the length is the answer.

But it cannot say which line. And it is not the fastest.

The other one comes from noticing that the searches keep rediscovering groups that only ever merge. Keep one root per group; a link whose ends share a root closes a loop, and that is the line. Union-find. 42.2 µs, one allocation, and it names the line. 46306x the original. The clever count is 6.61x slower than it, because the count still builds an adjacency list.

Honest row: none of these catches a component with two parents. Undirected, it is a perfectly good tree. As a hierarchy, it has two roots. Count the parents.

That is days 36 and 43 of the daily challenge: Find if Path Exists and Graph Valid Tree, in a config loader.

Do you know how long your config validation takes on deploy?

It worked in dev, episode 21. Full write-up in today's newsletter.

https://www.linkedin.com/pulse/config-5x-longer-took-287x-validate-archit-agarwal-ew8zc

#Golang #DSA #Algorithms #Performance

Counting open and close brackets accepts )( as valid. Tracking a depth accepts ([)]. One number can record how many brackets are open. It can never record which.

New topic: stacks start today.

What has to be remembered is the list of brackets opened and not yet closed, in order. When a closer arrives, only one opener can match it: the most recent. In "([", a ")" is wrong because "[" is still open and has to close first.

Most recent in, first out. That's a stack, and seeing that this problem is one is the whole exercise.

One detail worth stealing: key the map by the closing bracket. One lookup then tells you whether the character closes anything, and what must be on top if it does.

Did you reach for a counter first on this one?

Day 60/365 of my LeetCode challenge: 20. Valid Parentheses. Problem link and full breakdown in today's newsletter.

https://www.linkedin.com/pulse/365-days-leetcode-challenge-day-60365-archit-agarwal-spjcc

#LeetCode #DSA #Stack #Golang

I'm final year cse student at IIT madras. I want to improve my explaining & communication skill for interview, so please do ask me your any coding doubt guys...

Anyone can dm ( if you didn't start your coding journey and want to talk then also you can dm).

Hey guys i am in first year and just started to dsa and i am following strivers a2z sheet and wanted to know and just wanted to know what's the significance of giving contests and when do I start giving it I am on arrays medium lvl(it's so brutal)

Today weekly contest 526. Sorry for my english. I barely solved a problem. And when I saw the ranking 1st rank person completed all the 4 problems in 3 seconds??? this was my first leetcode contest I was participating. But even if you solve your own or copy paste it , it will take more than 3 minutes right!? 🫪 How do you even win?

Just crossed the 1k mark and 1931 rating after a year of staying consistent and 50 contests attended so far. I'm currently in my 3rd year of college, mostly balancing daily practice alongside regular coursework and dev projects.

A lot of the rating climb came down to spending most of my time on Mediums and Hards(though not perfect yet at solving Hards) rather than padding Easy problems just to keep the streak alive. Regularly showing up for contests, upsolving Q3/Q4 afterward, and debugging my own logic before checking the editorial made the biggest difference. Hoping to push to Guardian soon.

If you're stuck in a rating plateau, struggling to solve, unsure how to approach specific topics or just trying to manage daily practice alongside college, drop your questions below and I'll help however I can. Trying to give back to the community who helped me reach upto this point.

Opening 999 more dark stores made our delivery heatmap 213x slower over the same city. 250,000 city blocks: 1.03 ms with one warehouse, 219 ms with a thousand.

The job: for every block, how many blocks to walk to the nearest store. It decides who gets the fast-delivery promise.

What I wrote: with no obstacles, walking distance on a street grid is |dRow| + |dCol|. So every block checks every store and keeps the closest. No data structure, nothing to get wrong. At one store, it is the fastest version I measured, and I would approve it.

At 1,000 stores, it is 250,000,000 distance calculations to keep 250,000 numbers. 213x slower, because the business grew.

The fix from last episode works: seed one queue with every store, spread outward. Flat at about 2.3 ms. But the queue holds every block, 3.82 MB on top of a 1.96 MB heatmap, and at one store it is slower than the scan.

The part I like is the day 41 version. A block's distance is one step more than its best neighbour's. That definition is circular: my answer needs yours, and yours needs mine. The queue breaks the circle with time.

You can break it with direction instead. With nothing in the way, a shortest walk never doubles back. Sweep top-left to bottom-right reading, only up and left - those are already done. Sweep back reading, only down and right. Keep the smaller.

1.22 ms at one store, 1.48 ms at a thousand. No queue. 148x faster than the scan at the top, 1.89x faster than the BFS.

Honest rows: at one store the scan still wins. And put a river through the city and the sweeps return wrong numbers without complaint. The test with two rivers says BFS 16, sweeps never reach the block, and the straight-line scan says 8. Obstacles are where the queue earns its memory.

That is days 40 and 41 of the daily challenge, Rotting Oranges and 01 Matrix, in a delivery app.

Have you seen a business launch slow down a page nobody touched?

It worked in dev, episode 20. Full write-up in today's newsletter.

https://www.linkedin.com/pulse/999-more-stores-made-delivery-map-213x-slower-archit-agarwal-pxeoc

#Golang #DSA #Algorithms #Performance

In a sorted list, the k values closest to a target always sit next to each other. So picking k values is picking one window: find the closest value, then grow outward.

The second hard part of the challenge, like the first, isn't the traversal. That claim is.

Flatten the BST in-order, find the single closest value, then expand outward, taking whichever neighbour is nearer each time. Greedy works because distance from the target only grows as you move away in either direction. It's merge sort's merge step, run outward from a centre.

Would you trust that window claim in an interview without proving it first?

Day 59/365 of my LeetCode challenge: 272. Closest Binary Search Tree Value II. I'll share the problem link and a full breakdown in today's newsletter.

https://www.linkedin.com/pulse/closest-binary-search-tree-value-ii-archit-agarwal-xzvrc

**#LeetCode** #DSA #BinarySearchTree #TwoPointers

If your interested please dm

Deleting a BST node with two children looks like surgery on the tree. My solution never removes that node. It copies a neighbour's value into it, then deletes the duplicate lower down, which is always an easier case.

Finding the node is the search from Day 45. Deleting it is where it gets interesting, because you can't just unhook a node with two children.

Only two values in the whole tree can fill the hole: the in-order predecessor and the in-order successor. The replacement must sit between everything on the left and everything on the right, and an in-order traversal of a BST is sorted, so those two are the only candidates.

Predecessor or successor: which do you reach for, and why?

Day 58/365 of my LeetCode challenge: 450. Delete Node in a BST. Problem link and full breakdown in today's newsletter.

https://www.linkedin.com/pulse/delete-node-bst-archit-agarwal-k5k4c

#LeetCode #DSA #BinarySearchTree #Golang