A few years into my tech journey, I wrote a short post about the lessons I learnt one year into my first job. From then till now, the experiences I’ve had feel almost fantastical, and I’m deeply grateful for them. Recently, I realised I am one year and a month into my current role, so I thought to reflect on the year: what has happened, and most importantly, what I’ve learnt that could be useful for me or for someone out there just starting.

I got this role a few months before finishing my master’s. It was an internship, supposed to last a maximum of six months. Two months in, while balancing my thesis and work (don’t ask how those weeks felt), my manager asked if I was open to extending to a full-time contract. I thought about it and made consultations. It was an opportunity to get working experience, learn from seniors, and grow. So I said yes. And it has been quite a year.

Along this journey, I’ve learnt a lot about work, people, the corporate environment, something-something-tics, and the differences between this and a startup. My first role was in a startup, and oh, it was very different. It remains an experience I will always cherish. Wearing different hats there taught me one thing I remain very proud of: how to build. To take a problem, design it, build it, ship it, and actually have people use it — before ChatGPT. That trait remains fundamental to me, and I try to carry it everywhere, including here.

Before I list the lessons, it is important I explain the environment. It is a research and development center, which means its main role is to conduct research and then turn that research into products. Not strictly research in the academic sense, and not strictly engineering in the product sense — somewhere in between. And that was a sweet spot for me: a builder’s identity coupled with academic training that had shaped my research thinking. Adjusting was not straightforward in the beginning, but like everything, if you sit with it long enough, honestly and diligently, it tends to click. And I think it did.

So below are the lessons I’ve learnt while it was clicking:

  1. Large companies usually hire young people for their capability and potential, not their experience. They often have large departments with many projects, and what they’re looking for is someone who can learn properly and be placed in any of them. And because projects may change due to quarterly reports, market cycles, or world trends, they prioritize adaptability and raw capability over experience. When they do hire for experience, they’re often looking for more senior people — usually to spearhead a new area they want to venture into. For everything else, reshuffling internal talent is preferred to hiring externally.

  2. It is slower than a startup. But not slow in the working sense. Slow in feedback, approvals, and knowing the status of your work. You can work fast and you can demonstrate fast. But getting feedback, approval, and next steps usually sits between conflicting calendars, different forms to fill, and many people to include in the project.

  3. Technical skills are good, but authority is better. And authority here means demonstrating initiative, responsibility, and accountability for something. This includes writing proper reports, setting up meetings, involving people in your projects, pushing them, and actually arguing for your work. This is different from a startup, where building and deploying is what answers the question. Here, your presentation is what answers the question. You may have deployed, but if the people who were supposed to see it didn’t, it was just something deployed — not something you deployed.

  4. Research is very, very iterative. Before this experience and my master’s, my mental model was: you get a good idea, think about it, plan it out, run experiments, and report results. Real-world projects and access to the researchers around me gave me a different understanding: research consists of small experiments conducted to answer small questions. You take the answers from one step and use them to ask the next question, until you reach a finding, formulation, or method that deserves to be shared with the community.

  5. Production machine learning is different from just machine learning. When you run models in production and real users use them, you get exposed to the different ways people actually use models. Different failure modes, out-of-distribution inputs, model drift, performance regressions over time, spin-up times — issues you can only experience in these settings.

  6. Whether one researches or builds, engineering skills are very important, and I still believe they differentiate you. At the end of the day, the goal of anything is to produce something. That is where engineering skills come into play. So be proud of your engineering skills and keep them sharp, no matter what else you do. In my opinion, the best and most impactful researchers and inventors are fundamentally builders.

  7. Building an international product goes beyond regional CDNs, deployment strategies, or multi-language layouts. It involves legal research, restrictions, regulations, and understanding the nature of every single market — then tailoring the product to it. Before this, I didn’t appreciate how much work it takes to get started in a new market, understand its rules, and actually map them to what you’re building. Imagine creating one thing that has to serve conflicting regulations — allowed here, banned there. And in a contested area like AI today, getting it wrong can cost far more than an outage.

I’m certain some lessons have slipped my mind, but I consider the ones above the most relevant.

If I had to give advice, it would be this: get your fundamentals right in the beginning. It is not a cliché. That is the foundation, and everything builds on top of it. With GenAI today, it is easier than ever to live with an illusion of competence. One has to be very careful not to fall victim to that.

Secondly, try to learn as much as possible at the start. Learn from people, and then just do things. Even do more than what was assigned to you. You’re trying to make the best of yourself — not just because of work, but because you deserve to see what you are capable of. Case in point: one of the most impactful projects I worked on this year came from a problem I noticed in our processes. I experimented with something over a weekend, and it turned out to solve a recurring pain point in our workflow.

So, yeah. Here goes. Good luck, and I wish you the very best.