Sergii Maiakov is a CTO at Newage. Sergii has over 12 years of engineering and leadership experience in some of the biggest tech companies like Amazon and Samsung. Sergii holds a Master’s Degree in Computer Science and is a certified AWS Solution Architect.

We are living in challenging times, and many engineers are facing the question of finding a job or re-qualification. I’d like to share my experience of working in different types of IT companies and explore the pros and cons of various roles and engineering approaches. I hope my story will help someone make the right career choice.

In IT by vocation

I believe people can succeed in their career only when they are passionate about their work. Therefore, I sincerely advise all people beginning their journey in IT to listen to themselves before choosing a specialty.

For many years there has been a lot of hype around Ukrainian IT: many talks about the mythically huge earnings of programmers and how low an entry threshold into the profession is. If we talk about the standard of living and local prices, working as a programmer in Ukraine looks more interesting than in the U.S in terms of profit.

Though one should not choose this path only for the money. Nobody can become an engineer in a couple of months just after finishing a course: the work in IT (and not only) is a constant self-development process. There will never be a point where an engineer “finishes the degree” and has nothing to master more. If you are ready to evolve throughout your career constantly, always get to the bottom of the problem, analyze and look for flaws and get a buzz out of it; congratulations – we’re the same blood.

If you feel that engineering is not quite your thing, IT jobs are not limited to engineers only: you can consider business analysis, project and product management, design, and many other things that might work better for creative people of non-egineering mindset. And the entry threshold, by the way, is much lower in these roles.

It is good to attend free introductory webinars that now precede most training courses. It is easy to sign up for a few, listen, and choose a role for further development. I do not recommend relying on spontaneous decisions; instead it is good to remember that success in any business is only possible with deep dive into it and 100% commitment.

For me, choosing an IT specialisation was not a matter of trend. I was genuinely interested in it from the very moment I completely took apart my 8-bit Subor console at the age of six, trying to understand how it worked. Then I studied the Basic programming language on my own long before I entered the Kyiv Polytechnic Institute. After admission, I chose Java as my primary programming language, although back in 2007, it wasn’t that popular.

I was driven by programming as it was interesting to understand the aspects of new technologies, and I believe this kind of drive played an essential role in my career development.

Work experience in Ukraine. What I understood about the difference between an international product, outsourcing company, and a startup

My first full-time engineering role was as an Android developer at Samsung Electronics. Before that, I worked as an administrator for three years, where I gained some basic knowledge of Linux and networks.

My time at Samsung Electronics gave me vast experience and professional development. Working there, I learned how to present ideas, prove a concept, create Software Development Life Cycle (SDLC) and manage project implementation.

When choosing a job in an international product company, you must be ready to cooperate as a team member, develop your presentation skills, and constantly focus on user experience rather than feature development. It always could happen that a product feature and/or the project itself becomes irrelevant, and you might need to start over the development.

After working in a well-known international product company, I continued my career development in Ukrainian IT outsourcing companies.

At first, I joined a small outsourcing project for a bank in America (it was the end of development, 300 people were engaged).

As in any bank, the project cycle and technological stack were very conservative. A professional management team led the project with all related bonuses: no fever and overtime, always satisfied clients and employees, loyal relations within the team, and transparent career development. But in 2014, when russia’s military invasion of Ukraine began, the client decided to minimise risks and hand over the project to another IT outsourcing company from India.

Then I joined a big international IT outsourcing company. In my experience, the biggest advantage of any large-scale IT outsourcing company are aligned processes and smooth interaction at every level. Newcomers go through a well-defined onboarding process; employees have a clear personal development program; the project manager and head of the unit follow your progress. Hence an engineer can concentrate on work, following the established processes.

The advantages of working for IT outsourcing companies are well-defined processes and efficient interaction with the customer. A team member always knows what is required and has a future backlog with the proper management. No deviations from the set roadmap are allowed. The work comfort depends on the client and the stage of the project.However, this approach has a downside – the opportunities for development within the project are limited. Even if you go the extra mile, chances are that no one needs it. The customer pays for a certain amount of work. You can change projects, but it will not change the global setup. Customers pay the company a fixed rate, and an engineer gets a certain percentage of that.

