A Survival Check-in: On Overthinking a Zero-Level Problem

Why I’ve Been Quiet Lately

I haven’t posted in a while.
Actually, “a while” is an understatement—it’s been almost half a year since my last post.

If you’re wondering what I’ve been doing instead of writing, there isn’t a dramatic reason.
- My domain was about to expire, so I migrated to a new one.
- I’m in the middle of an endless blog refactor—though at this point, it’s closer to rebuilding everything from scratch.
- I built a web application for a friend’s business, and along the way created a handful of automation tools purely for my own convenience.
- And lastly, I’ve been grinding what I consider my biggest weakness: coding tests and CS fundamentals.

In short, I’ve been spending more time on how I think, rather than on visible output.

So Here’s the Code I Want to Talk About

This one.

def solution(num_list):
    return [even := sum(i % 2 == 0 for i in num_list), len(num_list) - even]

This function returns the number of even and odd elements in num_list.

It’s from a zero-level problem on Programmers called “Count Even and Odd Numbers.”
The constraints are trivial:
- List length: 1 ≤ n ≤ 100
- Value range: 0 ≤ value ≤ 1000

It’s not a difficult problem by any stretch.
The canonical solution looks like this:

even, odd = 0, 0
for i in num_list:
    if i % 2 == 0:
        even += 1
    else:
        odd += 1
return [even, odd]

There’s nothing wrong with this solution.
It’s just not my choice—specifically in the context of coding tests.

To put up a quick disclaimer: I draw a hard line between code written for production and code written for coding tests.

In real-world projects, I prioritize readability, collaboration, and long-term maintainability.
In coding tests, however, I deliberately push things as far as they can go.

This post isn’t about showing off “production-quality” code.
It’s about documenting my thought process.

Thought Process #1

sum(1 for i in num_list if i % 2 == 0)

If a number is even, return 1 and sum it up.
That gives us the count of even numbers.

Then what about odds?

[sum(1 for i in num_list if i % 2 == 0), sum(1 for i in num_list if i % 2 == 1)]

This already produces the correct answer.
But it iterates over num_list twice and evaluates nearly identical conditions twice.

Given the maximum list length is only 100, this is not a performance issue at all.

Still, regardless of how subjective aesthetics may be, this code doesn’t look beautiful to me.

Thought Process #2: The Walrus Operator

What’s the walrus operator?

It’s a feature added in Python 3.8.

Walrus Operator (:=) Allows assignment inside an expression.

In this problem, it fits perfectly for one reason:

If you know the count of either evens or odds, the other can be derived instantly.

Of course, you don’t need the walrus operator to do this.

even = sum(1 for i in num_list if i % 2 == 0)
return [even, len(num_list) - even]

This already removes redundant computation, and many would stop here.

But if we introduce the walrus operator:

[even := sum(1 for i in num_list if i % 2 == 0), len(num_list) - even]

Readability, collaboration, and maintainability are all thrown out the window—but for someone like me, who enjoys aggressive code compression in coding tests, this is exactly the kind of thing that scratches the itch.

Thought Process #3

There was still room to refine things.

In Python, True evaluates to 1 and False to 0.
So instead of explicitly yielding 1 with a conditional expression, we can rely on boolean arithmetic.

sum(i % 2 == 0 for i in num_list)

To be clear, this difference is not perceptible in practice—especially not with a list capped at 100 elements.

But it removes an explicit conditional branch and leans into Python’s type semantics more directly.

After going through these steps, we arrive at the final version:

def solution(num_list):
    return [even := sum(i % 2 == 0 for i in num_list), len(num_list) - even]

Not many people would solve a zero-level problem this way.
That doesn’t mean this was written as a joke.

Is This Actually Efficient?

Ignoring readability, collaboration, and maintainability for a moment—how does this code fare in terms of complexity?

Time Complexity
- Single pass through the list → O(n)
- All other operations → O(1)

There is no asymptotically faster solution, because every element must be examined at least once.

Space Complexity
- Generator expression (no intermediate list)
- No unnecessary data structures
- Only one retained variable (even)

Space complexity is O(1).

In real-world code, though?

def solution(num_list):
    even = sum(i % 2 == 0 for i in num_list)
    return [even, len(num_list) - even]

Or just a plain loop.
Walrus operators in collaborative codebases are usually more of a hindrance than a help.

Conclusion

This post is not an endorsement of writing code like this.

The point is that even for trivial problems, exploring multiple approaches teaches you what tools exist—and, more importantly, when not to use them.

There’s a fundamental difference between not using something because you don’t know it and not using it because you consciously chose not to.

I wrote this post because I can’t guarantee that my sense of “good code” will stay the same one year—or five years—from now. As I learn new things and my perspective shifts, I may very well end up criticizing the code I wrote today.

Still, the path that led here matters.
This is a record that, in 2025, this is how I thought and how I reasoned.

For those who believe even % 2 == 0 is an unnecessary luxury, there is a bitwise alternative:

return [len(num_list) - (odd := sum(i & 1 for i in num_list)), odd]

Even by my own standards, this is pushing it.
It’s not intuitive, not human-friendly, and once Python’s interpreter overhead is taken into account, it offers no meaningful advantage over the previous version.

That’s where I draw the line.

If anyone solved this problem in a different way—excluding lambdas—I’d genuinely like to see it.
When the thought process is more interesting than the problem itself, there’s usually something worth learning there.