← Experience

Case study

Reasons for leaving

How three short roles ended, and my part in each.

Between 2024 and 2026, alongside my current role at SuperPOD, I worked at three companies in Mongolia: an AI company, a large financial IT center and an early-stage startup. None of them lasted longer than about three months, so here is how each one ended.

At a glance

  1. An AI companyHow it endedLet go after about three monthsMy partI withdrew in meetings and rarely asked questions. Both turned out to matter.
  2. A large financial IT centerHow it endedResigned after a monthMy partI left sooner than my contract required, though management agreed to let me go.
  3. An early-stage startupHow it endedQuit after about two monthsMy partI quit and cut off contact with everyone there. That was irresponsible.

Each one ended differently, and each time part of it was on me. Each also left me with a criticism of how software teams work. In the first, meetings looked productive without moving the work forward. In the second, the existing mess in the code set the standard for new code. In the third, leaders spoke badly of developers they had let go.

These are what I saw in short stays, not verdicts on whole companies.

01

An AI company

  • Go backend
  • About three months
  • Let go

The good

At first it was great. The developers were young and friendly, and I fit right in even though the main stack was Go, which I learned on the job.

Most of the team worked on the frontend. The only other backend developer was the CTO, who also had other projects, so it was an important role. My contributions weren't small. I was responsible for image uploads in the company's AI chat assistant, and I oversaw the backend work for image streaming, a web-scraping project and detecting whether a text is in Mongolian.

The problems

Every few days the developers met to discuss ideas and solutions. To me, these meetings looked productive but weren't: mostly small talk, complaints without solutions and big ideas I didn't think were feasible.

I noticed this in the first few meetings and didn't want to play into it.

My part

So I withdrew. I contributed little in those meetings, and my bored face didn't help. My supervisor felt ignored, because I wasn't communicating much: every task was clear and I could do it, so I rarely asked questions. After about three months, the team apparently told management I wasn't team-oriented, and I was let go.

Looking back, I should have contributed in real ways instead of complaining in my head. I should have been the one who made those meetings useful. I also learned that small talk and questions matter, even when the task is clear.

The good again

Overall, it was a great company with a culture I liked. The team had big ambitions, and the work-from-home rules were lenient by local standards.

02

A large financial IT center

  • Java, Spring Boot
  • About a month
  • Resigned

Why I joined

I wanted to work on larger projects at a larger company, and to be an important part of them. The people were friendly. Every month or two, staff were split into teams to compete at anything from table tennis to Dota and Counter-Strike. I joined the table tennis team, and it got competitive, though we didn't take first place.

What I found

I was writing Java and Spring Boot and learning as I went. The projects were badly organized. Values were hardcoded everywhere, which made the code hard to follow. Comments switched between Mongolian and English, and some made no sense to me. Commit messages rarely described the change.

As the new person, I didn't have anyone to hang out with yet, and I felt bored and without direction.

One task, two weeks

One task took me a day, written following good coding practices. Then came two weeks of back-and-forth, rewriting it to match the existing code as my supervisor asked: very large, inefficient database queries, hardcoded values and so on.

I argued that my version was the right approach. My supervisor didn't budge, and pointed out that I was still learning Spring Boot. That was true, but being new to Spring Boot didn't make me wrong here: the problems weren't specific to it. They were general software engineering.

An illustration I wrote for this page, not the company's code. The day of work and the two weeks of rework are real; the steps in between are a sketch.
  • The day I wrote it
  • Days reworking it
  • Shaded lines changed in this step

Done in a day. The numbers have names, and the database returns only the 50 users on the current page.

private static final int PAGE_SIZE = 50;private static final Duration ACTIVE_WINDOW = Duration.ofDays(30); public List<UserSummary> activeUsers(int page) {    Instant since = Instant.now().minus(ACTIVE_WINDOW);    return userRepository        .findByLastLoginAfter(since, PageRequest.of(page, PAGE_SIZE))        .map(UserSummary::from)        .getContent();}

Leaving

I understand why a big codebase values consistency. Still, after two weeks of deliberately making working code worse, I knew this team's way of working and mine didn't fit. I wasn't being challenged, and every day felt emptier.

A month in, I told my supervisor, then my manager, then HR that it wasn't working for me. Management let me go a day or two later. A few days after I left, my manager called to wish me well, and I said the same.

My part

I left sooner than my contract required, and management would have preferred that I stay. I feel bad that this may have caused them problems, and I hope they found another developer quickly.

03

An early-stage startup

  • About two months
  • Quit

What happened

Right after I agreed to join, I noticed how the manager and the CTO talked about the developers they had let go, and it worried me.

Our first disagreement was over the foundation of a larger project. I argued with the CTO, and the manager joined in on the CTO's side. It turned out they had misunderstood what I was proposing, so I wrote up the architecture I had in mind as an HTML document. That's when they agreed.

A few days later we disagreed again, this time on whether to render the application on the server or the client. It got heated.

My part

The next day I quit, and I cut off contact with everyone there. That was my mistake, and it was irresponsible.

It wasn't a healthy place to work, but that doesn't change that I should have left properly.

What I do now

I've been at SuperPOD since 2025, as its only developer. These are the habits I took from the three roles above.

  • I propose new ideas and dig deep into opportunities when my boss and I discuss the work, instead of staying quiet.
  • I'm specific with my boss about everything I propose: why it's right and what its drawbacks are.
  • As the only developer, I hold the code and the architecture to the practices I argued for at the financial IT center.
  • I'm responsible for every development decision, but I make the important ones together with my boss, describing the solutions in detail.
  • I take responsibility for small shortcomings right away, stay honest and keep looking for solutions to small obstacles.
← Back to experience