The story of an engineer who started with programming, worked across several startups, and gradually moved into architecture and cloud infrastructure.

Part 1. How It All Began

Question 1. How did you get into IT in the first place?

I got my first computer when I was about seven. I think it was an Amstrad CPC 86. My earliest memory of programming is opening the EXE file of a game called Hunter, where a little guy walked around and shot things. I found some text inside the file, changed it to something like infinite lives, saved it, and expected the game to give me unlimited lives.

Instead, the game stopped launching.

My older brother was furious because we didn’t have another copy, and he played that game all the time. So that was my first programming experience: I wanted to improve a program, and instead I broke it.

Question 2. When did you start programming for real?

At school. My mother taught computer science, and my father taught physics. I spent a lot of time hanging around my mother’s computer lab. We had plenty of computers, and for its time, our school was quite advanced in IT. I think we were among the first schools in the area to get internet access.

The first thing I did was register on Ambitus.ru and start chatting with people.

Then, around eighth grade, I discovered Borland Pascal. That was it. Nobody could pull me away from the computer. I wrote programs and took part in a city conference with a Who Wants to Be a Millionaire? game. I drew the interface in text mode, used circle-drawing functions and timers, and tried to make the graphics work.

Then came CorelDRAW, and I started exploring how websites worked. Around ninth grade, I built a website for my class using HTML. There weren’t many books available, so I would open the source code of other websites, see how they worked, copy things, and modify them.

Back then, we had dial-up internet. If you connected, the phone line was busy, and nobody could call you. Diablo had just come out, we had Word, the first chat rooms, and attempts to hack things through CGI-Bin. I could talk about that period for hours.

Everything was primitive by today’s standards, but back then it felt like an entire world.

Question 3. What did university teach you?

I studied computer security. We had a lot of mathematics, physics, algorithms, cryptography, and low-level programming.

Calculus, linear algebra, differential equations, complex analysis, integrals, Green–Stokes theorems, cryptography, Diffie–Hellman. During the first three years, I was studying almost constantly. Eat, sleep, study, repeat. There was a lot of memorization.

I still don’t know why we had to memorize some of those things. I’ve barely ever used calculus directly in my work, for example. But maybe all that training made my thinking more systematic.

I find it difficult to relax when I don’t understand how something works underneath. I want to get to the mechanism itself, not just memorize which button to press.

We studied Assembly, C++, C#, Windows, and operating systems. Books about Windows internals and the work of Mark Russinovich were practically our desk bibles. Books weren’t easy to find, so we’d download them and print them out. Sometimes the floor would be covered with printed pages.

We had a professor who taught operating systems whom I still consider one of the smartest people I’ve ever met. He explained how everything worked internally extremely well. He also ran a company that worked on projects for international clients. I did well in his course and emailed him to ask if I could get an internship.

That’s how I joined my first professional engineering team.

Part 2. First Jobs and Real Engineering

Question 4. What was your first job?

My first job title was Design Engineer. We worked on low-level Windows development, operating systems, and drivers. For example, I wrote a C driver for virtual COM ports so we could emulate devices and pass data between them.

I also worked on COM emulation and optimizing an LDPC coding algorithm.

After university, I joined a small startup building GPS tracking devices. We developed our own hardware: it received satellite coordinates and sent them to a server over GPRS.

I worked on the server side, writing software for FreeBSD. Multithreading, networking, our own data storage formats, tests, and an administrative application. Initially, we worked directly with WinAPI, then libraries and Qt came along.

It was very low-level work. You needed to understand how processes and threads worked, how networking operated, and what was happening inside the operating system. It wasn’t just about writing code. You had to make the entire system work reliably.

Question 5. Did you already feel confident as an engineer?

No. At first, it was a little scary. When a task came in, I wasn’t always sure I could solve it.

But gradually, I developed what I call an engineering backbone. I realized that if a system has documentation, source code, logs, or at least something you can investigate, you can usually figure it out.

It might take time. You might need to read a lot and experiment. But I stopped seeing an unfamiliar system as something fundamentally incomprehensible.

And in a startup, you’re not just a programmer. I visited customers, installed devices in cars and tractors, talked to farmers, trained users, tested software, provided support, and worked on infrastructure. If the power went out, somebody had to start the generator to keep the server running.

Back then, I didn’t know all these modern job titles. We just had to make the product work.

Question 6. Why do you remember that startup so fondly?

Because those were probably some of the happiest years of my professional life. We worked together, became friends, and built interesting things. The team was very strong, and nobody was trying to pretend we were a big corporation.

