A developer’s résumé is usually expected to show a degree in the field, internships in the right places, previous commercial experience. Maksim Lykov had none of that.
He learned programming on his own, in the evenings, while studying for a different profession — and got his first job without a single line of commercial code behind him.
From there, his path went through Yandex and Google, and now — Meta, where Lykov is responsible for systems that millions of users around the world depend on every day.
In this interview, he talks about how a career takes shape when the only argument in its favor is the result, not a line in a diploma.
Maksim, good afternoon. Programming wasn’t your first specialty originally. How did you get into it?
Good afternoon. Before that, I was studying in a different field. I learned programming on my own, in the evenings, without courses or mentors, and prepared for interviews using textbooks and open problems.
I got my first job as a developer without a single line of commercial code in my résumé. After that, everything depended only on the result of the job.
How did the company even decide to hire a developer with no experience?
I can’t say for sure what they were thinking at the interview. I just solved the problems they gave me and showed my reasoning. I lacked formal experience, but they gave me a chance with a trial period.
And did that chance define your entire path from there?
Yes. After the first job, the path went through Yandex, then I moved to Google, and now — Meta.
At Yandex, you worked on ML infrastructure. What exactly did you build?
I took part in building shared infrastructure for machine learning — Feature Store and Long Term Profiles. In essence, it’s a shared repository of features that different teams use instead of each one building its own solution separately.
We built infrastructure that centralized more than a hundred such production features used by multiple teams. The infrastructure supported advertising systems with an audience of about 77 million users a month.
At Google, you switched to a completely different area — Android Auto. How did that happen?
Inside the company, you often change direction if the task is interesting. One of the areas I worked on was improving the reliability of Android Auto connections across different vehicles and firmware versions. E.g. we had a problem with launch reliability — the app didn’t always start correctly on different cars and firmware versions.
I worked on a stress-testing system and automation tools. They checked this problem across a stream of identical launch scenarios, without a person involved at every step.
Did you manage to solve the problem?
The rate of launch errors dropped by 36%. For this project, the team received the internal Google Auto Awards.
Android Auto works directly with automakers. Who did you have to deal with?
I worked on the connectivity between Android Auto and partners — Nissan, BMW, Polestar, Volvo, MINI, and others. For automakers, phone compatibility became a mandatory item in technical requirements.
Now you’re at Meta. What do you work on there?
My area of responsibility covers two directions. My work has included backend systems for hacked account recovery, and more recently AI infrastructure and tooling for evaluating and benchmarking AI models.
Account recovery sounds like a routine task, but scale probably changes everything?
Absolutely. The flow is used tens of millions of times a month. I redesigned key parts of the account recovery flow to simplify the experience for recovering compromised accounts.
The result: successful recovery completion grew by 7%, and the share of repeat break-ins dropped by 1.1 percentage points. At this scale, even a small percentage means millions of people who regained access to their accounts faster.
You talk about systemic thinking and measurable results as your guiding principles. What does that mean in practice?
It means not relying on intuition where information can be checked with numbers. Before changing a system, you need to understand exactly what it’s doing wrong, and after the change you need a metric that shows whether things got better or not. Without that, changes turn into guesswork.
This summer, you joined the judging panel for two Business Intelligence Group awards at once — the Sammy in the sales and marketing category, and the Sustainability Award. How did that happen?
I was invited to serve as a judge based on my engineering experience and work across several technology domains.
I evaluated nominee submissions in both categories — approach, results, argumentation. Judging work requires attention to detail and the ability to compare very different projects against common criteria.
Sales & marketing and sustainability are fairly different fields. Didn’t the lack of direct experience in those specific areas get in the way?
Here, what helps more is experience evaluating technical solutions in general, regardless of industry. The logic of a good solution is similar in any field: a clear problem, a measurable effect, reproducibility of the result.
You’ve also written articles for industry publications — on balancing feature development and bug fixes, on moving from internal tooling to mobile development, on Kotlin. Why did you decide to share this in written form?
Many things you run into in practice aren’t clearly described anywhere — only through personal experience. I wanted to write down observations that might be useful to other developers: how to change specialization within the profession, what limitations a specific programming language creates, and so on.
What are your plans for the near future?
To keep working on AI infrastructure and high-load backend systems. Especially on the platforms that enable large-scale AI products. This is an area that especially needs engineers who know how to build the platforms that the models themselves later run on.
Looking back at the path from self-taught programmer to working at Meta — what would you say to someone starting out the same way now, without a degree in the field?
A degree opens doors in some places, but it doesn’t replace the ability to solve problems. If you can show a result on a real task, that works better than any line in a résumé.
After that, everything comes down to whether you’re willing to figure out things that no one will explain to you in advance.
From the First Line of Code to Systems for Tens of Millions of Users
Maksim Lykov’s career is built on results that can be measured: fewer launch errors, more successful account recoveries, infrastructure that other teams rely on.
His professional principle is simple: a solution matters only when it works at scale and can be counted.
