In-person interviews are back

I believe online assessments and coding interviews have been effective so far. However, I expect many companies will start rethinking their interview processes. The main challenge is that it’s difficult to truly evaluate a candidate’s abilities in just an hour.

leetcode-style problems and system design interviews have helped raise the bar, but as tools and AI models become more advanced, it will get easier to perform well on these types of interview questions. Because of that, I think mid-sized companies will begin to focus more on “How…” questions—emphasizing a candidate’s real-world experience rather than just testing their ability to solve leetcode-style problems.

As coding becomes less of a bottleneck in software development, interviews should shift toward evaluating a candidate’s practical experience, decision-making, and approach to solving real problems.

There Is No Perfect Code

The idea of clean code and clean architecture is often widely promoted by people of varying levels of experience. I sometimes hear folks discussing or debating this concept, making arguments based on commonly cited "best practices"—that it should be this way or must follow that convention. But in reality, there is no such thing as perfect code in production systems.

Over the past several years, I've worked on a variety of projects with different teams, and each project had its own level of quality, its own quirks and constraints. Not once have I encountered a codebase that could genuinely be called "perfect" (maybe I will one day).

What seems like perfect code today can easily become tomorrow's technical debt. Code doesn't remain static unless it's part of a small, throwaway project. What we write today is shaped by our current understanding and context, but it will inevitably change. Shifting business goals, changing requirements, and new constraints like latency, scalability, or compliance force us to adapt. That adaptation affects the code.

What we think is clean and ideal today can turn into a mess later. Or the opposite, something that seemed messy at first might end up being a practical solution. Building systems is always about trade-offs. Every system has different needs and goals: performance vs. readability, flexibility vs. simplicity, speed of development vs. stability. Improving one thing often means giving up something else.

Even the cleanest codebase decays. Without continual refactoring and maintenance, even well-written code degrades over time. I've seen many codebases slowly rot due to accumulating tech debt and a lack of care. That's why I believe the notion of "perfect code" is inherently short-lived.

In some cases, a team's obsession with clean code can even lead to project failure. In my experience, striving for perfection has delayed projects delivery and sometimes caused more harm than good. That's why I recommend avoiding over-engineering. There's no point in having beautifully crafted code if no one ends up using your product.

TypeScript's Dark Sides

I have been working within the TypeScript (TS) ecosystem for the past 4.5 years. During this time, I have worked on various codebases written in TS, each employing different approaches and mental models. Before discussing the problems associated with TypeScript, it's important to first consider the benefits it offers. TypeScript promises better tooling, improved type safety, and several other advantages. One of the key assertions often made by TS developers is that the type safety provided by TS facilitates the early detection of pre-compilation errors and improves the maintainability of projects. I agree with these statements to some extent. However, these claims no longer hold true once your codebase starts growing.

I believe one of the biggest issues is that TS was invented to solve JS issues. Most of the design decisions were made with compatibility with untyped legacy code in mind. TS prioritizes developer ergonomics over rigorous correctness, which has led to many poor design decisions. It opens the door to bypassing type-level checks, which in turn contradicts its promises.

You don't get a true sense of type safety. Even if the code compiles successfully, the chances of runtime errors persisting are high. In large projects, one of the most important things is strong compile-time guarantees, which TS cannot provide. This is because it's so easy to use any, unknown, type coercion, or abuse type assertions. Moreover, another significant issue is that the ecosystem itself is not reliable. As your project grows, you'll need to integrate different software and libraries, which in turn affect your codebase. If an SDK, library, or any external tool is not well-maintained or well-designed, you'll end up breaking things on your end or rewriting everything that those things provide (which is less likely to happen).

Additionally, the testing ecosystem sucks. As your project becomes larger, testing becomes very important. In TS, most popular testing frameworks and tools do not provide good type safety. From my experience, most of the teams that use TS end up using various workarounds, which significantly lowers the quality of your tests. I've encountered tests that appear to work due to low type safety (even they are broken). When you have large objects involved in testing, things get really complicated as you make changes to parts of your codebase.

To recap, I would say TS is good for shipping small projects on time. However, as the complexity of a project increases, the more you'll suffer from the fundamental issues the language has.

Using the conversations plugin feels so much better after years of using a mix of session based routers and state based step functions.

🌙 Eid Mubarak

Good starting point for AI agents and agentic flows.

AI economy

I was surprised with the results of the poll I posted recently. Claude won on spot (I assume that's because many of you are developers who use Claude Code), although I expected ChatGPT to take the lead followed by Gemini. Probably Anthropic's never ending hype makes itself known. Well this is a great opportunity for me to break everything down for you.

Anthropic's CEO - Dario Amodei is on every interview or show lately telling you and me that AI is coming for our jobs. I wonder if he's transitioned to chief marketing officer or some sort. But I get it, they need investors' money, looots of money. The company predominantly trains AI models and give you limited access to it for subscription fee. And training them is expensive, I mean EXPENSIVE.

Let's do some math. Sources say that training a frontier model on a cloud provider cost a couple of billion dollars. That's because GPUs that cost hundreds of thousands run day and night nonstop so eventually they have a model capable enough to respond your question. This is just training, running them also costs a bunch but significantly less. In a reasonably competitive market it's gonna make the company very hard to do their job if they rely on cloud providers only.

The solution is building a high end data center. The one with 1 Gigawatt power tailored for AI compute that would costs around $50B to build. That's land, energy, facility, cooling and hardware and additional 3-4 billion dollars annually to maintain it - technicians salary cost, electricity, water for cooling, hardware fixes and replacement. Still unimaginable amount of money, a third of Uzbekistan's GDP per say.

Yet I didn't factor in sales, marketing, engineering and all other administrative costs. To make such a business model work they need to scale out. Scale to tens of millions of users at the very least. Otherwise they still risk running out of money and getting bankrupt. Dario is probably praying every day for hardware to get cheaper, U.S government to go easy on them, so they reach IPO with trillion dollars valuation and he can take his big bag of profit from selling his shares just in case if they get crushed.

The same goes to OpenAI. Dario was OpenAI employee before leaving and founding Anthropic, of course he learned some tips and tricks from OpenAI's CEO Sam Altman. By the way I noticed that they both have jewish roots. They probably know how to play the game, I'm not being a racist here, just saying, ya know...

#tech