I Started as a Senior Engineer by Accident

My software engineering career had a strange beginning.

I am still not sure whether it was a good thing or a bad thing, but I started my career as a senior software engineer. I know that sounds funny. It was funny, just not immediately.

During my final year at university, someone from Singapore reached out to me about a project. His company worked on tenders, including tenders from the Singapore government.

This was long before ChatGPT, Claude, and AI agents made automated content processing feel normal. Google already had machine learning and transcription services, but someone still had to connect those services into a system that solved a real business problem.

The proposed product would process news from national media, including television, radio, podcasts, and print media. The goal was to measure how frequently a particular company or brand appeared in the news. A company might want to know how many media outlets mentioned it that day, how many times it was mentioned, and how long people spoke about it.

The person who contacted me also owned a software company in Bangladesh. I was supposed to meet his team of PHP and Python developers and discuss a possible solution.

I was still a student, so meeting professional software engineers felt like a huge opportunity. I imagined entering a room full of people who understood software in ways I could not yet imagine. I was excited, but also nervous.

The first meeting was honestly disappointing.

I had always assumed that people in the industry built software in a much better way than I did. I expected better planning, better technical decisions, and some invisible professional process that students did not know about. Instead, I found that they were often doing things in the same way I was, and sometimes worse.

That meeting removed some of the mystery around the software industry. These were not magicians. They were people trying to solve problems with the knowledge they had.

The plan nobody could easily stop

Soon afterward, I was asked to prepare an architectural plan for the product.

I did what a good salesperson would do. Honestly, I was also trying to suggest something different enough that their technical team could not easily stop me. I proposed Node.js and Google APIs, even though the existing developers had never worked with that stack.

It worked.

The team agreed with the proposal. They were happy with the plan, and I was happy that professional engineers were listening to me.

Within around two months, I completed the product. The company did not win the tender, so the system was eventually discarded. At the time, that was difficult to accept. I had invested months of work into something that would never reach a real user.

But I graduated around the same time, and the owner offered me a job at his company. He asked about my expected salary, and I gave him a number similar to what some of my friends were receiving as fresh graduates at good software companies.

I had no idea that, inside his company, this was closer to a senior engineer’s salary.

I joined without understanding what that salary had purchased.

A senior title with junior knowledge

I started working with Django on a freight-management system.

There was only one other senior engineer on the team. He was probably the most frustrated software engineer I had ever met. He regularly complained about how little he was paid, and he was not happy that someone fresh out of university had joined with a salary close to his.

Within my first week, I received a reality check. I had expected some kind of onboarding. I thought I would spend at least a week understanding the codebase, learning the development process, and receiving guidance from experienced engineers.

Instead, management called me into a meeting and explained that they had hired me as a senior software engineer. They could not give me time to train.

That was how I officially started my software engineering career as a senior engineer.

A part of me was proud. Another part of me knew I was not ready. I think many careers begin somewhere between those two feelings. You are trusted with more than you understand, and you hope you can grow quickly enough that nobody notices the gap.

I had spent years convincing myself that I could learn anything if I tried hard enough, so I put on the title and tried to behave like someone who deserved it.

From that day, I wore several hats at once. I was a software engineer, QA engineer, product manager, and sometimes the person responsible for understanding what the client actually wanted.

The team had only two engineers. There was no dedicated QA engineer and no product manager.

Communication with the client was also poor, even though meetings happened regularly. We spoke often, but the software still did not reflect how their business actually worked. The owner of our company regularly complained about the user experience.

Eventually, I was given responsibility for the sea-freight module. Taking ownership of it was difficult. I did not have the experience that my title suggested, but I had enough confidence to walk into the problem and start asking questions.

I stopped asking about features

I began visiting the client’s office.

At first, the employees seemed frustrated and unwilling to cooperate. I could understand why. They had probably attended enough meetings, repeated their requirements enough times, and still received software that made their work harder.

So I stopped beginning every conversation with software.

I spent time with them. We gossiped. I listened to their complaints. I asked how their day was going and what usually went wrong. Slowly, they began to talk more openly.

Eventually, I met the manager responsible for the process. He was an older man with years of freight experience. I did not ask him what buttons he wanted or which fields should appear on a form. I asked him to explain the business.

I wanted to know how sea freight actually worked, which documents moved between people, which decisions mattered, and which parts of the process caused the most frustration.

Over the next three weeks, I met with them repeatedly. The relationship changed. They started trusting me, and they would offer me lunch when I visited. The conversations became less formal and much more useful.

I enjoyed that. I did not feel like an engineer collecting requirements. I felt like someone being allowed into their working lives.

My goal was still practical. I wanted to design software that respected the people using it.

I worked with the limited knowledge I had. I used Bootstrap to keep the interface clean and made the fonts and controls large enough for the older managers who would use the system throughout the day.

Many traditional freight applications had small text, crowded screens, and extremely long forms. I tried to move away from that. I broke large tasks into smaller steps. I used jQuery to load selection fields without forcing users to reload the entire page. I removed small points of friction wherever I noticed them.

None of those changes were technically impressive on their own. Together, they changed how the software felt.

The sea-freight module became the part of the system the client wanted to try first.

I was proud. For the first time in my career, I had taken ownership of something difficult, earned the trust of real users, and changed a product based on how people actually worked.

For a while, I thought maybe the senior title had been correct after all.

When everything became my responsibility

My senior teammate became increasingly unhappy. He eventually left the company, and suddenly almost everything was my responsibility. The company wanted me to rebuild his parts of the system as well.

From management’s perspective, I was doing well. I delivered features, communicated with the client, improved the product, and took responsibility when things went wrong.

But internally, I was becoming uncomfortable.

I knew the way I was building the software was not the best way. The code worked. The users were happier. The company trusted me. But I did not know how to structure a large application properly.

I did not understand how to design boundaries between modules, how to control dependencies, or how to keep the codebase maintainable as it grew. I could make things work, but I did not know whether I was building them in a way that another engineer could safely continue.

That difference started bothering me.

I asked the company to hire someone more experienced so I could learn from them. I wanted someone who could review my decisions, challenge my assumptions, and show me where my approach would create problems later.

After around four months, I realized that was unlikely to happen. From the company’s perspective, there was no urgent problem. I was delivering, so hiring another senior engineer looked unnecessary.

I could have stayed. The title was good, the salary was good, and management trusted me. From the outside, leaving probably looked unnecessary.

But deep down, I knew I was learning how to survive responsibility, not how to design software properly. I had reached the uncomfortable point where doing well was no longer the same as growing.

So I decided to leave.

I was ready to accept less money if it meant working around engineers who knew more than I did. That decision led to the next stage of my career, where I finally encountered the architecture, mentorship, and engineering culture I had been looking for. I continue that journey in Learning to Design Maintainable Software.

My first job taught me that I could take ownership before I felt ready. It also taught me that responsibility and growth are not the same thing.

Sometimes the most dangerous place to stay is the place where everyone thinks you are already good enough.