I am a Chemical Engineer who became a software engineer. A software engineer who became an entrepreneur. An entrepreneur who became a teacher. And a teacher who returned to building products.
That is the short version. The longer version is more interesting — not because of where I ended up, but because of how each chapter prepared me for the next in ways I did not anticipate.
IIT Roorkee: Learning to Build
I arrived at IIT Roorkee to study Chemical Engineering. What I actually spent most of my time doing was computing.
I want to be precise about this: it was not that I was a reluctant engineer. I was genuinely interested in the curriculum. But I was more interested in computers. I spent hours learning to program, building small systems, solving problems. I read widely and stayed up late working through things I had not been taught in class.
Looking back, this was my first experience of a truth I would return to many times: the things you choose to spend your discretionary time on usually point toward where you should go.
The other significant thing that happened at IIT Roorkee was co-founding IMG — the Information Management Group. We built and maintained online systems and resources that the whole campus depended on. This was my first experience of building something real for real users.
What I remember most is the feedback loop. When something broke, people noticed immediately. When something worked well, you could see people using it. Building for a community of users who actually depend on what you built is a very different experience from building for a course assignment.
D. E. Shaw: Learning to Think Rigorously
My first job after graduation was at D. E. Shaw, then one of the most technically sophisticated firms in the world. This was in the early 2000s, before the vocabulary of data science or machine learning had entered mainstream usage.
What I took from D. E. Shaw was not a specific set of technologies — those changed quickly. What I took was a standard of rigour.
There was a culture there of thinking very carefully before concluding anything. Of not accepting an answer simply because it seemed right or because it was fast to arrive at. Of being sceptical of your own reasoning. Of building things with the assumption that they would be scrutinised.
I still carry this. When I am building something — whether code, an argument or a product feature — I hear an internal voice asking: are you sure? Have you checked this? What are you assuming?
Amazon: Learning Scale
At Amazon, I worked on the product detail page — one of the most-visited pages in internet commerce — and on recommendation systems and image selection frameworks.
Scale changes the nature of engineering problems in interesting ways. When something runs for millions of users, the difference between a decision that is right 95% of the time and one that is right 99% of the time is enormous in absolute terms. Small gains compound. Small errors multiply.
I also learned something about customer thinking at Amazon that has stayed with me. There was a genuine insistence on starting from what the customer actually needs, rather than from what was technically interesting or convenient to build. This sounds obvious. In practice, it is surprisingly hard to maintain.
InMobi: Learning Data at Scale
At InMobi, I worked with very large datasets — recommendation systems operating on hundreds of terabytes. This deepened my understanding of the practical challenges of building machine learning systems in production.
Reading papers about machine learning is one thing. Building systems that produce useful outputs on real data, with real latency constraints, with real distribution shift as the world changes — that is something else. The gap between the theoretical ideal and the practical working system is always larger than it looks from the outside.
tBits: Learning to Build a Company
Founding tBits was my first experience of the full cycle of company building.
Technical problems have right answers — or at least, better and worse approaches that can be evaluated objectively. Business problems often have no right answer. There are decisions that must be made with incomplete information, under pressure, with real consequences for real people.
The most important thing I learned at tBits was about people. Hiring, mentoring, creating conditions where talented engineers could do their best work — this is a skill that does not come from studying computer science. It comes from paying attention to people and taking seriously your responsibility toward them.
Several of the engineers I hired at tBits have gone on to build strong careers. That matters to me more than the technical achievements of the company itself.
CloudxLab: Learning What Learning Actually Is
CloudxLab changed me more than any other chapter.
I expected to be a teacher who knew the material well and could explain it clearly. What I discovered was that knowing the material and being able to explain it clearly is not enough — and sometimes not even the most important thing.
The learners who transformed most were not the ones who sat through the best explanations. They were the ones who struggled productively and experienced the moment of understanding something for themselves.
This is what led me toward what I now call Learning by Inventing. The realisation that the teacher’s job is not primarily to deliver information — it is to design conditions in which the learner discovers it.
Teaching hundreds of thousands of people also gave me something that no amount of reading about education could have given: a deep empirical sense of how people learn, where they get stuck, what creates confidence and what destroys it.
Terno AI: Bringing It All Together
When I started thinking about Terno AI, I could trace a line from every earlier chapter.
The rigour from D. E. Shaw told me that plausible-sounding was not good enough. The scale thinking from Amazon told me to think carefully about reliability at production levels. The data systems work from InMobi told me the gap between demo and production is real. The company-building at tBits told me that the user matters more than the technology. And teaching at CloudxLab told me that things need to work in the hands of real people with real needs, not just in ideal conditions.
Terno AI is an AI data scientist for enterprises. But in a sense, it is built on everything I have learned about how people and technology interact — which is to say, on twenty years of increasingly specific and hands-on work.
What I Would Tell My Earlier Self
Looking back, a few things stand out.
The work you do in your discretionary time usually tells you what you care about. I spent my free time at IIT Roorkee programming when I could have been studying Chemical Engineering more diligently. I should have listened to that signal sooner.
Every chapter teaches you something that the next chapter needs. I could not have built CloudxLab without what I learned at Amazon about scale, or without what I learned at tBits about building a company. I could not have built Terno AI without what CloudxLab taught me about what real users need.
Teaching is a form of learning. The best way to discover the limits of your own understanding is to try to guide someone else toward it.
And perhaps most importantly: the interesting questions are usually at the intersection of things. My most productive work has always been where technology meets human need, where engineering meets teaching, where product meets idea.
This essay is part of my writing on the Founder Journey. If you are interested in the technical side of what I am building now, the Building Terno AI essays go deeper into the product and engineering thinking.