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.

Hello. Im 2nd year betch student. Rn i know python and im learning Django and further going with python full stack. But the catch is idk wheather i should be doing or starting dsa and if yes in which language?

I dont have any main goal. But i also dont want to get into multiple things and not learn anything. So please help

Hey everyone.I am starting my dsa journey today i am in tier 2 gov college first sem. I am starting from striver a to z course today... any suggestions would be helpful

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

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

Hey everyone,
Is there a GitHub repo, spreadsheet, or any resource that has LeetCode links for all the questions in Striver’s new 180-question sheet (Master Patterns)?
I was working through the old SD sheet and had been tracking my progress, but now that the sheet is no longer available, I’ve lost my progress tracking as well.
I’m planning to start again with the new 180 sheet, but having to manually search for every single question on LeetCode is going to be a pain.
Has anyone compiled all the LeetCode links in one place? Even a partially completed list would be really helpful.
I’d rather spend my time solving problems than searching for them one by one. 😂
Thanks in advance!

A candidate is trying to make sense of a coding interview that started with the right-looking algorithm but ended without a code walkthrough.

The earlier behavioral round covered the resume, services the candidate had built, and engineering trade-offs. In coding, the task was a graph with n nodes and transmission lines as edges, each with an efficiency between 0 and 1. Given a source and destination, find the path with maximum efficiency.

The candidate immediately proposed Dijkstra and explained the approach. The interviewer asked about DFS and BFS. The candidate described DFS but worried that enumerating paths could take O(V!) time in the worst case. During the BFS discussion, several suggestions were rejected before the interviewer said BFS wasn't a solution for this problem.

That discussion ate into implementation time. The candidate coded the Dijkstra approach and explained complexity, but didn't get to walk through an example. Questions about node/edge counts and whether a path was guaranteed were also missed, and the interviewer called that out.

How would you weigh the algorithm choice against the missing clarification and validation? There's no way to infer the final hiring decision from this account alone, but I'd be interested in how interviewers assess those gaps.

For the next practice session, real technical interview questions can provide prompts to rehearse clarifying constraints and reserving time for a dry run. If a wider search is taking up that practice time, application autofill and Agent autoapply can cut down repetitive application forms.

What helps you handle alternative-approach follow-ups without losing the time you need to implement and test?

Disclosure: I operate PracHub and LandOffer.