В начале мая 2023 года я решил податься на вакансию менеджера в Canonical. Я не был в курсе их процесса собеседования. Забегая вперед, 7 сентября, спустя 4 месяца, пройдя последний этап и пройдя в шорт лист кандидатов, я снял свою кандидатуру.

Мало того, что мне нужно было бы уйти на существенное понижение зарплаты, так и сама должность выглядела как понижение: одна команда из 5 человек вместо 3 команд и 10 человек, с которыми я работаю сейчас.

Я никому не рекомендую собеседование в Canonical. Оно ужасно и не тестирует совершенно ничего. Одним из этапов я верстал страничку на HTML/CSS из картинки. Оно затянуто. Мне нужно было потратить 1 час раз в 1-2 недели. Наверное поэтому я и не слился. Просто интересно было дойти до конца. Однако первое задание — описать свою жизнь — я нашел довольно полезным для себя самого.

Если вы вдруг захотите себя попробовать в роли испытуемого проходя тесты на идиота, а таких было целых 2 этапа, то вот такого стиля текст их устроил.

Дальше 5 страниц текста о моем образовании, опыте работы и мотивации.

Education

Before I delve into my performance in high school mathematics, physical sciences, and computing, I need to give you a brief overview of the grading system at Russian universities. Upon graduation, you can receive one of three grades for a discipline: A, B, and C, with A being the highest. I performed well at the University, graduating with what is known as a "red diploma," which signifies graduating with honors, despite not being a straight-A student. Specifically, I earned an A in Math, a B in Physics, and mostly A's in all disciplines related to computing.

Except programming, I received a B. There was one teacher from whom passing the exam on the first try was quite challenging. To earn an A, you had to solve a programming competition puzzle — this was before platforms like Leetcode were established. To attain that coveted A grade, one had to either excel in a competitive environment or willing to disprove the instructor's precondition that we students were dumb. I chose to opt out of these maneuvers, as he never provided even a single example of the type of task we could anticipate on the exam for an A grade.

The reason I didn't let him draw me into this competitive cycle is because I don't view myself in a competitive light, nor do I make education or work a competition. My focus is solely on my own development and progress. Consequently, I tend not to participate in various competitions or contests. When asked which discipline I enjoyed the most, my answer would be Web development. Although, at the University, the course on web programming wasn't the strongest. At that time, my knowledge of PHP/MySQL exceeded that of the instructor, leading me to assist her in explaining the subject to my classmates. She expressed her gratitude, as this was not her area of expertise, and she had been asked by the dean to teach the class due to the unavailability of another instructor.

Regarding leadership, I was involved in the student union and assisted them with their website. This experience provided me insight into their operations. However, I found it to be less about fostering positive change through leadership and more about navigating internal politics. Unfortunately, it seemed that those who joined the union office tended to halt their learning journey, a sacrifice I was unwilling to make. However, when a friend decided to run for office, I willingly lent a hand in organizing his campaign.

I believe my classmates would recall me as someone who never seemed to be flustered. While I won't claim that everything was always easy, I maintained a positive spirit and attitude, never taking failures to heart. I was punctual and consistent, never skipping classes and typically completing assignments on time. I was a dedicated student who enjoyed spending my free time playing video games and assisting my then-girlfriend with calculus problems. After all, mathematics was a strong suit of mine.

As previously stated, I was captivated by the concept of the web as a globally interconnected platform. Consequently, I devoted my spare time to learning web programming, server administration, and related topics. This allowed me to contribute to my local internet service provider, where I supported various services such as a photo gallery, developed and maintained a search engine for local FTP servers.

I selected the best Technical University in town, although the specialization I chose was not considered the top. In 2002, Russia was just emerging from the state collapse of the 1990s, which made the choice of University less crucial than it might seem from a foreign perspective. Many young men would select a university that offered deferment from compulsory military service. I chose computer science because I had a genuine interest in computers.

Most of my achievements during that time were somewhat independent of my University education, so I don't have many exceptional accomplishments to mention aside from my diploma. However, graduating with honors is a notable achievement in itself.

Web engineering experience

