TourRadar GmbH
Igor Rusinov, Lead Back End Engineer at TourRadar
Description
Igor Rusinov von TourRadar spricht im Interview über seinen Werdegang, was sein Aufgabenbereich als Lead Back End Engineer umfasst und gibt Tipps für Anfänger.
By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.
Video Summary
In 'Igor Rusinov, Lead Back End Engineer at TourRadar,' Speaker Igor Rusinov traces his path from discovering web development at university (PHP/JavaScript) to serving six years as Lead Back End Engineer at TourRadar, involved end-to-end from ideation and solution design to implementation. He stresses thinking several steps ahead to deliver scalable, maintainable systems and coordinating cross-team impacts, and outlines TourRadar’s growing use of AWS serverless (Lambda Functions, DynamoDB, 'Lambda Storage', Step Functions, API Gateway) for rapid, cost‑efficient projects. His advice: pick a domain you enjoy and learn by building, debugging, and reading docs; he stays current mainly through work, plus books, videos, and newsletters on AWS, PHP, and the frameworks they use.
From First Client Website to AWS Serverless: The Developer Journey of Igor Rusinov (Lead Back End Engineer, TourRadar GmbH)
Introduction: A career powered by curiosity and pragmatism
In the session "Igor Rusinov, Lead Back End Engineer at TourRadar" with speaker Igor Rusinov of TourRadar GmbH, we heard a grounded, developer‑first story: starting with first access to unlimited internet at university and growing into the responsibility of designing scalable, maintainable systems in a serverless world on AWS. From our DevJobs.at editorial vantage point, what stands out is the consistency: no shortcuts, no myths — just sustained curiosity, learning by doing, and the discipline to think several steps ahead.
“I started programming in university … that was the first time I got access to unlimited Internet.”
That remark sets the tone: real learning happens where questions arise — and where answers are tested hands‑on. Rusinov’s journey centers on three themes:
- Learn by doing, not only by reading.
- Anticipate the effects of technical decisions on teams and systems.
- Pick technologies that balance speed, scalability, and cost — in his case, serverless on AWS.
Origins: The spark of the open internet
When Igor Rusinov first had unrestricted internet at university, he didn’t just ask what the web is — he wanted to know how it works and how to build within it.
“I was curious how Internet work, how to build websites. So I started to read some articles and books about PHP and JavaScript.”
Two details matter here:
- He focused early on web‑native languages — PHP and JavaScript — because they let you build things, now.
- He paired freely available resources with immediate practice.
It’s that combination — theory plus hands‑on — that forms a durable technical foundation.
From hobby to first client: momentum through real delivery
Within a few months, learning turned into paid work:
“In a couple of months, I got my first order to build a website. So this is how it became not just a hobby, but a job.”
Nothing accelerates progress like a real user or client. Real delivery forces quality, reliability, and communication. First projects are rarely perfect — but they create the momentum that compounds learning.
Professionalization after university: quality, tests, architecture
After university, Rusinov worked full time as a web developer and leaned into the disciplines that make software sustainable:
“I learned about code quality, unit tests, application architecture, and many, many things that you need to be a back end developer.”
These aren’t afterthoughts. Architecture, tests, and code quality are the means to build systems that can grow, enable teamwork, and evolve over years.
Three anchors of professional practice from that phase
- Code quality as a team contract: not just “works,” but “is understandable, testable, and changeable.”
- Unit tests as safety net: enable change without risking the foundation.
- Architecture as orientation: decisions have consequences — for performance, maintainability, and team topology.
Six years at TourRadar: scope and ownership as Lead Back End Engineer
A few years into his journey, Rusinov joined TourRadar, where he’s now been for six years. Today he serves as Lead Back End Engineer — a role defined as much by ownership as by code.
“In this role, I’m involved in all stages of product development, from idea to solution design to implementing it in the code.”
End‑to‑end responsibility means shaping direction — technologically, procedurally, and communicatively. It’s less about shipping isolated features and more about building the conditions for sustainable delivery.
Thinking several steps ahead: scalability and maintainability as guiding stars
Rusinov describes the mental work of a lead in crisp terms:
“I should always think a few steps ahead… My solutions are scalable, easy to support and maintain in the future.”
Scalability here isn’t only handling more traffic — it’s team scalability: how easily can colleagues reason about the system? How do we minimize coupling and operational toil? Maintainability touches naming, module boundaries, testability, migration paths, and documented decisions — the stuff that unlocks fast iteration.
Working across team boundaries: anticipate impact, coordinate change
Leads rarely operate in isolation. Changes in one area have ripple effects across teams:
“Some of my team’s changes might affect other teams. So I should predict those situations and communicate it with other teams or coordinate those initiatives that span across multiple teams.”
It sounds unglamorous — and it’s the backbone of productive organizations. Anticipate impact to reduce friction. Communicate early to avoid surprises. Coordinate cross‑cutting work to speed up the whole system.
Practices we draw from this stance
- Early impact analysis for large changes: who is affected, which interfaces, what deployment windows?
- Shared concepts and migration paths: write down what changes and how others can follow.
- Cross‑team rituals: regular syncs to keep technical initiatives aligned.
Technical focus: more and more serverless
TourRadar increasingly adopts serverless applications. Rusinov finds the concept both interesting and helpful.
“It allows us to launch new projects very quickly; they are scalable and cost efficient because we only pay for the resources that we actually use.”
Those are classic arguments — and they matter especially in growing product portfolios. Serverless shifts the focus from managing servers to designing workflows and functions.
AWS as platform: the concrete building blocks
Because TourRadar hosts everything on AWS, the team leans into the serverless toolbox there:
“We use their services such as Lambda Functions, DynamoDB, Storage, Step Functions and API Gateway to build more complex workflows.”
The breadth is notable: stateless compute (Lambda), NoSQL storage (DynamoDB), orchestration (Step Functions), and interfaces (API Gateway). The common thread is clear: compose building blocks instead of maintaining infrastructure.
Why this combination fits
- Lambda Functions: event‑driven logic at scale, no server management.
- DynamoDB: managed NoSQL that aligns with serverless workloads.
- Storage: persistence detached from server instances.
- Step Functions: defined workflows that decouple complex processes and add resilience.
- API Gateway: interfaces as first‑class products — centrally managed and secured.
Together, these components enable systems that start fast, scale predictably, and keep ops costs in check.
Learn by doing: the pragmatic learning path
Rusinov’s learning philosophy is unapologetically hands‑on.
“I find it easy to learn by doing. I would recommend find some tutorial, article or video. It usually allows you to build some real application in a couple of hours.”
Finishing something creates momentum:
“Once you finish something, it really motivates you to learn more and more.”
Why tutorials that don’t work out of the box are good for you
He calls out a universal experience:
“Those articles usually do not work as expected out of the box, so you would need to fix some issues, read through documentation, find some useful resources.”
That friction is valuable. It forces understanding, debugging, and going to the source. This is where durable knowledge forms — beyond recipe‑following.
Pick your field: interest is the engine
Before all else, Rusinov urges developers to choose a domain that genuinely interests them.
“Find the field that is interesting to you. For me, it was web development; it might be games, mobile applications… there are a lot of fields where programming is applicable.”
Interest sustains effort. It keeps you engaged long enough to build deep understanding. Over years, motivation beats pure willpower.
Staying current: the job as the main source, media as accelerators
How to stay up to date? For Rusinov, work itself is the primary learning environment:
“The main source for me would be my job, as we constantly monitor how we could improve our systems, so there is a lot of space to try new things at work.”
On top of that, he leans on familiar channels:
“I read some books, watch videos about technologies that are interesting to me, and I’m also subscribed to a couple of newsletters… for example, about AWS, about PHP and frameworks that we use.”
Practical routines for continuous learning
- Treat system improvements as learning vehicles.
- Curate newsletters for signal over noise — especially around AWS, PHP, and your frameworks.
- Use books and videos for context and depth beyond release notes.
Actionable takeaways for developers and teams
From “Igor Rusinov, Lead Back End Engineer at TourRadar,” these principles stand out:
- Start small, but ship something real: a tutorial that gets you to a working app in hours is worth its weight in gold.
- Use breakage as a teacher: when things don’t work out of the box, you earn real understanding by fixing them.
- Think a few steps ahead: not just “what do we need today?” but “what does this mean for scalability and maintenance in six months?”
- Communicate impact early: if changes might affect other teams, speak up, document migration paths, and coordinate.
- Bake in quality early: code quality, unit tests, and architecture are what enable speed.
- Choose technologies that fit reality: serverless can align speed and cost — particularly with Lambda, DynamoDB, Step Functions, and API Gateway.
- Learn on the job and around it: improvement initiatives plus newsletters/books/videos keep you current.
From idea to code: the through‑line of Rusinov’s work
What ties his story together is the end‑to‑end arc “from idea to implementation”:
“I’m involved in all stages, from idea to solution design to implementing it in the code.”
It’s more than a job description — it’s a stance: think holistically, balance trade‑offs, and make decisions with the future in mind. Serverless exemplifies this: compose workflows out of managed building blocks, and focus on delivering value.
A day in the life of a lead: decisions as force multipliers
Code still matters, but as a lead, decisions are the real lever. Which services to use? How to slice systems? How to guide teams through change? Each answer shapes speed, reliability, and team happiness.
Rusinov’s emphasis on scalability, maintainability, and communication is a timely reminder: technical leadership is largely about anticipating consequences and explaining them clearly. None of it is flashy — and all of it makes teams fast and products resilient.
Grounding the promise of serverless
Serverless isn’t an end in itself; it’s a way to deliver value faster and with less operational burden. As Rusinov puts it:
“It allows us to launch new projects very quickly… they are scalable and cost efficient because we only pay for the resources that we actually use.”
For many teams, that means less capacity planning and less undifferentiated heavy lifting — and more attention on business logic. In practice, design, data modeling, and orchestration become the core competencies — precisely the areas Rusinov shines a light on.
Learning as a constant: motivation, friction, routine
Igor Rusinov’s career starts with curiosity, moves through early client work, and matures into a role that bridges product, architecture, and teamwork. The pattern is consistent:
- Motivation through a domain you care about (web, games, mobile — pick your spark).
- Learning through tangible results (small apps you can build in hours and actually run).
- Friction as a teacher (tutorials that fail at first force you to truly understand).
- Work as a lab (system improvements as opportunities to try new things).
Conclusion: A practical blueprint for sustainable engineering
“Igor Rusinov, Lead Back End Engineer at TourRadar” isn’t a superhero tale — it’s a blueprint for sustainable engineering careers. Choose a field that genuinely interests you. Build something real as early as possible. Treat quality as a first principle. Think ahead — for scalability, maintainability, and cross‑team collaboration. Use platforms like AWS so you can focus on what matters: functions and workflows that create value.
Or, in his own words:
“Once you finish something, it really motivates you to learn more and more.”
Paired with professional rigor and a pragmatic technology lens, that motivation becomes lasting impact.
