Day 28 of 30
One leetcode problem a day or I pay a follower $500. No AI. No autocomplete. No copilot
Problem of the day : 2452. Words Within Two Edits of Dictionary
I built the clever version, measured it, and it was 3x " points straight at Levenshtein distance and its O(n^2) table. But the definition given only allows changing a letter to another letter, and all the words are the same length. No insertions, no deletions, so the alignment is forced. Position i only ever meets position i.
That kills the DP before it starts. It is Hamming distance and a counter.
Then I tried the standard trick for bulk lookups: split each word into 3 blocks, note that two words within 2 edits must share a block exactly, hash the dictionary by block, probe 3 buckets per query. Textbook.
On random input it was indistinguishable from the plain triple loop. On the adversarial case it ran 1.21 ms against 394 microseconds, because when the dictionary words share their blocks, every probe returns the whole dictionary and the hashing is pure overhead on top of the same comparisons.
→ read what the spec allows, not what the word implies
→ clever pays off at a scale you may not actually have
→ build it, measure it, then delete it
Shipped the loop. Kept the benchmark.
One leetcode problem a day or I pay a follower $500. No AI. No autocomplete. No copilot
Problem of the day : 2452. Words Within Two Edits of Dictionary
I built the clever version, measured it, and it was 3x " points straight at Levenshtein distance and its O(n^2) table. But the definition given only allows changing a letter to another letter, and all the words are the same length. No insertions, no deletions, so the alignment is forced. Position i only ever meets position i.
That kills the DP before it starts. It is Hamming distance and a counter.
Then I tried the standard trick for bulk lookups: split each word into 3 blocks, note that two words within 2 edits must share a block exactly, hash the dictionary by block, probe 3 buckets per query. Textbook.
On random input it was indistinguishable from the plain triple loop. On the adversarial case it ran 1.21 ms against 394 microseconds, because when the dictionary words share their blocks, every probe returns the whole dictionary and the hashing is pure overhead on top of the same comparisons.
→ read what the spec allows, not what the word implies
→ clever pays off at a scale you may not actually have
→ build it, measure it, then delete it
Shipped the loop. Kept the benchmark.
Day 27 of 30
One leetcode problem a day or I pay a follower $500. No AI. No autocomplete. No copilot
Problem of the day : 874. Walking Robot Simulation
Nothing to discover in this problem. That is the trap.
The statement the answer is that machine, so the pull is to transcribe it in thirty seconds. Everything that can go wrong is in the transcription, in three places.
→ Turn arithmetic. Storing the heading as an index into N, E, S, W makes a right turn +1 and a left turn -1 mod 4. Go's % takes the sign of the dividend, so facing north and turning left gives -1 and the next lookup panics. Not a wrong answer, a crash, and only on inputs the first example never produces. Writing a left turn as +3 removes the case entirely.
→ Where you sample the distance. Once per command, not once per step, because squared distance along a straight segment is convex, so the maximum sits at an endpoint. Two lines of justification instead of a shrug.
→ The obstacle sitting at the origin needs no code at all. The loop only ever tests the square it is about to enter, so an obstacle underfoot is inert while you stand on it and blocking the moment you try to return. Exactly the described behaviour, for free.
Transcription bugs do not announce themselves.
Sep 13, 2026 · 11:38 AM UTC
2
1
5
605
