Article · Blog
Working abroad doesn't make you senior. Context does.
I went to work at a software factory in France thinking the geographical leap would change my technical trajectory. It did, but not in the way I expected. What actually happened was slower, more uncomfortable, and more useful than anything I could have planned for.
Working abroad doesn't make you senior. Context does.
In 2013 I went to work at a software factory in France.
By that point I already had six years of mobile experience, had led technical teams, built native apps for iOS and Android, and thought I had a pretty solid grasp of what I was doing.
The expectation was that working in an international context would change my career. And it did. But the mechanism through which that happened was not what I had imagined.
I expected to learn through exposure: new technologies, new processes, best practices. And I learned those things too. But what really changed was subtler and harder to name at the time.
The illusion of geographical exposure
There is a fairly widespread belief in the Brazilian engineering community that working abroad, especially in markets like the US or Europe, automatically puts you at a higher technical level.
I believed that too.
What I found in practice is that external context works as an amplifier, not a substitute. If you arrive without clarity about what you know and what you don't, international exposure can actually get in the way, because the noise increases right alongside the signal.
At Joyjet I was working with clients across completely different markets, with cultural, legal, and product requirements that looked nothing like anything I had seen before. Deadlines were different. Quality expectations were different. The definition of "done" was different.
And the first thing I noticed was that my technical instincts, which I considered solid, had been calibrated for a specific context that no longer existed.
It wasn't incompetence. It was wrong calibration.
The real problem behind the problem
Most engineers chasing an international career are solving the wrong problem.
They practice English, build out their GitHub portfolio, study system design for American interviews, and ignore the harder question: what kind of context brings out my best technical decisions?
It's not a question about geographical location. It's a question about work environment, tolerated ambiguity, feedback cadence, product maturity, and team dynamics.
When I went to San Francisco in 2018 to work at Photozig, the stack was different, the product was different. But the hardest challenge wasn't technical. It was understanding that the cost of a wrong architecture decision, in a real-time video product with FFmpeg, AVFoundation, and OpenGL in the same pipeline, was measured in dropped FPS and battery drain on the user's device. Not in lines of code or test coverage.
That kind of calibration doesn't come from interviews. It comes from being inside the problem long enough to feel where it hurts.
What international experience actually teaches you
There's a pattern I call internally the Transplanted Context Problem.
It's when you take a solution that worked really well in one context and apply it in a different context without adjusting the fundamental parameters. The code looks right. The architecture feels familiar. And yet the result is worse than it should be.
This happens a lot with engineers who come from large companies with heavy process, join startups, and try to apply the same level of abstraction and formalization. Or the reverse: engineers used to startup velocity who join fintechs and underestimate the cost of a security decision made a little too fast.
At XP, when I was working on the investment flow, that misalignment showed up in code reviews. What was "clean enough code" in a content app became "regulatory risk" in a financial deposit flow. It wasn't a skill issue. It was calibration to the domain.
International experience accelerates that recalibration because it forces you to confront multiple contexts in sequence, without enough time to get comfortable in any of them.
What most people get wrong without realizing it
Engineers treat "international career" as a destination. In practice, it's a continuous process of reading context.
The engineer who thrives across multiple international contexts isn't the one who knows the most. It's the one who can identify most quickly where the implicit assumptions are in the environment they just walked into.
Assumptions about what quality means. About what is urgent. About what can be refactored later and what can't. About who decides what.
That mapping doesn't show up in any technical interview. It shows up in week three, when you realize your estimates are systematically off, and the reason isn't technical.
What I would do differently
I would have arrived in France asking more questions and shipping less code in the first two weeks.
Not because code was less important. But because the first two weeks are the only window where you have implicit permission to ask obvious questions. After that, the team assumes you've already understood the context.
I wasted that period trying to prove technical competence. And I ended up discovering the real context the hard way, breaking things that didn't need to be broken.
Today, whenever I step into any new environment, the first thing I map is not the stack. It's where the decisions live that never made it into the documentation.
Every company has a set of technical decisions that were made for reasons that no longer exist, but that nobody questions because they work. Those decisions are the real map of the context.
Final thoughts
An international career isn't about working in another country.
It's about developing the ability to step into contexts you don't know, quickly map what actually matters, and make technical decisions that make sense for that specific environment.
The counterintuitive part is that this is learned better when things go wrong in a new context than when they go right in a familiar one.
I made bad decisions in France because I was solving a problem I knew well. And I learned more from those bad decisions than from any project where I knew what I was doing from the start.
The international environment doesn't teach you what you don't know. It reveals what you thought you knew.
That distinction changes what you prioritize learning. And it changes, fundamentally, how you read any new context.