Roundtable. How to become a senior

They started with definitions. One participant, calling himself the most doubtful, proposed two frames: when a developer asks himself whether he is a senior, it is about skills, experience and knowledge; when an employer asks, it is about responsibility — for a product, a domain, or technical decisions. Someone added that responsibility cannot be carried without knowledge. From there the panel agreed that a grade is not something you are born with but the way others rate you: fellow developers, your current employer, employers on the market. Assessment systems differ, so no list of things you must know exists; there is a set of areas worth developing to match the criteria of as many companies as possible. Salary as a metric was not dismissed, but qualified: today's figure says more about how firmly your current employer holds you, and it is fairer to sit five to ten interviews and look at the offers.

The second answer to the same question is that it depends on the company. A studio churning out identical projects is one thing, a complex system quite another: one participant told of a colleague who moved teams purely for harder problems, to a team building an in-house replacement for a bought-in logging tool. Hence the advice to learn what criteria your company sets for a senior and to look at its competency matrix. Alexander described his: an engineer files his own promotion request and attaches artefacts — which tasks he worked on, with whom, what came out of it; requests are collected and reviewed every month by internally recognised experts, the leaders of the profession, while expectations for each level live in an internal document. They also discussed finer grades: you cannot be a senior in a vacuum, you are a senior in something. In a large desktop application on WinForms and WPF that has been developed for twenty years, system design barely matters, whereas design patterns do.

Alexander gave the fullest account of how this is tested at the door: an engineer goes through three sections, algorithms and data structures with LeetCode-style problems, a .NET platform section, and system design, where the candidate builds a system from a set of requirements while the interviewer shakes it — what if the network blinks, the service catches fire, someone cuts through the cables? System design is not only for engineers: team leads and heads of departments take it too, and without it nobody moves above a certain grade. He ran one such interview in the online part of a C++ conference, and the recording is available. Anton's approach is different: he asks a candidate two questions — the biggest achievement and the biggest failure. What matters is not the answer but the ability to unpack what exactly the achievement was and where the person failed; someone with no achievements, no failures and a history of simple forms is not a senior for him.

Then came the signals that do not work. A rating of specialists from an independent community, asked about in the chat, strikes Anton as feasible, but it is work someone must pay for; certifications exist from several vendors, only most companies he has met barely look at them. Codebase knowledge is really knowledge of the domain and the business quirks, picked up in about three months on average, so what is worth judging is breadth of understanding and impact: making a service technically better rather than shuffling JSON around. A long stint at one company was not called a red flag either — loyalty counts as a plus. Alexander himself measures impact by the amount of headache: when work stalls, the pain climbs the chain all the way to the CEO — and he immediately admits the flaw: someone sitting quietly in a corner gives nobody a headache either. Worst of all, in his view, are seniors who got their stripes while everything simply ran smoothly: while the flow of tasks stays laminar they hold it, but once the business changes they resist every change, and such people are usually shown the door.

The second half turned to how people actually get there. One participant told his own story: he was hired by a man he is still grateful to, Lyosha Kaufman, and found himself surrounded by strong people to learn from; he calls that the most direct and least reliable route. Andrey added that you only grow on tasks, and they have to vary in difficulty. Another participant agreed and qualified it: changing employer for another thirty per cent of salary works worse in the long run than a deliberate move made when your current place has run out of problems your size. Frequent hopping also robs an engineer of feedback — he starts something and leaves without seeing how it ended. Mentoring was called voluntary on both sides, and Alexander noted that people are better drawn into something new by explaining what they get out of it than by order: that is how he widened the circle of system design interviewers back when he was running ten interviews a week himself.

Towards the end the three laid out what they had prepared: four criteria for a senior — responsibility, the ability to do the work with your own hands, breadth of outlook, and the volume of things you have watched happen. They explained the last one by example: you watched the neighbouring team repair a cluster that had fallen apart — you did not do it yourself, but you lived through it close by. That is what conferences and podcasts are for: other people's experience without your own bruises, adjacent technologies, accounts of how not to do things. It is not practical knowledge but a wider picture of the world, and it helps against impostor syndrome. No compulsory books emerged: some dig into theory first, others go for a white paper from a large company, and another participant called a book concentrated experience — five or six years of someone's work read in a month with a pencil. Anton complained that no systematic education exists for a working middle engineer and proposed borrowing a format from western medicine: a clinical case reviewed by a panel of two or three experts, into which an incident review fits one to one.