I started Kata as a problem-solving practice project.

The point was never to collect problems. The point was to practice the process of solving them: reading carefully, writing down a first idea, finding where that idea breaks, and then turning the rough reasoning into a clear solution.

After the first 24 kata, the most useful lesson is not a particular algorithm. It is this:

A problem often becomes easier when I stop asking for the final answer directly and start asking what information each step should produce.

Full project: Kata

The First Pattern: Remember The Right Thing

The early problems were mostly about arrays, strings, and simple lookup.

001 · Two Sum started with the obvious brute-force idea: check every pair. The better question was not:

Which two numbers add to the target?

but:

If I am looking at this number, what complement would I need, and have I seen it before?

That small change turns a nested loop into a single pass with a hash map.

The same idea appears again in 007 · Contains Duplicate. If the only question is whether something appeared before, a set is a better mental model than a list. A list stores values, but a set answers the question:

Is this already here?

004 · Valid Anagram adds one more step. It is not enough to know whether a character appears. The count matters. So the right memory is not a set, but a frequency map.

These problems look simple, but they introduced an important habit:

Before choosing a data structure, define the question it needs to answer.

Boundaries Matter More Than They Look

Several problems were really about boundaries.

In 003 · Binary Search, the first instinct is to cut the array or look at the middle. But the real work is maintaining two boundaries, left and right, without losing the original index.

012 · First Bad Version made that sharper. The task is not just binary search for a value. It is finding the first position where a condition becomes true.

That changes the update rules:

if mid is good, it cannot be the answer, so move to mid + 1

if mid is bad, it might still be the first bad version, so keep it

This is the part I want to remember: binary search is less about the middle element itself and more about what can be safely removed.

When A Window Is Not The Right Window

009 · Maximum Subarray was one of the more useful early lessons.

At first, it looks like a continuous interval problem. That makes it tempting to think in terms of a moving left boundary and right boundary:

Where should the best subarray start?

But with negative numbers, the window does not behave in a clean monotonic way. Sometimes the correct move is not to shift the left boundary by one step. Sometimes the whole previous prefix should be abandoned.

The better question is:

What is the maximum subarray sum that must end at the current position?

That state is much easier to maintain:

This was one of the first places where the solution stopped being about manually moving pointers and became about defining a state.

011 · Climbing Stairs had a similar shape. It can look like a counting or arrangement problem: how many 1 steps and how many 2 steps are used? But the cleaner question is:

What are the last possible moves into step n?

The answer only depends on step n - 1 and step n - 2.

That is a useful pattern: if listing all possibilities becomes messy, look for the smaller state that produces the current one.

Pointers Are Not Values

The linked list problems were less about algorithms and more about understanding what a variable points to.

In 006 · Merge Two Sorted Lists, the key confusion is not the comparison itself. Comparing two current nodes is straightforward. The question is:

Once I choose a node, where do I attach it?

That is why the dummy node and tail pointer matter. They make the result list easier to build without treating the first node as a special case.

In 014 · Reverse Linked List, the first confusion was more basic but more important:

Is head the value, or the node?

The solution only becomes clear after separating:

current.val: the value inside the node

current.next: the next node

current = current.next: moving the variable forward

The actual reversal is not about printing values backward. It is about changing next pointers.

And before changing current.next, the next node must be saved:

Otherwise the rest of the list is lost.

015 · Linked List Cycle reinforced the same point from a different angle. A cycle is about seeing the same node object again, not seeing the same value again.

That distinction matters. In linked lists, values can repeat. Nodes are identities.

Some Problems Are About The Local Rule

013 · Roman to Integer looked like a collection of special cases at first.

There are many subtractive forms: IV, IX, XL, XC, CD, CM. It is tempting to handle them one by one.

But the common local rule is simpler:

If the current value is smaller than the value to its right, subtract it. Otherwise, add it.

This is a good reminder that a problem with many named cases may still have one small rule underneath.

017 · Plus One had a similar lesson. The first reaction is:

Is this just integer plus one?

Converting the whole digit array into an integer works in Python, but it avoids the real problem. The useful rule is local and starts at the end:

if the digit is not 9, add one and stop

if the digit is 9, turn it into 0 and continue the carry

The problem is not about numbers in general. It is about how carry moves through an array.

Tree Problems Changed The Main Question

The binary tree sequence was the biggest shift in this first batch.

018 · Invert Binary Tree starts with a simple idea:

Swap the left and right child of every node.

The key is realizing that a tree is recursive:

So the function only needs to handle the current root, then let the same function handle the subtrees.

019 · Maximum Depth of Binary Tree made the return value explicit:

maxDepth(root) returns the maximum depth of the tree rooted at root.

Once that is clear, the relation is simple:

020 · Same Tree and 021 · Symmetric Tree pushed the same idea further. The useful move was to define the recursive function with the right arguments:

isSameTree(p, q) compares two current nodes

isMirror(left, right) compares two mirror positions

The function definition matters. If the function receives the right pieces of the problem, the recursive calls become much easier to write.

022 · Subtree of Another Tree then reused Same Tree: one function checks whether two trees are identical, another function moves through root looking for candidate starting points.

That separation is important:

one function answers "are these two trees the same?"

another function answers "does this tree contain a matching subtree?"

The Clearest Lesson: Return Value vs Final Answer

The strongest arc is:

019 · Maximum Depth of Binary Tree

023 · Balanced Binary Tree

024 · Diameter of Binary Tree

They all use subtree height, but height plays a different role each time.

In Maximum Depth, height is the final answer.

In Balanced Binary Tree, height is not enough by itself. The function needs to compute height while also detecting whether a subtree is already unbalanced. A special value like -1 can carry that failure state upward.

That taught me that a recursive return value does not have to be the final answer. It can be the information the parent call needs.

Diameter of Binary Tree made this even clearer.

The first thought was to ask whether the longest path goes through the root, or whether it sits inside the left or right subtree. That leads to awkward comparisons like:

Should I compare the two branches inside root.left with the longest branch from root.right?

This quickly mixes two different ideas:

the best diameter already formed inside a subtree

the single downward height that can be returned to a parent

The better question is local:

For each node N, if a candidate path has its highest point at N, how long is that path?

Then the candidate length is:

The recursive function still returns height. The final diameter is updated separately while visiting each node.

That distinction feels important enough to write down:

The return value is what the parent needs. The final answer is what the whole problem asks for. They are not always the same thing.

What This Batch Taught Me

Looking across the first 24 kata, the repeated lesson is not "use hash map" or "use recursion" or "use two pointers".

The repeated lesson is to ask a sharper question.

Instead of:

How do I find the answer?

ask:

What information do I need at this step?

Instead of:

Which case is the answer in?

ask:

Can I define a local rule that covers all cases?

Instead of:

What should the code look like?

ask:

What should this variable or function mean?

That is the part I want Kata to keep training.

Full project: Kata

Cell by Cell

After 24 Kata: Learning To Ask A Better Question

The First Pattern: Remember The Right Thing

Boundaries Matter More Than They Look

When A Window Is Not The Right Window

Pointers Are Not Values

Some Problems Are About The Local Rule

Tree Problems Changed The Main Question

The Clearest Lesson: Return Value vs Final Answer

What This Batch Taught Me

Welcome to My Blog

Why a Blog?

What to Expect?

Final Words for This Awkward Hello