11/9/2025

Discover the rollercoaster of my new job experience—exciting beginnings, unexpected layoffs, and valuable lessons learned in just 45 days.

---

Intro

Back in May of 2025, I quit my job of 3 and a half years to pursue new challenges. I had landed a new role and was genuinely excited about it. However, just 45 days into the job, I was unexpectedly let go. This article shares my experience and reflections on that period, and most importantly, what I learned.

The (New) Beginning 🌱

The decision to leave my previous job was actually a combination of two very important factors:

Back in 2024 the company was scaling up and adopted new coding practices that did not align with what was discussed during my hiring process, which at the time was a deal breaker for me. I understand that as the company grew, changes were inevitable, but I felt that the new direction was not in line with my professional values and goals.

• When these changes were announced by the higher ups I went to a handful of interviews, but ultimately decided to stay as I had a good relationship with my team and manager. In the end, I ended up learning a lot from staying and adopting some of the new practices.

After a year of working under the new practices, I felt that my growth was stagnating. And the feeling was mutual; I was placed under a Performance Improvement Program (PIP), and on the same day I started working on personal projects and a few articles in order to resurrecting my LinkedIn profile from under the dust bin of the algorithm.

• As we proceeded with the PIP, I got to a point which I realized that no matter what I did, the outcome would not favor me. I would not go as far as to say that they were trying to push me out, but on one moment I was receiving feedback to be more communicative and in the other, I was being bombarded on Slack that I was over-sharing stuff with the team. It was a confusing time to say the least.

So not long after I started re-surfacing on LinkedIn and other platforms, I got a message from this recruiter, let’s call him H, who had found my profile and was interested in discussing a new opportunity. H was from a company that was working on the productivity space, something I quite enjoy. I had actually used the product from H’s company before. I underwent the interview process, which was fairly standard with a take-home exercise, a technical interview, and a cultural fit interview. In the end, I got the offer and decided to take it.

I remember my biggest motivations were the fact that I would be working with a product I would use myself - as opposed to the localized accounting software I was working at the time. I had grown saturated of building tables or lists and sidepanels over and over again for the past 3 and a half years. So the fact that the product had been around for a while and the fact that they mentioned wanting to improve the codebase and developer experience, had me genuinely excited over what was ahead for me.

So I gave my notice at my previous job, and started preparing for the new role.

Onboarding ✈️

In June, I headed out to Vienna to meet the team and the company and although I was received warmly by everyone, I also started to spot some early signs of what would become some serious red flags. I do not want to write anything that would get me in trouble from a legal point of view, so I will just say that there some decisions that were taken that clearly did not reflect what it was presented. There were two main things I observed that I consider to be the biggest red flags:

The codebase relied heavily on a custom built solution for, well, everything. This alone was not a red flag, I mean, this could be something really powerful that made obsolete some really powerful libraries that are used for any project - I’m talking about state management, style preprocessing, type safety and schema validation, that thing had it all - it seemed really useful. However, the feedback I got from 99% of the devs I interacted to, was that we were dealing with this legacy solution everywhere and everything was entangled in it. This made it so that they had been building on top of it. Something that everyone acknowledged was getting in the way of the developer experience at the company, but also everyone was building their own stuff on top of it.

The second red flag came in the form of Google Drive access and some pretty heavy to digest previous presentations that reflected the company’s growth had stagnated for a LONG time.

Still, I tried to be optimistic for a change and actually thought that I had arrived to enact some much needed change and ideas. The feedback I got from everyone is that the company itself was pivoting and looking to bring in some fresh ideas to the table. And I came back home with the idea that in the end, this was going to work out perfectly.

My Tenure In A Nutshell 🚀

I remember the setup process being really painful; there were no clear guidelines, and the instructions were either outdated or plainly wrong. The concept of having README.md in their repos was close to non-existent 🚨. So my first PR was precisely updating a bit the old instructions and the second was adding a README.md to the repo.

I remember that my onboarding came a bit at a bad time since my onboarding week had a lot of people away on vacation and my second week was the company retreat, so I was basically alone, except for one or two colleagues who would reply to my enquiries at least once a day. Additionally, most of my squad mates were backend focused, so they were not very familiar with how the front end setup was done.