I’m grateful that I started my career in that kind of environment rather than in a huge enterprise.

The company was more scientific in nature, with government subsidies and funding. That gave us time to understand technologies, learn how things worked, and experiment.

That’s when I first realized that behind complicated technical solutions, there are usually understandable mechanisms. Over time, new layers of abstraction appear on top of them, and suddenly everything starts looking like magic.

I’ve always felt that a strong foundation matters more than knowing a particular tool. Tools change, but the principles remain.

Question 7. How did you move from low-level development to web and business applications?

At some point, it became clear that everything was moving to the internet. Desktop applications were gradually moving into browsers, new web technologies were emerging, and I’d always been interested in that side of development.

I worked for a company that built software for the restaurant industry: inventory management, restaurant operations, and integrations. It was mostly C# and the Windows stack. I wrote a couple of modules for a large system and stayed there for about a year.

Then I moved to Saint Petersburg, which I consider the most beautiful city in Russia, and joined a company working on clinical trials for pharmaceutical products.

It was another startup, with around twenty people when I joined.

Part 3. Learning to Understand More Than Just Code

Question 8. What was interesting about working in clinical research?

The amount of business context involved.

For the first six months, I was simply trying to understand the domain. What a clinical trial monitor does, what a data manager does, what screening and randomization mean, how patient groups work, how the databases are structured, and why there are so many relationships between them.

It was a very complex process, and I had to understand it not just as a developer, but as someone who needed to understand how the entire system worked.

We developed a CTMS — a clinical trial management system — and rewrote an earlier version of the product. We also worked on web applications and mobile applications for patients.

We used C#, .NET, JavaScript, and various frontend technologies of the time. I participated in developing applications that patients used to complete electronic questionnaires — ePRO.

For example, one project involved research into female libido. Patients answered questions, marked events on a calendar, and completed questionnaires. Another project involved conditions affecting the knee joints.

At some point, you realize you’re not just building another form or table. You’re providing the technical foundation for a huge process — from a scientific hypothesis to collecting data that could help develop a new medicine.

That gave the work an additional sense of purpose.

Question 9. When did you realize you wanted to work remotely?

Gradually. I increasingly felt that spending so much time commuting to an office was strange when almost all the work could be done remotely.

I was already interested in Microsoft technologies, taking certification exams, and working with the Windows stack. At some point, I decided to ask for six months of remote work.

Around the same time, an acquaintance I’d previously built a few web projects for invited me to join his company. We’d never even met in person, but he told me he had plenty of interesting projects and wanted me to work with him full-time.

That began the next stage of my career.

Part 4. A Company That Grew from Four to Forty People

Question 10. What kind of company was it, and what did you do there?

It was Tenging. The company built solutions around Microsoft Dynamics NAV, which later became part of the Business Central ecosystem, as well as solutions for retail and hospitality.

We started with around four people and grew to forty. I was involved in that growth as a technical specialist, although the company had a CTO. In practice, I’d describe my role as technical lead.

Almost the entire technical side passed through my hands: integrations, application architecture, infrastructure, development, and supporting other programmers.

We built our own middleware for Dynamics that allowed us to retrieve data from the system and return it as JSON, making it easier to integrate with web applications. This gave us a flexible foundation for building solutions for our customers.

We developed online stores and other web applications for companies across very different industries. One customer was a cannabis producer in the United States; another was a sushi shop in Iceland. The industries and locations varied widely.

Our main stack became C#, .NET Core, and Azure on the backend, with Vue and Quasar on the frontend.

I think we made some very good technology choices. We could take template projects and adapt them to individual customers instead of rebuilding everything from scratch each time.

Question 11. When did you start working with Azure?

That’s where I started working with Azure seriously.

Previously, I might have handled administration to make sure the code worked. Now I needed to build the infrastructure that allowed the code to run in the right environment.

Virtual machines, virtual networks, domain controllers, connections between services, customer infrastructure, and our own infrastructure — all of that gradually became part of my everyday work.

At the same time, I never stopped being someone who needed to understand the application itself. In a small company, a customer could call you directly and ask why their application wasn’t working on a particular device. You had to investigate everything: the business process, the application, the infrastructure, and the specific problem.

You couldn’t say, “That’s not my responsibility. Please contact another department.” You had to at least understand where the problem was and who could solve it.

Question 12. How did your role change as the company grew?

Gradually, I spent less time programming and more time working on everything around the development process.

I needed to pass my experience on to other developers, help them make technical decisions, configure their working environments, organize projects, and maintain the connections between applications and infrastructure.