"What frameworks will succeed?" is indeed an intriguing question. I have co-authored my own PHP framework, inspired by Python's Django. It amuses me when people claim that technology X will eliminate PHP or Ruby on Rails. The comparison becomes even more amusing when you consider that the former is a language and the latter is a framework. Yet both are stronger now than they ever were. I recall Brandon Eich's quote: "Always bet on JavaScript," a language that has garnered much criticism but which I genuinely enjoy. In his talk, "The Birth & Death of JavaScript," Gary Bernhardt accurately predicted the platform's future, so precisely that it's somewhat unnerving. He even foresaw the war.

So, I continue to bet on JavaScript, while learning Rust to maximize the potential of WebAssembly. I haven't done much programming in TypeScript, and it has been a while since I wrote Python code using Django. However, JavaScript, CSS, and React have been my staples. I began writing JavaScript around 2007, during an era devoid of browser dev tools and when Internet Explorer 6 still commanded a large market share. It was a time of painful necessity. I remember witnessing the rise and fall of CoffeeScript, the emergence of Babel, and the early days of React.

In 2014, as a freelancer working with Ruby on Rails, I landed a contract where, unexpectedly, one of us back-end engineers was required to handle front-end tasks. Intrigued by the design, I accepted the challenge. When choosing a framework, I selected React, despite it being only a year post-release. Its approach was refreshingly different from the other frameworks I had considered, namely Ember and Knockout. While React isn't a framework per se, it was straightforward to assemble a robust toolkit with it. Fast-forward to 2016, I left my Ruby on Rails job (which had led me to relocate to Germany) to fully commit to JavaScript. Departing from the software engineering track, I took on the role of Tech Lead for this project: https://github.com/dcos/dcos-ui/graphs/contributors While I didn't surpass Michael to achieve the #1 spot, I must reiterate that this isn't a competition. Nonetheless, my #2 ranking is unchallenged, as the project has since been discontinued. Am I a bit competitive after all?

When it comes to selecting the right tool, I have often chosen Bootstrap for prototyping or when a rigid structure is expected with little need for flexibility. However, I opted for Tailwind for ityoutubers.com due to the anticipated need for adaptability in the future. Another thing to note is that Bootstrap is akin to Joomla CMS; using Bootstrap unmistakably brands your web interface as a Bootstrap interface, and there's no disguising it.

Software engineering experience

I launched my career at a company that managed several substantial websites for the city, including the largest forum and car-related bulletin board, a mobile device-focused forum, and a city portal. The region had around 3 million people, which generated substantial traffic. This was where I honed my skills in hardcore Unix administration, PostgreSQL, Apache, Perl, and more. After that, I wrote extensive PHP code at a web studio, before transitioning to Ruby on Rails at xing.de. Eventually, I switched to front-end development, primarily working with JavaScript.

The workplace I most cherished was Mesosphere, an open-source company. I departed from the organization when I became dissatisfied with the direction it took following two CEO changes. My largest contribution to open source, in terms of lines of code, can be found here: https://github.com/dcos/dcos-ui/graphs/contributors. Aside from that, I made a minor contribution to React during the first Hacktoberfest and rectified a few issues in various libraries sporadically.

I believe that open source is not solely about the code; it's about the people. I wholeheartedly agree with Pieter Hintjens' philosophy that building a successful open-source project requires fostering a community around it. I feel this was where DC\OS fell short, as the company did not sufficiently invest in nurturing its community.

As you may now understand, it's difficult for me to answer this question definitively. As an engineer, I dedicated a great deal of energy towards enhancing dcos-ui. Initially, it didn't work for large clusters due to its reliance on polling for the cluster state. The leading node simply couldn't respond swiftly enough within the polling interval. I rewrote the core of the UI to use the Mesos Streaming API, based on the RecordIO protocol. This adjustment proved beneficial, as the UI began functioning for large clusters! However, with increased scale came new challenges. The UI was not equipped to handle such a torrent of data. My team and I invested considerable time addressing performance issues.

As a leader, I have guided my teams through periods of existential uncertainty at every company I've worked with. Most recently, our business unit was sold to another company, causing considerable unease and anxiety among team members. I devoted countless hours to one-on-one coaching sessions to help individuals navigate through the situation, while also providing feedback to the higher-ups to bring clarity and assurance to the team. Currently, things have improved, and we are approaching the merger with a positive mindset.