My manager was actually a beacon of hope in the middle of everything. He was pretty knowledgeable about the product, he knew what everyone in the squad was doing and he knew the blockers each of us were facing, and most importantly, he knew the hardships the company and the product were facing and the poor developer experience repo he was onboarding me onto. Still, I felt motivated each time I spoke with my manager regarding the hardships I was facing and the improvements I saw that could be made, and I was always incentivized to open a PR or to open a discussion with the relevant people on Slack.

My first tasks were simple enough: Fix a copy issue here, remove a button there, update a few links to the cookies to the new domain. And I was tackling these simple issues with a certain degree of respect that I normally would not: I was writing tests for components that only displayed links - because they had no unit tests and no framework for developers to write them. Each PR had an extensive description, copy-paste commands to run the newly-added specs and screenshots of the changes - I had picked this habit from my Pennylane tenure, and again, I was trying to show a bit of what we could be doing, opposed to PRs with only a title and lacking any description. The feedback I was getting from my manager was positive and, I cannot stress this enough, I was motivated. And I felt like I was being a part of a positive change in the air.

My First Big Issue 🐞

During my onboarding week I was presented with an issue the application had for quite some time and that was about to breach some SLAs if not fixed. This was an extremely edge case issue that broke a core part of the application for some select users: drag and drop. There were hundreds of customer service tickets for this (not so many from the tech side), however it was an issue that no one in the company had managed to reproduce. There was company lore that said a colleague started working on this before taking a medical leave, and I did find a PR where a colleague did start to replace all drag and drop functionality. After digging and asking a series of questions around I learned that some months ago they replaced their bundling engine and after doing so they started receiving reports of users with a broken scroll. So they attempted a fix and while the scroll was indeed fixed for normal interactions, however when you interacted with an element, for example, a card, you lost all scroll capabilities when dragging it. This was already something a bit edge-casy, now add that to the fact that only certain users, in remote desktop, were reporting the issue, and again, no one in the company had manage to reproduce at that point and it was poorly documented.

TLDR 👉️ old, edge case issue that no one could reproduce. i had to investigate and dig around a lot to learn the actual issue and come up with a plan.

So I wrote a battle plan, shared it with my superiors who eventually gave me the green light to go ahead with it. Before trying anything, it took me some time, but I finally had a way to reproduce the issue with an old company computer !

My first approach was to go on the engine - that everyone was so adamant was the reason for this - and add any polyfills that may have been missing. This was a fast solution. If it worked, great. If not, we weren’t wasting much time with it. It did not work. So I remember drafting a PR with a few improvements and dependency updates and I got back to my battle plan.

Now I thought about doing what my colleague started, but I did not want to go as far as replacing this whole core functionality, so I tried creating a sandboxed context for the drag and drop features that required scroll, but that was not good because of the existing outer context which relied heavily on that old custom-built-solution-for-everything.

So I ended up doing a frankenstein of sorts and managed to use new components for the UI and their librarie’s events for the rest. I’d guess a monster with about 75% of my code and the 25% using their library with a sanitized wrapper.

TLDR 👉️Tried some quick fixes, didn’t work, so I mixed my own code with bits of the old library—it’s a Frankenstein solution, but it works!

In the end, I managed to fix the issue that was caused by their fix and the original issue too. My manager was happy, my manager’s manager was happy. And the plan was to actually replace the remaining features with this solution and implement it app-wide. We just needed to work out some quirks, here and there, and we would proceed.

I remember already having a POC (proof of concept) on Monday and my manager telling me to present a battle plan to the team, like the last time, before starting to write code, and I agreed. I was already writing a document, just needed some time to polish it and present it to the team for any questions or clarifications there may be. So that’s what I did.

At the end of the day the document was all polished up and I had this somewhat implemented in one of the features that had my new solution. I do not remember how presentable the code was, nor do I recall if I ended up posting my plan in Slack.

The Next Morning 🌄

It was about 9h30 when I woke up the next morning - I had no meetings, my work was ahead of schedule and I had received some great feedback the day before. So I look at the phone and I remember an onboarding session I had with the security department in which they demo’d a few phishing emails. I thought I had just received one of those. Still, it said “Termination Notice”, I had to open it. So I did, and I quickly confirmed this was indeed from the company’s domain. And I jumped out of the room to grab my computed and check Slack. What the hell was happening ? Everything was going good, everyone was happy with my work. My head was filled with questions at this point, but I still was not entirely certain this was happening. How could it ? This was probably a mistake.