I combined several functions: technical leadership, architecture, DevOps, system design, and sometimes business analysis. Not because I wanted to collect every possible job title, but because that’s what the company needed.

It was my first long-term remote job. The company grew, and we developed more complex processes, project management practices, and team responsibilities.

At some point, I wasn’t just writing applications anymore. I was responsible for making sure the entire technical side worked together.

Question 13. Why did you eventually leave?

Startups go through different phases, and it’s important to understand which phase you’re in and what’s happening in the market.

We had delivered many projects, grown, gained experience, and built a reasonably successful technology business. But over time, I stopped agreeing with the direction management wanted to take.

There was an idea to open an office, make the company more corporate, and bring people back into the office. We started hiring what people like to call “effective managers,” but I felt the sales strategy hadn’t been thought through properly.

I believed the company needed to move in a different direction.

At some point, I decided to leave. For me, it wasn’t so much about technology as about understanding how a business should develop and what kind of environment I wanted to work in.

Part 5. Working Internationally

Question 14. What happened after Tenging?

By then, I’d already moved to Colombia and was working remotely. I spoke Spanish, had married a Colombian citizen, and my next job became interesting to me for that reason as well.

I joined a startup developing a new version of an existing SaaS product. The customer and management team were based in the United States, while the technical team was being assembled across Latin America.

I was hired as the first technical person responsible for architecture. Then we started building the team. The managers handled the organizational side of recruitment, while I conducted technical interviews and helped build a team of developers from different countries in the region.

It was my first full experience working in a bilingual team. We spoke Spanish within the team and English with the American management.

I found it interesting not only technically, but also in terms of how people from different countries and cultures work together.

Question 15. What made the product itself interesting?

It was one of the most complex projects I’d worked on.

There were many business rules, complicated relationships between data, and a large amount of information I needed to understand before I could design the system properly.

We were building a new version of the product and introducing Microsoft Document Intelligence for document processing.

Generative AI wasn’t as advanced back then as it is today. ChatGPT already existed, but it often produced rather strange results when used for serious development work. Document Intelligence, on the other hand, could already extract useful data from specific document types after the model had been configured and trained.

We integrated it into the product and built the other components of the system around it.

I was responsible for architecture, helped build the team, led developers, and continued writing some of the code myself — both backend and frontend.

The stack was familiar to me again: C#, .NET, Vue, and Quasar.

We built a proof of concept and released the first version, but then the customer ran out of funding. The project continued with a smaller core team.

For me, it was valuable experience: building a product’s technical foundation almost from scratch, assembling a team, and delivering a complex solution that actually worked.

Part 6. Moving Toward Azure as My Main Specialization

Question 16. Why did you join VIAcode?

After several startups, I joined VIAcode — a company with extensive Azure experience and strong engineers, including people who had previously worked at Microsoft.

My role shifted noticeably from application development toward cloud infrastructure.

I don’t see this as giving up programming. I see it as the next stage. Everything I’d done before — software development, architecture, databases, networking, operating systems, and business applications — now helps me understand cloud systems.

At VIAcode, we work on Azure migrations, building infrastructure from scratch, resource management, security, cost optimization, monitoring, and customer support. There are also development tasks involving our own products.

The work varies a lot. Today it might be an infrastructure migration, tomorrow an access issue, and the day after that an urgent incident that needs to be investigated with the customer’s team.

Question 17. What’s the most interesting part of this work?

Probably the situations where you have to quickly understand a completely unfamiliar system.

Sometimes you join a call with several engineers, nobody really knows what happened, and they show you some custom application that uses a Windows Registry entry to print invoices. It’s written in Pascal, there’s almost no documentation, and you need to figure out what’s broken and how to restore the service.

At the same time, everyone seems to expect you to have spent six months studying that particular system already.

Of course, it’s stressful. But it’s also an interesting engineering problem. You need to gather context quickly, identify the main components, understand how they interact, and find the root cause.

This is where all the previous experience helps. If you understand operating systems, networks, applications, and infrastructure, you have a starting point even when the specific technology is unfamiliar.

Question 18. What are you specializing in within Azure right now?

Recently, I’ve been working on a lot of monitoring, resource tagging, and infrastructure organization.

I work with Azure Monitor, Log Analytics, KQL, metrics, alerts, analytics workspaces, Kubernetes monitoring, Grafana, and Prometheus.

For example, we recently configured monitoring for a startup running in Azure. I hadn’t worked deeply with Prometheus before, so I needed to understand how it worked.

I started with the basics: where the metrics come from, how they’re collected, where they’re stored, how to query them, and how everything connects to Kubernetes and Grafana.

