Rung 3 — “Explain the Algorithm” Blog Series¶
Month: M3–M4 | Mode: Communication | Platform: Hashnode or Dev.to
Teaching is the hardest test of understanding because it removes every hiding place. You cannot gesture at a diagram and say “you know, like this.” You cannot say “it’s similar to what we discussed earlier.” You have to build understanding from zero, in words, for someone who doesn’t share your mental model. Every gap in your own understanding becomes a gap in your explanation — and readers find those gaps faster than you expect.
Five blog posts, five algorithms, published publicly. Not polished conference talks — clear, honest explanations with worked examples and the humility to say “here’s what most people get wrong, including me at first.”
What It Is¶
A series of 5 blog posts on a public platform (Hashnode or Dev.to) that explains 5 algorithms to a beginner audience. Each post is written by you, in your voice, from your understanding. Not a tutorial recycled from a course you watched — a genuine explanation of what you actually understand about how the algorithm works and why.
Platform Choice¶
Hashnode — has a developer community, supports custom domains, good SEO, built-in analytics. Best if you want a personal blog feel with community reach.
Dev.to — larger built-in audience, more social (comments, reactions), easier to get early reads. Best if you want immediate community engagement.
Pick one and commit. Cross-posting to the other later is fine. The engagement criterion (3 genuine human responses) is easier to meet on Dev.to due to community size.
Do not start a personal GitHub Pages site for this rung unless you already have one. Setup friction will eat your writing time. Use an existing platform.
The 5 Posts¶
Post 1: Binary Search — Including the “Search on Answer” Generalization¶
Why this post: Binary search is the algorithm most engineers think they understand and most engineers cannot implement without a bug. The off-by-one errors are legendary. More importantly, the “search on answer” generalization — binary searching on the answer space rather than the data — is a pattern that unlocks a class of hard problems that look nothing like binary search at first glance.
What it must cover:
The core algorithm with a clean, bug-free implementation (and why
mid = lo + (hi - lo) / 2instead of(lo + hi) / 2)A concrete traced example: searching [2, 5, 8, 12, 16, 23, 38, 56, 72, 91] for 23
Why binary search finds the answer in O(log n): derive it, don’t state it
The “search on answer” generalization: the insight that you can binary search on any monotonic predicate, not just a sorted array
One worked example of search-on-answer: “find the minimum speed to eat all bananas in h hours” (LeetCode 875) or similar — trace through why binary searching on speed works
“What most people get wrong”: the infinite loop bug in
while lo < hivswhile lo <= hidepending on invariant
Length: 800–1200 words. Diagrams strongly encouraged (even ASCII diagrams work).
Post 2: BFS — Why It Finds the Shortest Path¶
Why this post: BFS is one of those algorithms where the “how” is simple but the “why it’s correct” is subtle. Most people know “BFS for shortest path, DFS for reachability” without understanding the invariant that makes it true. That invariant — that BFS processes nodes in non-decreasing order of distance from source — is worth understanding precisely.
What it must cover:
The algorithm with a queue, clearly traced on a small graph (6–8 nodes, show which nodes enter and leave the queue at each step)
The key invariant: at any point in BFS execution, all nodes at distance d are processed before any node at distance d+1 — explain why the queue structure enforces this
Why BFS gives shortest path in unweighted graphs: derive it from the invariant
Why BFS does NOT give shortest path in weighted graphs (preview of Dijkstra)
BFS on a grid: the translation from 2D coordinates to graph (this is where LeetCode grid problems live)
“What most people get wrong”: not marking nodes as visited when enqueuing (vs. when dequeuing) — the subtle bug that causes re-processing
Length: 900–1300 words. A queue trace table (node | distance | neighbors enqueued) is worth including.
Post 3: The Recursive Structure of Merge Sort¶
Why this post: Merge sort is the canonical divide-and-conquer algorithm. Understanding why it works at the recursive structure level — not just “split, recurse, merge” but what guarantee the merge step relies on — builds the mental model for all divide-and-conquer reasoning.
What it must cover:
The recursive structure clearly stated: if both halves are sorted, merge produces a sorted whole — and this is the entire algorithm, recursing down to base case (1 element is sorted)
A full trace on [38, 27, 43, 3, 9, 82, 10]: show the split tree and the merge tree
The merge step in detail: two-pointer approach, why O(n) time
The recurrence T(n) = 2T(n/2) + O(n) and its solution via Master Theorem
Space complexity: why merge sort requires O(n) auxiliary space (the temporary arrays in merge)
Why merge sort is stable (equal elements maintain relative order) — and why that matters
“What most people get wrong”: confusing in-place merge sort (hard, rarely used) with standard merge sort (O(n) space, what you actually want)
Length: 1000–1500 words. The split/merge diagram is essential.
Post 4: How Hash Maps Handle Collisions (with Diagrams)¶
Why this post: Every engineer uses hash maps. Almost none can explain what happens when two keys hash to the same bucket, why O(1) average lookup is a probabilistic claim not a guarantee, or what a hash map looks like when load factor exceeds 0.75. This post closes that gap — and since you built one in Rung 2, you can write from direct experience.
What it must cover:
What a hash function does (maps key → bucket index) and why collisions are inevitable (pigeonhole principle)
Separate chaining: diagram showing an array of buckets where each bucket is a linked list
Open addressing: brief explanation of linear probing as an alternative
Why average lookup is O(1): expected chain length is O(1) when load factor is bounded — explain the assumption (uniform hashing) and what it means
Load factor threshold: why 0.75 is a common choice (empirical balance between space and collision rate)
Rehashing: what it is, why it’s O(n), why it’s O(1) amortized
“What most people get wrong”: treating O(1) as a guarantee (it’s an expectation under uniform hashing assumptions; pathological inputs can produce O(n) worst case)
Length: 1000–1400 words. Bucket diagram (even ASCII) is required.
Post 5: One Algorithm of Your Choice from Phase 2¶
Why this post: This is the one post where you decide what you found most interesting or most surprising in your Phase 2 study (Months 3–5: trees, graphs, dynamic programming basics). Choose an algorithm that genuinely surprised you, confused you initially, or produced an “aha moment.”
Good candidates:
Cycle detection via Floyd’s tortoise and hare (the pointer math is non-obvious and elegant)
Why Dijkstra fails on negative edges (specific failure mode, illuminating)
The recursive structure of tree DFS and why pre/in/post order produce different results
The two-pointer technique on a sorted array (why it’s O(n) not O(n²))
Kadane’s algorithm for maximum subarray (the state transition insight)
Whatever you choose, it must cover:
Intuition (why does this algorithm do what it does?)
Worked traced example
Complexity derivation
“What most people get wrong” section
Your personal “aha moment” — the thing that made it click for you
Length: 800–1200 words.
Post Template¶
Every post follows this structure (adapt language to your voice, don’t copy this verbatim):
Title: [Algorithm Name] — [One-line hook that promises the reader something specific]
Opening paragraph: A concrete problem scenario that motivates why someone needs this algorithm.
Section 1: Intuition
[Explain the core idea in plain language before any code or math]
Section 2: The Algorithm
[Pseudocode + step-by-step traced example]
Section 3: Why It Works
[The invariant or correctness argument — not hand-wavy, but not a formal proof either]
Section 4: Complexity
[Time and space, with the derivation, not just the answer]
Section 5: What Most People Get Wrong
[A specific bug, misconception, or edge case that trips people up]
Closing: Link to your implementation in ds-from-scratch (if applicable) or your complexity-audit repo.
Acceptance Criteria¶
5 posts published on Hashnode or Dev.to
Each post has: intuition, worked example, complexity derivation, “what most people get wrong” section
At least 3 genuine human engagements (comments, reactions with non-trivial text, shares) across any of the 5 posts
No AI-generated content (community readers will notice; the engagement criterion requires actual value)
Posts link back to your GitHub repos (complexity-audit, ds-from-scratch) where applicable
You are satisfied that someone who reads each post leaves understanding the algorithm better than before
Getting That First Engagement¶
Engagement doesn’t happen organically at zero-audience stage. Do these:
Post in relevant communities: Share your post in r/learnprogramming, r/java (or r/cpp), or relevant Discord servers for programmers. One sentence: “I wrote about [algorithm] — specifically the part most tutorials skip about [X]. Feedback welcome.”
Tag relevant accounts on Dev.to: Dev.to has a community that responds to genuine technical content.
Comment on other people’s posts: Read and comment on similar posts on your chosen platform. The community is reciprocal.
Share on LinkedIn: Your professional network may include people learning or interested in algorithms. Even 1 thoughtful comment counts.
You do not need to go viral. You need 3 humans to engage. That is a very achievable bar.
Signal It Sends¶
“This person can communicate algorithms clearly.”
Teaching is the hardest test of understanding. A working implementation proves you built it. A clear explanation proves you understand it well enough to transfer that understanding to someone else. That is a different and rarer skill. It’s also directly relevant to technical writing, onboarding, code review, and any collaborative technical work.
The blog series also creates a permanent reference. When you encounter binary search edge cases in 6 months, your own post is one of the best references you have — because you wrote it to explain what confused you.
Timeline¶
Week |
Target |
|---|---|
Week 1 (M3) |
Write Post 1 (Binary Search) + publish |
Week 2 (M3) |
Write Post 2 (BFS) + publish |
Week 3 (M3/M4) |
Write Post 3 (Merge Sort) + publish |
Week 4 (M4) |
Write Post 4 (Hash Maps) + publish |
Week 5 (M4) |
Write Post 5 (choice) + publish |
Week 6 (M4) |
Promote posts, respond to comments, verify 3 engagements |