As I've mentioned before, software development is about people. As an engineering manager, my role is not only about looking after the software, but also nurturing and developing the people who create it. I streamline processes, draft documents and instructions, attend meetings to relay information to the team, and share their perspectives with the larger organization. I don't take on the engineering tasks; my role is to guide, coach, develop, and motivate the team.

Regarding my general experience, I have managed systems in various languages, including TypeScript, Go, Scala, Java, and Ruby, and worked with several databases such as MySQL, Dynamo, MongoDB, Postgres, and Kafka. I have experience with a variety of deployment environments, including k8s clusters, serverless AWS, classic AWS, and on-premises servers.

One of the largest systems I've overseen was as a manager, where I currently work with a team that develops and maintains a system of approximately 50 microservices written in Scala and Java. I've noticed that microservices can impose a significant cognitive load on a small team of 5 engineers, averaging about 10 services per engineer. While we don't actively engage with each service daily, we still need to keep them operational. Challenges such as recent log4j vulnerabilities are particularly tricky to mitigate. The need to dockerize these services one by one added to the workload.

Interestingly, we also manage a substantial legacy monolith application, which proved to be the most challenging to dockerize. In my experience, the ideal solution often lies somewhere in between the extremes, and each team should strive to balance the size of a service. I lean towards medium-sized services, at least at the codebase level. For instance, we recently began deploying separate instances of the same codebase to serve different endpoints. This approach provides the benefit of independent scalability without the need to manage multiple codebases.

I recall a line from Gerald Weinberg's "Quality Software Management" Vol 2 that resonates with me: "Quality is value for people." If a program lacks a feature, it does not deliver quality to its customers. If the code is challenging to maintain and expand, it doesn't provide quality for software engineers. As software engineering managers, I believe our responsibility is to maintain a balance between these two aspects. We must ensure that our codebase remains manageable so that we can incorporate the features our customers desire. However, the crux of the matter lies in the objective - software's purpose is to be utilized by people, offering them value. If no one uses the software, its aesthetics become irrelevant.

Focusing on quality for software engineers, the pursuit of quality involves three stages: design, coding, and operation. At the design stage, it's essential to select an appropriate set of technologies for the task at hand and conduct a design review. It's best to avoid 'cool' technologies unless they provide unique features that your product requires. During the coding stage, I've found that practices such as pair programming, linting, and testing, are fundamental to driving quality. In the operations stage, robust monitoring and observability are crucial. For instance, if you're providing boxed software to customers, it's important to have a mechanism in place for gathering telemetry data, like enabling customers to collect log bundles, and so forth.

One best practice that often gets overlooked is allowing software engineers to interact with actual customers. I've noticed that when engineers are acquainted with the real individuals using the software, they tend to exercise greater care in what they deliver.

Context

If you google mission of Canonical, you can't really find it. So I take the statement I found on Ubuntu's website.

To bring free software to the widest audience.

The most appealing part is that software should be essentially free and open source. Software is a huge multiplier, and providing essential software free of charge to people pushes the humanity forward. But, of course, not charging money is not enough. People should be free to modify and distribute the copy to address the needs of their community. 

At the same time, I think the risky part of the statement is "widest audience" or "we believe that every computer user". When we target everyone, we, at the same time, don't target anyone particular. It is extremely hard to please everyone. So the company with such goal will be spending a lot of resources balancing tradeoffs. Which might impede the goal itself and block the widest distribution.

Speaking about the competitors, I would like to think with the metaphor in mind that I read in the book Tribal Leadership: When asked an employee of a medical company who the competitor of their company was, the employee said — cancer.

So, who could be the biggest competitor when your goal is to bring free software to the widest audience? I think the biggest competitor would be Canonical itself. Internal inefficiencies, or lack of willingness to forge alliances with other companies, that, perhaps, don't fully share the vision, but could be really helpful on the way to achieve the goal.

So the reason I want to work for Canonical the most is because I don't want to fight another company. I want to fight cancer.

I applied for the position Engineering Manager — Web. I believe my skills suit best for this position. This is something I spent my entire career working with. Although, I would like to work on Web or internet platform in general. I remember there was another opening for the k8s platform.