Internal transfers are a path almost no external prep guide describes, because the dynamics are different from external hiring in ways that matter. The cost of failure is different (your manager finds out, the team you applied to remembers, the recruiter you worked with is internal and stays in your network). The bar is sometimes lower (you have a track record at the company) and sometimes higher (the panel is comparing you to a known internal benchmark, not against the median external candidate). The path is also slower. I want to write this down because the 11-month arc from "I want to be a SWE" to "I am one" included three rejected internal interviews, and the rejections were the part that taught me how the transfer path actually works.
I was a QA engineer at a public company in the developer-tooling space for three years. I transferred to a mid-level SWE role on a different team at the same company in late 2024. I want to walk through the rejections and the conversion, because the conversion was not the most interesting part.
What QA-to-SWE means at this company specifically
The term "QA engineer" covers a wide range of roles. At my company, the QA role was test-engineering-flavored: we wrote test infrastructure (test runners, fixtures, CI integrations), we did exploratory testing on new features, and we owned the test-pass-fail signal for the engineering org. There was real engineering work in the role, in TypeScript and Python, mostly in the test-infrastructure layer. There was also a lot of work that was not engineering work (manual test passes, bug filing and triage, regression test maintenance) which, in my career narrative, I had spent three years learning to do well.
The SWE bar at the same company was higher than the bar I had been hitting in QA. SWE engineers at this company shipped product features end-to-end, owned a service in production, were on-call, and were graded on technical impact in a way that QA engineers were not. The transfer was not a lateral move; it was a step up the technical-bar curve. That distinction was the thing the panels in the rejected interviews were grading, and I had not understood it for the first two rejections.
Rejection 1: my own team's SWE opening, four months in
The first transfer I attempted was to a SWE opening on a sister team I had worked closely with for two years. I had a relationship with the manager. I had built a piece of test infrastructure that the team relied on. I felt strongly that this was the easiest transfer of the three options I had considered.
The interview was a single round with the team's tech lead and one IC. The format was a coding problem (45 minutes) followed by a short discussion of how I would approach a hypothetical project on the team. The coding problem was a medium-difficulty algorithm problem. I did not solve it. I got 80% of the way to the solution and ran out of time. The discussion of the hypothetical project was fine.
The rejection came three days later. The phrasing the manager used, paraphrased: "Strong relationship signal, the team would love to work with you on a transfer. The technical bar in the round was the gap. The IC interviewer felt the round was below the SWE bar we use for external hires. We do not want to lower the bar for internal candidates."
That phrase, "we do not want to lower the bar for internal candidates," is the frame I had not had. I had assumed that the relationship and the track record at the company would carry weight. They did, in the sense that the team would have welcomed me. They did not, in the sense of the technical bar being the same bar as for an external candidate, and the bar being non-negotiable.
Rejection 2: a different team, three months later
For the second attempt I prepped harder. I spent two months doing targeted coding practice (about 90 problems, focused on the medium-hard band that I had failed at in the first interview). I felt ready. The opening was on a backend infrastructure team where I had less of a relationship but stronger technical alignment.
The interview was two rounds: a coding round and a system-design-light round (a 45-minute discussion of how I would build a small feature). I cleared the coding round at hire. The system-design-light round was where I bombed. The prompt was to walk through how I would build a job-scheduling service for a specific internal use case. I had thought about job scheduling at a high level and could talk about queues and workers, but I had no production experience with the specific tradeoffs (priority queues, fair scheduling, retry logic, deduplication) that the round was grading. The interviewer asked four questions in the second half of the round that I gave hand-wave answers to.
The rejection: "The coding round was at SWE bar. The design conversation surfaced a gap in production-systems experience. We are looking for someone who can own the scheduler from day 30, not from day 90."
This was the second framing I had not had. The internal bar at this company was not just the technical bar. It was the ramp-up speed bar. An external SWE hire is expected to ramp in three months and own a service. An internal transfer who has been in QA does not have the production-systems context the SWE role assumes. The interviewer was not wrong. I had been thinking about the transfer as a credential question. The interviewer was thinking about it as an effective-date question.
The four-month bridge between rejection 2 and the next attempt
I did three things differently in the bridge.
First, I asked my QA manager if there were any production-flavored projects I could pick up in my current role. She found one: an integration between our test-infrastructure platform and the company's deploy system. It was a real production service (it ran during every deploy and gated every release) and it was small enough that I could own it end-to-end. I spent three months on it, with a code-review relationship to a SWE on the deploy team who agreed to mentor me on the production-systems shape. By the end of the project I had owned a service in production, been paged on it (twice), and shipped a fix that included a runbook update.
Second, I started attending the SWE on-call shadowing program the company ran. It was an opt-in program where any engineer could shadow another team's on-call rotation for a week. I did three rotations on three different teams. The pattern recognition that came out of the rotations (what kinds of incidents recur, how much time is spent on triage versus root-cause, how the runbook is structured) was the kind of context the design-light round had been grading.
Third, I had a quiet conversation with the recruiter who handled internal mobility. The phrasing I used, paraphrased: "I have been rejected twice. I want to be honest about my readiness. Do you think the gap is closable in the next six months, and what would you tell me to focus on?" She was honest. The gap, in her framing, was production-systems context. The remediation was the kind of thing I was already doing. She estimated three to six more months and said she would flag me to teams she thought were good fits.
Rejection 3: a near-miss
Four months into the bridge, the recruiter brought me a third opportunity. The interview was three rounds: coding, design-light, and a behavioral with the hiring manager. I cleared coding at hire and design-light at lean-hire. The behavioral round was the gap. I had practiced behavioral stories from my QA work, but the hiring manager was specifically interested in stories that demonstrated production ownership, and my production-systems story was the one project I had picked up in the bridge. One project is a thin story bank.
The rejection: "Lean-hire across the panel. Comfortable with you in 9 months, hesitant about you on day 30."
This was a near-miss. The recruiter, when she called, said the team was specifically asking whether I could re-apply if a similar opening came up later in the year.
The fourth attempt and the conversion
The fourth attempt was on a backend platform team about three months later. I had picked up a second production project in the meantime and had two real stories. The interview was four rounds: two coding (I cleared both at hire), one design-light (I cleared at hire), and one behavioral with the hiring manager (I cleared at strong-hire because the second production-project story was the right fit for the team's work).
The offer came a week later. The transfer effective date was six weeks out, to give my QA team time to absorb the handoff.
What is different about the internal transfer path
Looking back at the 11-month arc, the things I would tell another QA-to-SWE candidate at this scale of company:
The 11 months felt long while I was inside them. From the other side, the bridge time was the thing that made the transfer possible. The transfer was not a credential change. It was an evidence change. The internal panels needed evidence that I could operate at SWE bar from day 30, and I did not have that evidence at month four. By month eleven I did. The rejections in between were the calibration that told me what evidence I needed.