So I started looking for an opportunity to get into a company where I would have a chance to try everything: be an administrator, a DevOps engineer, a software architect, and a project manager. In 2016, I chose Newage – at the time, it was a product startup in its purest form: a small rented room as an office, a few people on the team, and no processes built yet. There was only some shared vision of how to make a product, the desire to develop these ideas into reality, and a very motivated team, aimed at results.

As a technical/team lead, I hired specialists, expanded the team, and made architectural decisions. I had almost complete freedom regarding technical product development, which I was missing in my previous positions.

I can say that working in a startup would hardly suit those who are used to clear and well-organised processes and who prefer a measured working pace.Any startup is always a journey into the unknown. You don’t know what will happen the next moment, but you have to be agile and come up with elegant solutions. However, startups are the perfect place for those seeking diverse development.

Experienсe working for Amazon in Canada: change of perspectives on IT approaches

Thinking about further personal development, I was eager to learn from the best and set my sights on getting into FAANG. “FAANG” is an acronym that refers to the stocks of five prominent American technology companies: Meta (META) (formerly known as Facebook), Amazon (AMZN), Apple (AAPL), Netflix (NFLX); and Alphabet (GOOG) (formerly known as Google).

In 2012, I purposefully started applying to Amazon, Google, Disney, and Microsoft to move to the US. But there were difficulties either with the feedback during the hiring process or with getting a US working visa for several years.

I dreamt of driving a pickup truck wearing a cowboy hat, living in a two-story house with a green lawn, and breathing the air of a free America – but it turned out differently.

Eventually, I was interviewed at Amazon Canada, and within 24 hours, I got two excellent job offers from different teams. It took a few months of paperwork, and I ended up in Canada.

The project I joined involved the high-load technical part of Amazon, which linked all virtual purchases to physical items in warehouses worldwide. It was an incredible experience working with a giant, distributed, highly loaded system with strict SLAs.

The first thing that struck me most about Amazon was the scale. The company’s total number of employees at the time was about 500,000. The services, the outlets, the teams, and the warehouses were spread worldwide. And it was necessary to organize the entire process (from order placement on the website to load the parcel into the car) because the slightest disruption would disorganise the whole chain and lead to delays in subsequent parcels.

While working at Amazon, I realised that in my previous roles I was focusing more on the result, while the focus should be on the processes. With logical and clear processes, teams can work self-organised and autonomously in any situation – even on the scale of tens of thousands of employees and hundreds of thousands of services.

I began actively studying and developing Site Reliability Engineering (SRE), the practices that originated at Google and Amazon. SRE practices helped in building truly reliable systems of all sizes and complexities (this covers SLAs for availability, durability, correctness, throughput, freshness, latency, quality, and many others).

When there are 10-50 services in a project, it does not look like a big challenge, but the picture becomes more interesting and complex when the scale is thousands times bigger. For example, it is not a trivial task to provide distributed consensus between cross-continental data centers, which many systems use.

I have analysed the growth of global IT giants to understand how they manage (and some do not) to maintain and develop highly loaded distributed systems of hundreds of thousands of services while ensuring good product quality and high availability levels. Without these practices in scaling a project, the complexity of support and development increases exponentially as teams and services grow.

Amazon taught me many great things, including analysing mistakes and reacting appropriately to incidents. For example, I learnt a lot while being on duty. In this process, you have to monitor the efficiency of the entire system your team is responsible for.

The scale of the system and infrastructure is enormous. Within smaller teams and without flawless approaches to monitoring and alerting, the efficient work would not be possible. If something happens anywhere globally at any time of the day, you have 15 minutes to react before the issue escalates. You have to identify the problem, think through a plan of action, and give direction to other employees (if the solution to the problem is not in your area of responsibility) who are also scattered around the world.