Once you understand the chain, you can figure out the specific configuration details.

At a fundamental level, nothing particularly new is happening. You have data, transmission, storage, and processing. You have networks and protocols. Each generation of technology simply takes us to a higher level of abstraction.

Question 19. Why is keeping infrastructure organized so important to you?

Because I find it difficult to feel comfortable with a system where nobody knows what’s connected to what, who’s responsible for what, or why things work the way they do.

I like restoring order and making the system whole again. That applies to Azure and, more generally, to life.

If there’s dirty dishes in the sink, they need to be washed. If nobody in Azure knows which application sends logs to which workspace, why a particular resource exists, which tags it has, or where the costs are coming from, then something is wrong with the system.

To bring order, you need to understand the architecture. You can’t just start renaming and moving things around. You need to understand which resources are connected, what dependencies they have, what can be changed, and what can’t.

After twenty years, I think I’ve developed a reasonably good understanding of how these systems work. And now I’m interested in applying that experience to exactly these kinds of problems.

Part 7. How I Work with AI

Question 20. How has artificial intelligence changed the way you work?

For me, AI has become an amplifier for the skills I’ve already developed.

Previously, if I needed to write a complex KQL query or figure out a new technology, I might spend an entire day on it. Now I can get a working version much faster, check it, and move on.

But to do that, you need to understand what you’re trying to achieve. You need at least a basic understanding of the syntax, the system architecture, the task context, and how to formulate the right question.

I try not to hand over the entire task to AI. I work with it through a dialogue. It helps me investigate problems, generate scripts, build queries, write code, and automate repetitive work.

But if I no longer understand what it’s generating and can’t explain the solution in my own words, I’ve lost the context. That’s a signal for me to stop and figure things out.

An engineer still needs to make the architectural decisions. AI can suggest options, but the responsibility for how an application is divided into components, how systems are connected, and whether a solution meets the requirements remains with me.

Question 21. What does your everyday AI-assisted workflow look like?

Let’s say a task comes in involving an existing Azure subscription.

First, I gather the context. I use the CLI to collect information about the resources and their metadata, understand what the customer already has, and work out how everything is connected. Then I prepare that context for Copilot, group the tasks, and decide what changes need to be made.

Depending on the task, we might generate scripts, validate a configuration, or make the necessary changes manually. The changes are tracked through Git so there’s a history of what we did and why.

So a large part of my work now involves collecting the right information, asking the right questions, evaluating the proposed solution, and organizing its implementation.

I’d say I’m now combining twenty years of engineering experience with a very capable assistant. It lets me work faster, even in areas where I haven’t had much hands-on experience before.

Part 8. What Kind of Engineer Am I?

Question 22. If you didn’t use standard job titles, how would you describe your work?

That’s probably the hardest question.

I’ve worked as a programmer and technical lead, and I’ve been involved in application architecture, DevOps, cloud infrastructure, monitoring, and team management.

But none of those titles, on its own, fully describes my experience.

I’d say my main strength is understanding the whole system. I can get into the business process, understand the application, figure out how it interacts with databases and infrastructure, and then design or fix whatever is needed.

I don’t necessarily need to know every technology in advance. What matters is being able to understand it, identify the underlying principles, find the right information, and make a sound decision.

That’s why I don’t like limiting myself to a single technology stack or a narrow role. Technologies have changed many times over the last twenty years, and I’ve continued moving with them.

Question 23. What does doing a good job mean to you?

I’m a pretty responsible person. Sometimes, probably too responsible.

I find it difficult to do something just to tick a box. If I take on a task, I want to understand it, do it properly, and make sure the result actually works.

That doesn’t mean making everything perfect according to some abstract idea of perfectionism. But I want the solution to be understandable and maintainable. I don’t want the system to turn into a collection of random settings and workarounds.

It’s important to me to understand what I’ve done, why I’ve done it, and what will happen if something goes wrong.

Sometimes I’d like to take things a little less seriously myself. But that doesn’t always work.

Question 24. What are you looking for in your next job?

I want to keep moving toward Azure and architecture, apply my software development and systems design experience, work on complex problems, and deepen my knowledge of cloud technologies.

I’m interested in work where simply following instructions isn’t enough. You need to understand the context, identify the constraints, design a solution, and get it working.

I’m also drawn to environments that value independence and responsibility. I’ve spent most of my career in small teams where people trusted each other and everyone understood what they were responsible for.

I’m not claiming to know everything. Quite the opposite — I’m constantly learning. But I know how to approach unfamiliar problems, understand complex systems, and get things done.

That’s probably what I’d like to bring to my next team.