Back in early 2018, I switched from PHP to Go. At the time I had 6 years of total experience — 4.5 of them with PHP. Three years later, I wrote about switching in Ukrainian. Three years after that, I wrote another post about switching — again in Ukrainian. Now I'm building my own job search project and keep getting the same question on LinkedIn: "How do I switch to [Go / Rust / Elixir / pick your stack]?"
A couple of days ago I ran a poll about this on LinkedIn. I didn't wait for it to finish — 85% interest out of 118 votes made it obvious enough. Act when it's clear.
This post was originally written in Ukrainian and translated into English with Claude.
So here's my answer — for everyone who has asked, and for everyone who will ask.
It's Two Steps, Not One
A successful stack switch breaks down into two big steps:
- Learn the technology
- Find a job with that technology
Most people focus only on the first step and treat the second one as something that will figure itself out. It won't. Both steps need deliberate effort — and ideally, they overlap.
Step 1: Learn the Technology (Without Overthinking It)
Your first move will probably be a little lazy — and that's fine. You'll watch a few free courses to get a feel for whether you actually enjoy the language, read a popular book or two, maybe solve some exercises. That's a perfectly valid start.
Just don't fall into the trap of searching for the perfect learning path. It doesn't exist. The path is personal. Whether you learn through TDD, side projects, competitive programming, or just reading docs — it's all valid as long as you're actually building things.
The goal at this stage isn't mastery. It's enough familiarity to start a real project.
Step 2: Build a Project That Actually Helps You Get Hired
Before you start applying, you need hands-on experience with the new stack. The fastest way to get it is building your own project. But not just any project — one that's strategically aligned with the companies you want to work for.
Start with a Company List
Let's say you want to switch to Rust and you live in Brazil. (Swap in your own country and technology as you read.)
Your first task is to research and build a list of companies that hire — or have hired — Rust developers. Don't look only at companies with open positions right now. Job listings come and go. By the time you finish your project, those roles might be gone. Companies that hired Rust engineers in the past are very likely to hire again.
Build a spreadsheet with columns like:
- Company name
- Their products and domains
- Tech stack, databases, cloud providers they use
- Do they have an office in Brazil?
- If international — do they have current or former employees from Brazil?
Use LinkedIn Smarter
To find companies with Brazilian employees, use LinkedIn's People Search with a company filter and set "Universities" to well-known local technical universities. This helps you identify which international companies already have a pipeline into your local market.
Choose Your Domain Based on What You Find
Once you've analyzed your list, look for patterns. Maybe three companies use GCP, ScyllaDB, and build chat-related products. That's your signal.
Start building a demo chat app in Rust using Axum and ScyllaDB, deployed to GCP via GitHub Actions. Build the frontend yourself or with help from Claude / Gemini / ChatGPT. Make the chat functional by using a GenAI API to generate responses — it makes the demo interactive and impressive. Aim to keep everything on the free tier.
While you're building, google common problems in chat systems — scaling, message ordering, presence indicators. Understanding these issues will make you a much stronger candidate in interviews.
Connect With People in Parallel
While coding, start adding people on LinkedIn who work at your target companies — engineers, tech leads, engineering managers. Always include a short personal note: something like "I'm exploring opportunities at [Company] and would love to connect. If you have a referral program, I'd appreciate a heads up when the right role opens."
Don't push. Don't follow up aggressively. Just plant the seed.
When your project is ready, reach out to these contacts again and ask if they'd be willing to refer you — assuming there's an open position that fits.
Step 3: The Job Search Reality Check
Be Ready for a Title Downshift
If you're currently a Senior engineer in your old stack, switching to a new one often means entering the market as a Middle-level developer — or at most, a weak Senior. This is normal and expected. Your overall engineering experience still counts, but your hands-on depth in the new stack is limited.
Accepting this reality upfront saves a lot of frustration and helps you set realistic salary expectations. Think of it as a temporary investment — most people recover their seniority level within 1–2 years.
Update Your Resume Before You Start Applying
Don't wait until you have a job offer to update your resume. Do it early and make the project the centerpiece.
- Lead with the project. Put your new-stack project near the top of the resume, under a clear "Projects" section. Include a link to the live demo and the GitHub repo.
- Describe it with impact. Don't just list technologies. Explain what the project does, what problems it solves, and what you learned — especially anything related to domain challenges (e.g., real-time message delivery, connection handling).
- Reframe your existing experience. Highlight transferable skills — system design, architecture decisions, working with databases, API design — even if they were done in a different language.
- Keep your old stack on the resume. It shows depth and maturity. Just make clear that your focus going forward is the new stack.
Bonus: Share What You Learn
While building the project, keep a running note of what you discovered — tricky parts of the language, surprising behavior, useful libraries, things that weren't covered in any tutorial.
By the time you're done, you might have enough material for a post in the Rust (or Go, or Elixir) community on Reddit or here on dev.to. That kind of post builds credibility, gets you visibility in the exact community you're trying to join, and sometimes leads directly to job opportunities.
Summary
- Learn enough to start building.
- Research which companies hire in your stack and location.
- Build a project aligned with those companies' tech and domains.
- Connect with people at those companies while you build.
- Accept that a title downshift might happen — it's temporary.
- Update your resume with the project front and center.
- Share what you learned — it compounds over time.
The switch isn't magic, but it's also not as mysterious as it seems. The main thing is to stop optimizing the learning phase and start building something real.
My Own Switch, in Numbers
I built an API for a music player as my side project during the switch. It helped me qualify for Go roles — but not for the first one. There I made a mistake: I went from Senior PHP directly to Junior Go.
Six months later I joined another company as Middle Go — and that time I got hired without a technical interview. Their Senior engineer reviewed my music player project and that was enough. Six months after that I had the Senior Go title back. So in total, recovering the seniority level took about a year. But honestly, I didn't feel like a Senior Go engineer until about three years in.
The title downshift is real. The recovery is also real. And the project matters more than you think — it's what got me in the door.
Cross-Linking Your Project Properly
Once your project is live, don't leave it as an isolated repo. Connect everything:
- GitHub profile: pin the repository, and in your profile README add a link to the live project with a short description of what it does and what stack it uses.
- LinkedIn profile: add a link to your GitHub profile and to the live project — either in the Featured section or directly in your About.
- Live project header: add a GitHub repository link with a star button — so anyone using the demo can easily find and star the repo.
- Live project footer: add a GitHub repository link with a star button, and a link to your LinkedIn profile.
This creates a loop. Recruiters reviewing your resume can visit the live project, then follow through to LinkedIn — confirming for themselves that the project is genuinely yours. Engineers who discover your site can star the repo and find you on LinkedIn, or the other way around. This cross-linking tells employers: this person is who they say they are.
A few more things worth doing:
- Add the live project URL to the GitHub repo description — it shows up right under the repo name and is the first thing people see.
- Write a solid README for the repo — explain what the project does, how to run it locally, and what stack it uses. This is often the first thing a technical interviewer will read.
- Pin a post about the project on LinkedIn — a short post with a screenshot, a link, and two sentences about what you built. Pinned posts stay visible on your profile indefinitely.
- Add the project to your LinkedIn Experience or Projects section — not just in About. Some recruiters scan sections, not prose.
Research Your Own Path
Part of what I've described here I stumbled into by accident. Later I figured out why it worked, turned it into a personal instruction, and published it — to preserve it better and get some criticism.
Treat this article the same way. Don't follow it blindly. Use it as a starting point, then pay attention to what actually moves the needle for you — your market, your stack, your situation. A path you've researched and adapted yourself will always outperform one you borrowed from someone else.
A couple more tips. If you can't build a frontend but have a little budget — hire a junior designer and a junior developer part-time, someone without experience. When you review resumes yourself, you'll realize that most of the time you only care about one thing: whether the candidate can do the job. Everything else fades. It was like that for me too — and it changed how I looked at my own resume.
And if you're too honest for your own good — you'll still need to polish your resume enough to get invited to an interview. At FAANG-style behavior interviews, for example, you're expected to have conflict resolution stories ready. Prepare them in advance. If you haven't had dramatic conflicts, find the closest thing and shape it into a story.
I'm currently building ReadyToTouch — a job search tool for developers. If you have questions about switching stacks or job searching in tech, feel free to ask in the comments.
Top comments (0)