Sourin Kumar Sen

1. Backend architecture and system design for enterprise applications. I help engineers and technical teams make clearer decisions around microservice boundaries, APIs, integrations, deployment architecture, scalability, reliability and practical engineering trade-offs. 2. A colleague once came to me with what initially looked like a small change to make in a class containing a single method of more than 2,000 lines, with no unit or functional tests. He was unsure how to approach the change safely without breaking existing behaviour. Instead of helping him make the change directly, I helped him step back and break the problem into smaller, safer stages. I suggested that we first create functional and unit tests to establish a safety net. Once we had that, I suggested breaking the large method into smaller methods by extracting logical blocks and then gradually improving the design using appropriate abstraction, inheritance, polymorphism and design patterns. What initially appeared to be a small change turned into several weeks of refactoring and QA testing, but we eventually got the code into a much healthier state. Shortly afterwards, another feature required major changes to that same class. Because we had already restructured it, that work became much more manageable. What I think helped my colleague most wasn't a particular coding solution. It was helping him see that what initially looked like an overwhelming problem could be broken down into a sequence of manageable decisions. 3. I'm not the right mentor for someone looking for a beginner programming tutor, frontend development guidance, or deep specialization in areas such as data science/ML. My strength is helping people who already have some software-engineering experience and need another experienced perspective on backend architecture, system design, cloud/deployment decisions, or moving toward senior/architect-level roles. 4. About three years ago, I made the decision to move back to my hometown while continuing in a role that required me to be in the office once a week. I believed I could manage the arrangement by travelling overnight each week. What I underestimated was the cumulative cost of that decision. The travel eventually became physically and mentally exhausting, I started skipping some office weeks, and my performance suffered. This ultimately contributed to difficulties at work and the end of my employment. With the benefit of hindsight, I would have stayed where I was rather than optimizing for the immediate convenience of being closer to home. The bigger lesson for me was that I had evaluated the decision based on whether it was possible rather than whether it was sustainable. Today, when making a major decision, I pay much more attention to the long-term cost of maintaining the decision, not just whether I can make it work initially. 5. I've always viewed success as having a good source of income, a happy family, and strong relationships with the people I work with — being someone colleagues can count on, rely on and respect. I still value those things and wouldn't say I have rejected that definition. What I question now is the assumption that all of those things will necessarily move together or remain stable simply because we're doing the right things. Careers change, companies change, relationships change and circumstances can change very quickly. So today I think of success less as reaching a permanent state where everything is secure, and more as building the skills, relationships and resilience to adapt when one part of life changes unexpectedly.