Last week's contest ratings are now updated. I got to 2143, and am officially a Guardian now. It took me ~ 1 year of consistent practice and upsolving contest questions to reach this.

How many problems in a Solved list could you solve from a blank editor, with someone watching?

A candidate had solved roughly 320 LeetCode problems but still froze halfway through implementations. Even problems from a few weeks earlier could be hard to derive again. The green checkmarks were hiding gaps in recall and explanation.

The candidate started checking more after Accepted: identify the pattern without a hint, explain the approach before coding, justify time and space complexity, find edge cases, and dry-run the implementation. Doing that with a clock running exposes different gaps from solving alone.

Review also changed. Opening an old solution and recognizing “two pointers” felt easy, but didn't show whether the reasoning could be reconstructed. Re-solving from a blank editor did. Harder problems came back sooner; easier ones could wait a few days, then a week or two, then about a month.

The spreadsheet, notes, and calendar reminders eventually became another chore. A lighter routine was easier to maintain: a minute or two of reflection, a short note on the mistake, and a manageable daily review load that left room for unfamiliar patterns.

Real technical interview questions can supply fresh prompts for checking whether a pattern transfers. If applications are competing with practice time, Agent autoapply and application autofill can reduce repeated application paperwork.

What tells you you're ready to interview? How do you distinguish knowing a pattern from recognizing a problem you've already seen?

Disclosure: I operate PracHub and LandOffer.

I have only 3 months left before semester exams. So somebody who had an idea how I would complete dsa and mern( mern mai kr lunga sath mai kuki web development jaldi smjh skta hu mai) dsa ke liye proper khuch smjh nhi aa rha logic aa rhe h but striver se padha toh vo cpp se krata h and mai java se hu , jab raghav garg se padha toh question mujhe khud hi krne h isliye thoda idea dedo koi , abhi tak mai randomly leetcode attempt kr rha tha and yes mujhe smjh aaye bhi question and solve bhi kiye h ache se

Course Schedule (Medium) https://leetcode.com/problems/course-schedule/

You can finish every course unless some group depends on itself: A needs B, B needs C, C needs A. Nobody in that group can ever start. So this is cycle detection in a directed graph, phrased as scheduling.

Kahn's algorithm: count how many prerequisites each course still has, queue everything at zero, and each time you finish a course, decrement everything it unlocks.

The line that separates this from an ordinary BFS is small. In a BFS a node is enqueued the first time it is REACHED. Here, reaching a node only decrements its counter - it is enqueued when that counter hits ZERO. A course with three prerequisites is reached three times and queued once. That if is not an optimisation, it is the scheduling rule.

Then the cycle check, which never looks for a cycle:

`return len(result) == numCourses`

Courses stuck in a cycle never reach in-degree zero, so they never enter the queue and never appear in the result. The cycle is detected by what fails to show up.

That closes the graph arc on the same move yesterday used - inferring a cycle from a count rather than searching for one.

Full breakdown in today's newsletter article ⬇

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

#DSA #LeetCode #Golang #Graphs #TopologicalSort #CodingInterview #Algorithms

I'm interested in getting into web development. I know basic Java but I'm not interested in Python. Which language should I learn next? Should I continue with Java, learn JavaScript, explore Rust or consider something else? What would be the best choice for a beginner looking to build web applications?

i am stuck at this rating man idk why, please suggest me something..

A function that returns 200 log lines, and keeps 186 MB alive after it returns. The 200 lines are about 20 KB.

The job: a crash reporter attaches the last 200 lines of the request log to the report. The log is a stream - a scanner over a file, a cursor over a table, a channel fed by a tailer. It hands you lines in order and does not know how many there are.

```

var all []string

for line := range log {

all = append(all, line)

}

return all[len(all)-n:]

```

I have written that in two languages. One idea, reads like the ticket.

Then I measured the live heap with the answer still held, rather than the clock. Two million lines: 186 MB, still there after the function has gone out of scope.

all[len(all)-n:] is a window onto the array all grew into, not a new array, and a slice keeps its whole backing array alive. A test reads the capacity off the returned value: len 200, cap 169,032.

One line fixes the retention. Copy the tail into a slice of its own, and 186 MB becomes 20.8 KB. If you take one thing from this post, take that.

It does not fix the peak. The copy runs after the collection finishes, so the two million lines were all in memory a moment earlier, and that moment is where a container gets killed.

Counting the stream first and walking it again is exactly 2.00x at every size in the benchmark, and it needs a way to start the walk twice - which a file gives you and a socket does not.

What the data was actually saying: the only lines that can be in the answer are the 200 most recent ones, and that is true after every line, not just at the end. So keep 200 and evict the oldest. A fixed-size buffer that wraps does it with no bookkeeping, because the write cursor and the oldest line are exactly n apart and never drift. That gap is the length nobody computes.

8528x less held on a two-million-line log. And, honestly: 1.08x on the clock. This is a memory fix and selling it as anything else gets it rejected by a reviewer who benchmarked throughput.

The benchmark's own allocation column says 1.98x, because both versions allocate every line - the scanner produces them either way. Allocation 1.98x, retention 8528x. A profiler pointed at allocation shows you the first number and shrugs.

At a few hundred lines, collect it. 34 microseconds, 21.8 KB, and it answers the next question too.

That is days 20 and 24 of the daily challenge - Middle of the Linked List and Remove Nth Node From End - sitting in a crash reporter.

Full piece in today's Newsletter.

It worked in dev, episode 14.

https://www.linkedin.com/pulse/your-crash-report-held-186-mb-log-send-200-lines-archit-agarwal-hyyzc

#Golang #DSA #Algorithms #Performance #SoftwareEngineering #DataStructures #100DaysOfCode