If it's anything like my experience switching between Alphabet-owned companies, it's a lot like switching teams at Google. A couple of chats with a manager and you transfer to that team. Managers almost always take internal transfers over external hires, since they have a good idea of your performance, plenty of references, and knowledge that you'll require much less ramp up time. It's not at all like submitting your resume again as an external applicant.
Also the internal job boards are much more detailed than the external "engineers wanted" posting, and you can ping people internally to chat, so it's much less of a "jump into the unknown" than your typical job hunt.
The usual problem is that to get promoted to the next level, you have to start building your promotion package again from 0, so these random moves can take away years of life from someone's carrier. At the same time Loom was quite visible project, so I guess it was easy to get promoted there.
> Managers almost always take internal transfers over external hires, since they have a good idea of your performance, plenty of references, and knowledge that you'll require much less ramp up time
One of my biggest mistakes as a newly promoted manager at Google was to take an internal transfer without asking enough questions as to why that person was transferring. It turns out that sometimes an internal transfer is happening because their current manager is desperate to get rid of that employee, and it's much, much easier to do so via an internal transfer rather than going through a separation.
It turned out that the employee who transferred to my team, while technically competent in most ways, was extremely frustrating to work with because of the degree to which they refused to accept feedback and change their behaviors. While they acted very pleasant and always used the "right" words in communications, if you tried to give them any feedback on their code, they would litigate every single last detail of the feedback and simply would never accept something like, "All of your peers think this change makes the codebase harder to read and maintain for reasons [X] and [Y]. If you did things this other way instead, see how that's more elegant?"
Their response was habitually, "Well it adheres to the letter of the style guide, and there are no specific rules supporting your requests, so I won't change anything you're asking me to change because I don't think that's reasonable."
Repeat that for literally every single comment in every single code review, and you can see how nobody would want to work with this person.
After several months of seeing first-hand what the problematic behaviors were and their pernicious impact on team morale, I was finally able to "read between the lines" in that employee's previous peer feedback, since none of their previous peers felt comfortable being direct and forthcoming in the written perf feedback about how working with that employee made them feel. All of the feedback simply focused on the technical quality of that person's work, which appeared fine for someone in that role and level.
Eventually after enough damage was being done, my own management asked him to transfer to a more experienced manager elsewhere in the org who then helped "manage out" the employee after their behaviors yet again caused rifts in that new team.
Lesson learned. I will never again just look at the role, level, and historical performance scores of an internal transfer candidate and "trust the system," but I'll instead really dig as deep as I can and try to arrange for some trial tasks with the team before accepting a formal transfer.
For the record, just looking purely at the statistics of my team over several years, the new external hires ended up being less of a risk than the internal transfers.
I've had many great internal transfers. You need to dig into their CLs, bugs, docs, and (yes) perf and have a couple of fit interviews first. You don't get that kind of signal from external candidates. With external hires though much of that ground work is essentially shouldered by recruiting, the interviewers, and hiring committee.
I fully appreciate that it's no fun for anyone to manage that kind of a situation, but the strategy I use is to just be really frank with the employee. Their attitude is a net negative to the team and if you don't see that changing they're not going to meet expectations.
