Pivoting to Go later in your career: case study

Hey! Something new is starting 😄

Let’s talk about primary language transition later in your career. It’s a case study of my recent (March, 2025) transition from almost a ten years as PHP developer into Go with no past commercial experience in it. Even though the story is aligned towards Go, the underlying principles are language-agnostic.

How The Idea For Change Was Born #

It was the end of third quarter of 2024, when the company I worked at back then laid off half of its employees, along with me. I had 3 month period before final termination of my contract, and it got me thinking about my future. I asked myself something between the lines of:

• Where do I want to be in a few years?
• What do I want to do?
• How this aligns with where I am at right now?
• Is there anything I need to change to get there?

I was reluctant of further bet on PHP. I saw so much more opportunity to grow in Go and Rust ecosystems. I felt that I started to stagnate in PHP. Work got repetitive and it stopped being challenging. I wanted to change. This driving force that leads into uncomfortable is what over the years helped me grow as an engineer and a man. When something gets repetitive and easy to do, even the stuff that previously was hard, for me it is a sign, that it is a time for change. In this case, I wanted to get first professional experience in Go.

I saw two possible ways to approach it:

1. I could’ve find a temporary work in PHP and learn Go after hours, then job-hop
2. Or look for a Go job directly, while being unemployed

I’ve decided to try the latter, leaving former as a “backup” plan. I was able to execute it that way, thanks to the three pillars I took care of, and prepared for beforehand.

Those pillars are finances, deadline, and realationship.

Finances #

Pivot takes more time to execute and be successful at compared to changing job to the same stack you used for years. You need a financial cushion to protect yourself from falling behind in liabilities, so you don’t drown in debts. There are various “schools” that say how big that cushion has to be. The reasonable size for me was 6 months of living costs (food, taxes, rent, mortgage, commute, etc) of our family of two covered by it. Some say 3 months is enough, while others keep it at one year level and above. This is not a personal finance blog, so I won’t go that much into details of budgeting and cost tracking (googling will help you), but generally speaking, in order to know what size of cushion to choose, you first have to know how much money you spend monthly. To do so, its worthwhile to keep track of monthly earnings and costs of living in Sheets/Excel, pen+paper, a third party app, or anything else that works for you. This has far more benefits beyond deciding upon financial cushion to be willing to practice it.

Financial hygiene is important.

Deadline #

Deadline, in other hand, is needed so you don’t waste too much time on fruitless en-devour that will eventually eat up all the savings you have stacked in the financial cushion. Time urgency is also enforcing a rigor needed to stay consistent and self-disciplined. I gave myself three months to find a job in Go, counted from the first day of unemployment (Jan 1st, 2025) with a backup plan of looking for PHP job afterwards if it wouldn’t work (way easier to do so, given proven past record). Deadlines do wonders for self-discipline.

Relationship #

Last, but not least, is the relationship. I found it extremely valuable to share what I plan to do with my wife so she could support me and knew all along what’s going on. This support was crucial over the entire challenge, as it helped me to push forwards during the ups and downs, and moved me in the right direction when I was close to resigning and moving back to the “safe” spot.

Initial Assumptions #

Starting out, I made a few assumptions:

• Since I’m applying for a Go role without any prior experience, I should apply for a junior position.
• A finite number of CVs submitted for “Go developer” positions will allow me to advance to the interview stage.
• I’ll design a distributed system in Go, showcasing what I already know about software development.
• An alternative option for the project is to contribute to open source packages written in Go.

All of those assumptions quickly turned out to be wrong.

The Discord Community #

When I started the preparation, I reached for a help to a Polish discord community called Order of Devs, where I outlined what I told you about here, the message was (translated from Polish):

A few days ago (Monday, Dec 9th) was my last day at my previous company, where I worked as a PHP developer. Without diving too deep into the details—there were cuts and many people were let go, including myself.

Trying to find a silver lining in this situation, I decided to get serious about making a professional transition from PHP to Go.

Up until now (since 2015), I have worked exclusively within the PHP ecosystem, and for the last two years with PHP-based microservices. However, Go piqued my interest with its capabilities, community, and significant growth potential.

Until recently, I didn’t have the slightest clue about this language or its possibilities, which leads to a major problem—I have no prior commercial experience in Go.