When you bring in someone from another team and talk about some serious problem in their domain, you must provide all relevant information in a few minutes. And that is impossible if you are not as clear and concise as possible.

After “putting out a fire”, it was important to run a detailed review of the problem to avoid repeating it in the future, and this review sometimes touched even the minor details.

At first, such duty was highly stressful, especially when several problems appeared at night and all at the same time. As I knew the price of downtime, the pulse rate jumped skyward when the pager went off, but gradually I developed clarity and serenity in analysing problems of all sizes.

Working at Amazon made me realise how much important processes and team collaboration were.

Why I returned to the IT product company in Ukraine

After a few years in Canada, I realised that such a lifestyle was not working well for my family and me. I learned a lot at my current job, and it was time to move on. I had a choice to finally fulfill my long-time goal, move to the U.S. and get a job at some promising startup, or return to Ukraine.

Why not FAANG? Indeed, the organisation, predictability, confidence in the future, and exciting challenges make FAANG still attractive. But it is necessary to understand that the growth of the last 12 years is now on the wane, and the shares (and half of the salary paid by the shares) are unlikely to increase in price 10-20 times as it was for the last ten years. Accordingly, the outlook is not as bright as it used to be, especially if you want to buy real estate in the United States or Canada in the near future.

So I decided to return to Ukraine and accepted the Newage offer as a Chief Technology Officer. At that time, the company had grown considerably: there were new clients, and its portfolio had several new products.

I must also admit that I prefer working in less bureaucratic companies. It is very convenient when almost any issue can be solved within a short time, without dozens of meetings and long email threads. Too bureaucratic processes slow down the speed of teams or generally “dampen” initiatives, which are very often the development triggers. 

We often conduct proof of concept or A/B-testing to make a decision and evaluate its effectiveness. After all, you can not always foresee everything in advance, and investing a lot of time in a detailed analysis and research is sometimes less effective than testing an idea on production.

Of course, this would be impossible without the proper level of observability, which is an integral part of SRE approaches.

I’m actively implementing SRE practices and scalable building processes in software development. We pay a lot of attention to practicing such things as capacity planning, incident analysis/root cause analysis, monitoring and alerting, and development best practices.

For example, all of our major projects with hundreds of services have a convenient SRE board that shows the state of the entire platform and each of its components, including the network. The boards display only crucial metrics so that it is possible to understand within 10 seconds if there is a problem, where exactly it is (in some cases – even its cause), and to trace the transitive dependencies of systems. This way, we greatly simplify and speed up the incident analysis and response.

As for the incidents themselves, we have a simplified practice of postmortem/correction of errors. If there is a severe incident, you need to perform a detailed analysis (5 Why’s) to get to the bottom of it, assess the losses, and come to action items that need to be executed to eliminate the incident in the future. Everything is logical and straightforward.

By business standards, Newage is a young company in the development process. But implemented approaches and practices are the keys to the established service level objective (SLO) and the highest level of our products. I am confident in my career choice and see a lot of prospects in the future.

IT product vs.  IToutsourcing: personal conclusions

In this article, I highlighted the pros and cons of working in different IT companies based on my experience.

n current realities, when choosing a company, I would also pay attention to how it behaved in the first months of russian invasion of Ukraine: were there layoffs, how were employees supported, and were there (and are there still) clients in russia?


I returned to Ukraine a few months before the war. I used to refer to myself as a world citizen and thought I could live and work anywhere. But while I lived in Canada, I realised that there were invisible threads that bound me to Ukraine.

And now, despite everything, I’m glad to be back. Having lived through all the wartime events here, I know I’m in my country and among my people.

I like the attitude of Ukrainians to work or do whatever they think is important: to fully devote themselves to the cause and work to the best of their ability.

I feel this rhythm, and we are on the same page. We have everything we need to make the future what we want it to be.

I am now closer than ever to Miroslav Veresiuk’s lines: “Do you think you offended me when you called me a Banderite? I’ll tell you at once – I wasn’t one! Now I am!”