Who Will We Become When We Grow Up? Alexander Polomodov

Alexander opens with his biography: at the time of recording he is 37, graduated from MIPT and meant to become a scientist, but from his third year he moved into IT, which, he says, did not pay particularly well then. He started in technical support and was programming six months later — he had been moonlighting in his spare time, and the team told him to stop doing it for others and join them.

Then came a master's programme in systems analysis at IBS and a year as an analyst: his thesis was on business process reengineering, and he redesigned the processes while writing the specification for automating them. In the 2008-2009 crisis the company hit trouble and he interviewed a lot of people on their way out, working out who would inherit their duties; after that he decided a developer's life was simpler — you just write code.

The engineering track followed: senior, team lead, a small startup, then joining Tinkoff as an engineering manager for online acquisition, with three teams of roughly three people. More than six years on, his department holds some 650-700 people.

What hooks him in architecture? Alexander connects it with his appetite for hard problems. In IT he is drawn to architectural changes and their relationship with organisational structure, invoking Conway's law and the need to change a system while keeping it running.

Asked what puts him off the work, Alexander answers: nothing. Problems you have mastered can be simplified and delegated. He recalls the complexity domains: moving from chaos to complex, then complicated and obvious. Work that no longer challenges you may help someone else grow; that is what delegation is for.

Architects, in his view, start not with a diploma but with a mindset: physics at his lyceum taught him what models are for — pick out what matters, abstract away the rest.

Andrey Dmitriev proposed breaking the conversation into blocks, starting with formalising the task. Alexander explains it through the system design interview framework: the first phase is to understand what the system is, what it is for, who will use it and which integrations it needs.

In real work everything starts long before that: the business has a wish, you find the stakeholders, reconcile their expectations, write them down and show them around, and only then bring in the technical part. He recalls his year as an analyst: he was more of an introvert, conversations were hard, and he had to go to one person, then another, then a third, circling back for what he had forgotten to ask.

Next come functional and non-functional requirements, and the old joke that non-functional ones sell badly: the business replies that it ordered features. So they are renamed quality attributes or architectural characteristics — early decisions are expensive to change afterwards. Andrey Burakov picks up an architect friend's joke: an analyst differs from an architect in that the architect thinks about non-functional requirements.

In reply Alexander describes an analyst hired for their A/B testing platform, which requires statistical analysis, data processing and support for heavy traffic. The man could ask good questions, throw in improvement ideas, document design decisions and record how components interact: he split ownership with the head of development, took hard topics such as preparing segments and tracking collisions, sent them for review — and grew from lead analyst to architect and then to technical product manager of that system.

Whether analysts are needed at all depends on the configuration: fixed-price contract work has a huge pre-design and documentation stage, iterative product development does not require everything to be designed in advance, but large cross-team changes get an RFC — of the recent ones Alexander likes the document on the new authorisation flow for individual customers.

The closing discussion returns to whether analysts are needed. Alexander describes a trade-off: universal engineers are hard to find, while separate roles add handoffs. As the mobile bank grew, the broad technologist role split into systems and business analysis; other teams need only a product manager and engineers. Tasks and skills determine the configuration.

Alexander explains system boundaries with a caveat about his own bias: over the past year he ran more than a hundred system design interviews, one every other day. Their version of system design is about the back end: they stop at the endpoints being designed and the integration points with external systems, say providers of exchange data, then take the most important scenario and decompose it into components, deciding what is synchronous and what asynchronous.

And this, he answers when asked whether development experience is mandatory, is exactly where it breaks: in his personal sample of roughly ten strong analysts, he rated two above junior in design. This is an interview experience, not a profession-wide estimate. After a brilliant formalisation the conversation slides downhill where you have to name the components and justify them, handle failures and unexpected conditions, draw the conceptual diagram and the data model, and map the design to concrete technologies and peak-load requirements.

He advises growing not on abstract problems from the internet but on your own system: take the first scenario, whether it is written as a use case, a user story or a job to be done, and work out where the entry point is and which components take part; insights follow, and the employer may notice the initiative.

Then theory and practice: networks, operating systems, distributed systems, the classic book on integration patterns, Kleppmann's book, the one he calls the boar, and Vlad Khononov's Learning Domain-Driven Design — and, beyond books, a pet project. To speak the same language as the infrastructure engineer who helped them move to Kubernetes some five years ago, he took the courses and labs and became a certified administrator.

He sorts architects by the Staff Engineer book: the tech lead inside a team, the solver-firefighter, the architect of cross-team solutions, and the right hand at deputy-CTO level — a person, he admits, he will soon need himself.

The labels, he says, are not nailed down: asked how a software architect differs from a solution architect, he advises picking a work profile rather than a badge — say, the connecting role where five teams build one solution.

And asked who he will be when he grows up, he answers that on the technical branch he is near the ceiling: he wants to write a book and to teach a course in English in Barcelona in the summer.