In this thread, I am describing the actions I’ve taken so far and those I plan to take in the near future to find my first job in Go. I’m also posting this here to cross-reference my idea with reality and the diverse experiences of the people in the OoD (Order of Devs) community. I want to dedicate the next three months (until the end of March 2025) to this full-time, relying on a financial cushion for current expenses and liabilities.

The forum seemed like the most sensible place for this thread; if you know of a better one, let me know.

Deadline #

End of March 2025. At the turn of February and March, I will start looking for PHP offers as a backup.

Market Research #

The job offers I’ve looked at so far require anywhere from six months (countable on one hand) to several years of experience. I haven’t found a single “Junior Go Dev” offer; there are a few Mid-level roles, and the rest are Senior. Common requirements include K8S, Helm, Kafka, OpenShift, gRPC, Kuttl, Kyverno, ScyllaDB, Cassandra, frameworks (Gin, Gofiber), CI/CD tools, algorithms and data structures, and design/architectural patterns. I know some of these from the PHP world, while others are strictly specific to Go.

Building Competencies #

I’ve come up with two potential and independent paths to tackle this problem:

(1) Building and documenting a distributed system project in Go based on a simplified transport domain that my wife deals with daily.

Pros:

I have a domain expert right next to me.

It could result in something that helps others break into Go, distributed systems, and DDD in the future.

It allows me to include many topics from the requirements list in job offers.

It can be nicely integrated with observability, telemetry, containerization, and K8S.

Cons:

No feedback loop—I’m working on this alone, and despite my efforts, the final project might end up being poor without me even knowing it.

Doubtful impact—I’m not sure if such a project will be a sufficient deciding factor for getting an interview and being hired.

(2) Open Source contributions to CNCF solutions

Pros:

Opportunities—The CNCF landscape is massive, and many solutions are built on Go.

Feedback loop—By contributing to OS, I’ll get feedback on the quality of my ideas and code.

Cons:

Entry barrier—CNCF solutions are complex; after choosing a project, I’ll face overhead just getting up to speed and understanding the project enough to contribute something valuable.

Some projects have very complex contribution processes that seem to drag on, e.g., ArgoCD and their triage process.

Asynchronous work issues—Response times for contributions can be long, and I might simply run out of time.

Current Progress (as of 12/16/2024) #

I’ve equipped myself with several books on Go:

Effective Concurrency in Go: Develop, analyze, and troubleshoot high performance concurrent applications with ease

Domain-Driven Design with Golang: Use Golang to create simple, maintainable systems to solve complex business problems

Mastering Go - Fourth Edition: Leverage Go’s expertise for advanced utilities, empowering you to develop professional software

Microservices with Go: Building scalable and reliable microservices with Go

Efficient Go: Data-Driven Performance Optimization

100 Go Mistakes and How to Avoid Them

I am roughly halfway through Mastering Go; the rest are on the shelf waiting. I’m worried I might have overshot the number of books versus the time available to read them.

I am also working through all the exercises from (1) Gophercises and (2) M.I.T. Distributed Systems to polish my Go skills in practice.

I wasn’t hoping for much, frankly, I wondered whether anyone will respond. I was really surprised and happy when I saw multiple responses and voices that clashed my initial assumptions.

I went on a shopping spree prior to that post and bought six advanced Go books at once. One of the first pieces of advice I got was to stop the book overhaul. The books I chose were great but not necessarily for beginners, and trying to read them all at once was overwhelming. I was also genuinely worried that not having “X years of experience” in Go would be a deal-breaker. However, I learned that Go is often used in infrastructure and platform tools where devops and k8s knowledge is just as valuable as the Go code itself.

The biggest breakthrough though, happened during a chat I had with one of the members of the community. It was a reality check that changed how I viewed the recruitment process.

What changed:

• I initially thought I had to start from the bottom because I had no commercial Go experience. I heard “Stop looking for Junior roles. You aren’t a Junior Developer.” that made me realize that my past experience in PHP - solving architectural problems, handling business logic, and scaling systems - didn’t evaporate just because I changed the language.
• I was worried my CV would be auto-rejected because I didn’t have “3+ years of Go.” The tip I got was to stop evaluating my own knowledge as “beginner” and simply list the technology alongside my hobby projects. The goal was to let my general engineering seniority speak for itself.
• My plan was to hide in a “study cave” for three months before applying. Instead, I was pushed to start sending CVs immediately. The mantra was: “keep studying, but start the search now.” I stopped trying to become a “Go Developer” and started presenting myself as a Software Engineer who uses Go as a tool to solve problems.

