I have about two years of total experience, including one year as an SDET at a large technology company. I enjoy building tools and would like to move closer to product development, infrastructure, and feature ownership by transitioning into platform engineering. For people who have made a similar move, was an internal transfer easier than applying elsewhere? How did you build system design skills when your day-to-day work centered on test automation? What was the most convincing thing you did to demonstrate that you were ready, and what mistakes should I avoid?
4 Answers
Internal transfers seem to be the most common route. Start building relationships with people on the platform team, learn what their work actually involves, and ask what skills they expect from candidates. Then shape your projects around those needs. I wouldn’t try to collect every trendy tool just to fill gaps on your résumé; practical experience with the team’s stack and problems will matter much more.
Transitions can also happen gradually. In larger organizations, changing projects may provide a fresh start even without changing employers. Look for opportunities to contribute to internal tools, deployment systems, build pipelines, service reliability, or infrastructure automation. The most convincing proof is usually a real project that other engineers depend on, backed by clear ownership and measurable results.
One way to make the transition is to stop thinking of your experience as “only testing.” Automation frameworks are production software too: they involve design, reliability, APIs, CI/CD, debugging, and maintainability. Try to own projects that include service development, deployment, observability, infrastructure, or developer tooling. A role on a small team where you can write code, operate systems, and take ownership end to end can be especially valuable.
My concern is that people at my company see SDETs as testers who can’t move into development. What would be the strongest way to prove that I’m ready for a platform role?
My move happened by applying directly to infrastructure and platform roles at another company after working in several QA positions. The interviews focused mostly on the target role rather than treating the career change as a problem, so I prepared for coding, Linux, networking, cloud fundamentals, CI/CD, troubleshooting, and system design. Be ready to explain how your existing automation work demonstrates engineering judgment, not just test execution.
Were you asked specifically about the career change, or was the interview mostly standard platform-engineering material?
That makes sense. I’ll focus on understanding the team’s real needs instead of trying to learn every new technology.