So technical interview today but woke up (6am) and started thinking about it and it led to this rant about algorithms. This is probably going into a Medium post if I ever get around to finishing it but sort of just wanted to share the rant that literally just went off in my mind.

*The problem with Algorithms Technical Interviews Is They don't test Real skills*

Real world problems are complex and often cross domain combining experience in multiple areas. Often the best way is not obvious unless you're a polymath and familiar with different areas, paradigms, designs. And intuitively can understand, reason, and combine them.

I don't think this is something a specific algorithm problem is designed to show. And the problem is the optimal solution to some of these and to algorithm design itself is that unless you train for it or are an algorithm designer (practice and experience), you can only brute force it in the amount of time given.

And quite frankly the algorithms I think we rely on daily weren't thought of in 30 minutes. The designers did this stuff for a living, thought about these problems for days and several iterations… at least. A lot were mathematicians. The matrix algorithm that had a Big O of 7N required a flash of insight that only someone constantly looking and thinking about the equations could see.

TBA
-system design
-clean readable coding practices
...

TLDR: I could probably go on and on about this stuff for hours jumping from item/example/area to the next and back again... But I don't think you can test these (~20) years of experience in a 1 hr technical interview focused on algorithms...

Lua has made my life simpler! 👐

I kind of don’t like OOP. There I said it.
Don’t get me wrong there are times I like using it. I don’t mind some of the features but I can rarely find times I want to use them.

It can be useful depending on the project but I mostly don’t use it and when I’m using Python I always feel like I have to? I know Python offers multiple types paradigms of programming to use but everyone’s making a big deal about OOP and I can rarely ever find uses for it. What I said for Python also goes for C++ I feel like I’m forced to do it. And I especially hate it in C++ fuck that.

I’d just like to use Python, and C++ without using it or if I do not have to use all the fancy features. And kinda wish Java and C# didn’t force OOP on you but I just don’t use all the fancy features in those languages (I don’t even use java but I’m mostly talking about C# for that one).

It’s not that I don’t know how to use it it’s that I can never find a use for any of the features or just don’t want to actually do it. Personally I only really see it shining in Game development, GUI development, and MAYBE network programming??

By all means I’m not trying to flame on OOP, I just wanted to throw my OOPinion (HA) on the matter. in fact you can tell me why you like it or dislike it. I’d like to discuss the topic with anyone.

Note: I had AI rephrase this because apparently it was too full of swearing or smth to be accepted and I was getting a "there was an error posting this rant". Nice that people at devrant's can't even show a clear error of WTF is going on, not even in chrome dev tool console/network requests, so maybe you're able to figure out WTF is going on and fix your post. They must be the same kind of people I'm ranting about.

-----------End of the note.----------------
TL;DR;: My coworkers are smart idiots that learn fast but can't control themselves into turning any project into a trashcan of spaghetti code and I'm burning out and want to switch for couple years to a simpler job.

I'm considering leaving my career in programming, consulting, and project management in favor of a more straightforward, manual labor job—perhaps something like baking or another role that relies on physical effort rather than constant problem solving.

I’ve reached a point where I can no longer tolerate the challenges of my current position, especially due to the dynamics with my coworkers. I long for a day where I can work for eight hours, exhaust myself physically, and then go home without any lingering mental responsibilities or ties to complex problem solving.

Over the past decade, I’ve collaborated with many people, yet I've only had the opportunity to manage an entire project from scratch on my own twice. In those rare instances, everything ran smoothly, issues were quickly resolved, and the code remained stable for years without constant complaints from clients.

Unfortunately, my coworkers, despite their intelligence, tend to overcomplicate even simple tasks. They often fall into the trap of overengineering, chasing the latest technologies and implementing unnecessarily complex paradigms, design patterns, frameworks, and techniques—even when I’ve offered simpler, proven solutions.

For example, I’ve built robust portals that handle everything from national highway finances and warehousing to HR and inventory management for major companies. In contrast, when others attempt similar projects, the resulting code becomes overwhelmingly complex and difficult to manage.

To give a few specific examples:

Example 1: The .NET Portal
We began developing a .NET portal about two months ago, which is now nearing version 1.0. Before we even started, the team had created multiple flowcharts to split the project into components like SaaS deployment, Docker integration, obfuscation, and separate portals for user administration and backend processes. Within a few weeks, they scrutinized and debated numerous authentication technologies—even though we had successfully implemented JWT token solutions in the past. The team continually shifts focus, leaving me uncertain about the final direction.

Example 2: Over-Engineering with Patterns
In another project, the team overused inversion of control (IoC) and mediation patterns, even going so far as to have an AI generate a custom message bus. Navigating this overly decoupled code is challenging; even Visual Studio’s IntelliSense struggles to provide guidance, and the code often feels like a puzzle that changes whenever I return from a break.

Example 3: Complicated Logging Implementation
We needed to add logging functionality, and I proposed a simple solution using custom exceptions that would bubble up to a central logging mechanism. Despite its past success in saving time and reducing frustration, the team decided to implement three different logging methods—one using .NET’s ILogger, another with Serilog, and a third hybrid approach. They even suggested using a rarely seen technique involving stack traces to determine which function threw an error. This approach added unnecessary complexity and only increased my frustration.

Now, even though the project is too far along for me to withdraw, I find myself feeling burned out just a few days back at work. The code has become a tangled mess, and even routine tasks like adding logging are turning into sources of intense frustration due to constantly shifting ideas and overly complicated designs.

On top of all this, I’m also disappointed with the performance of AI tools, which seem to be producing unreliable code that requires further fixes, compounding my frustration.

I’m now seriously contemplating a complete career change—perhaps even moving to a country with a better work environment, such as Denmark or Switzerland—in the hope of finding a job where the work is more straightforward and less mentally taxing and better paying