Those shifts in beliefs and outlook helped me to change the most crucial parts of the job seeking - from how my CV looked like, to how I positioned myself during technical interviews.

The Surprise Amazonian Interview #

Just weeks after updating my CV, I received an invitation from Amazon. I hadn’t expected a FAANG-level response, but there it was: a link to a HackerRank Online Assessment (OA).

I had a week to prepare before the link expires. I took that challenge.

The Week Of The “Grind” #

After brief research, I realized that my deep dives into Go and read through “Mastering Go” won’t be helpful to tackle this, because Amazon cares more about computer science fundamentals and system design than the programming languange at hand.

I adjusted my strategy by shifting the entire schedule into “leetcode grind” to see whether I’ll manage to pass that OA. For that week, I lived on LeetCode, NeetCode, and Algo.Monster, where I drilled fundamental patterns like DFS (Depth-First Search), BFS (Breadth-First Search), Two Pointers, and Backtracking. This moved me away from the Go for a brief moment, as Python turned out to be more suitable language to deal with LC challenges.

The Online Assessment (OA) #

The assessment consisted of two coding problems and a work-style simulation. The first one was LC Easy, the second was LC Hard, related to DP (Dynamic Programming), which I had no time to practice in detail. My resulting solution was inefficient. I passed the basic tests, but for the larger hidden test cases, my code hit the time limits. I ended up with roughly 20% of the test cases passing on that second task.

I received rejection email two days after sending the assessment. Even though I failed, this week of grind helped me to build a confidence and further challenged my beliefs - a PHP developer with zero commercial Go experience can get through the door of a FAANG company by properly showcasing the engineering mindset.

Shortly after though, my pivot was about to conclude, and Amazonian sidetrack played an important part in it.

The Offer #

In Mid-February, I got into an interview loop where Amazon interview-prep turned out to be very helpful, both behavioral-wise (culture fit, managerial talks) and coding-wise (leetcode problem solving). I went through a series of interviews spanning from coding, culture fit, and behavioral ones. Ultimately, at the March 7th, I got an offer. I’ve let myself to shift the deadline a bit due to the Amazonian preparation and the progress I already made in that interview loop. This was the last call before moving back to PHP.

Takeaways #

Looking back at those three months, my transition from PHP to Go wasn’t just about learning new syntax. It was a shift of mindset and lift of limiting beliefs. If you are considering a similar move, here are the things that worked for me:

1. Prepare! #

Take care of finances (financial cushion), relationship (partner’s buy-in) and set proper deadline, measured subjectively by your past endurance. Keep track of your impactful technical work somewhere, the more data you have at the beginning of the process, the easier it will be to tailor your CV.

2. “<X> Language” Developer vs. Software Craftsman #

The most important mindset shift was moving from “PHP Developer” to “Software Engineer who uses Go.”

If you have years of engineering experience, don’t look for internships. Your value lies in your ability to design systems, communicate effectively, leading and delivering the projects, and so on. These skills are language-agnostic. Avoid companies with rigid HR filters that only look for “X years in Go.” Look for engineering-heavy cultures that treat languages as tools. They value your problem-solving skills more than your knowledge of Go’s standard library.

3. Master The Interview Process #

Modern recruitment, especially for Go roles, is often inspired by “Big Tech” LeetCode processes. Treat it as a temporary skill to be learned.

For behavioral questions (Tell me about a time when...) STAR, the Situation, Task, Action, Result is a framework that will help you to prepare and highlight your past experience.

https://resources.biginterview.com/behavioral-interviews/star-interview-method/

4. Persistence Over Perfection #

Out of roughly 70 applications, I only had two real interview loops. My process went over the deadline by a week, something I agreed to given the Amazonian twist. If I hadn’t pushed through the doubts along the way, I’d still sit comfortably in the couch. Go though, has been a “breath of fresh air”.

If you’re feeling stagnant, the pivot with right preparation is worth every hour of the grind.

If this post helped you in some way, or you believe it didn’t answer some of your questions, please do let me know in the comments below or through an email.

And if you are considering similar feat, good luck!

Sincerly, Piotr Rusin (@piorus)