I reached out to my manager as soon as Slack loaded. He was at an appointment so did not fully know what was going on, but I learned two very serious things from him: There was a company-wide announcement and he had also received an email similar to mine. This is the first time it settled in for me that this was real. I had been fired. “Not for performance reasons,” the email said, which made it a tougher pill to swallow. I read the email again. It had my name, it had a few ‘custom’ words that seemed specifically aimed at me, such as “our short time together”.

I started digging through Slack’s channels and quickly came across a message from the CEO, whom I never met, summoning everyone for an all-hands meeting with a 15-30 minutes notice. The meeting would start at 8:00 for my timezone. Nothing else. Around this time a portuguese colleague reached out asking if I had been affected by the ‘restructuring’. I had. But I still had no idea what was going on, so I directly replied to the CEO’s message and checked the “Send to #general” box and asked if someone could have the decency to explain what had happened, for those who may be on a different time zone, at the doctors or in vacation (it was July), to know exactly was going on.

Before I got a reply on that, my colleague explained that 30% of the company had been fired. Just like that. I asked for a few names I retained during my short time there, and most of them were gone. In the other channel, I got a reply from some HR person that also confirmed this scenario, and a few minutes after this, the CEO himself apologized for how the news was given and a bunch of other stuff that I could not care less and explained the situation. This was two hours after calling a company-wide meeting to lay off 30% of the workforce. The email was sent 15 minutes after the meeting started.

In the end I received a not-so-big compensation package, on the account of being in my experimental period, and just had to come to terms that for the first time in my life, I had been fired. And I have been avoiding discussing this publicly, maybe feeling a bit of that sweet imposter syndrome. Still life goes on.

What I Learned From All Of This ? 🤓

While I had a while to digest this and have no ill-will towards the company, I like to think that as a developer, I learn A LOT, whenever I switch jobs. In this case, the learnings were not much on the technical side of things, however, here are some takeaways from this experience:

RED FLAGS MATTER 🚨

• I will be paying alot more attention to what I consider to be red flags - poor documentation, inconsistent information, legacy systems no one wants to maintain , and most importantly, hints at stagnation in company growth. I saw and validated these with colleagues and they were indeed meaningful signals.

CULTURE FIT AND LEADERSHIP TRANSPARENCY 🪞

• Companies are always excited to welcome everyone. It’s always a big moment of joy and celebration, like if the CEO had birthed himself another team of employees. This was the first company that I joined that the CEO was not a founder and that he did not bother to introduce himself during my time in Vienna. I did not think much of it at the time, but this lack of tact also helps explain how the whole layoff was handled.

STABILITY IS NOT GUARANTEED - EVEN FOR GOOD PERFORMERS 🏓

• I am not over myself when I say that everyone was happy with my performance. I know I’m not being arrogant when I say that I was having a positive impact on the product. I know this because I was told, repeatedly by my manager, my team-mates, my manager’s manager and even on the termination email. And sadly, that does not equal stability, as I learned. It’s not personal either. I reckon that in a cost-saving scenario it’s easier to fire those in the experimental period.

ALWAYS HAVE A BACKUP PLAN 🤫

• I think this was also one of my biggest mistakes. I saw what a shit-show the code was, I saw the status of the company growth, I saw how much everyone had stopped trying to improve the codebase. If I had a backup, I probably would jump out after Vienna. If I had a backup lined up, I would probably have just say my goodbyes and start working full time in the next month. I did not.

GROWTH IS NOT LINEAR 📈

• I was told this on my second job, right after I managed to get a pay rise with the agency. My career will include setbacks, unexpected turns and periods of uncertainty. I am grateful enough to have had eight great years of growth and continuous employment. I do not expect that my next job will be better than what I had, both in terms of salary and in terms of tech stack.

Conclusions

So, here’s the short version: I quit my comfy old job, jumped into a shiny new one, and—plot twist—got laid off just 45 days later. (Turns out, “trial period” isn’t just for apps!) The red flags started waving early: the codebase was basically a spaghetti monster nobody wanted to touch, documentation was a unicorn, and the company vibe felt... well, stale. But I powered through, fixed a legendary bug, even wrote real documentation (gasp!), and got a bunch of kudos—right before getting the boot with a “not your fault” email. Classic.

What did I learn? Trust your gut when something smells fishy; company culture isn’t always as advertised; sometimes even doing a great job won’t save you from a company “restructuring”; and for the love of all that is caffeinated, always have a backup plan. Oh, and growth is messy—sometimes it looks a lot like falling on your face. But hey, at least there’s a good story (and some fresh LinkedIn content) at the end of it.