☕ Welcome to Lattes & Stories! Today, I’m taking you back to 2010, to the worst job interview of my life and the internship that followed at a space company, working on an architecture that was about to quietly reshape the entire software industry. I was 22, my English was terrible, and I could feel something important was happening. Get cozy, grab a coffee, and let’s begin!

🔔 If you only want to receive notifications for the traditional Concepts posts, you can configure your notifications in your settings.

Illustrated banner for "The Coder Cafe – Services in Space" featuring a cartoon satellite orbiting a globe with a speech bubble saying "Can you repeat that?".

Interviews

December 2010. I was finishing my last year at a French engineering school. I’m not sure if it’s the same in all countries, but in France, most engineering degrees require a 6-month internship to graduate, and I was looking for mine.

I was searching for a good internship when, at some point, an ex-student who graduated the year before me sent a message to the school mailing list about a company called Ariba1 that was looking for interns. San Francisco-based. I read the email and thought: “Why not?”

With a friend of mine, we decided to apply and got an interview with their tech team.

Let me tell you something first. At that time, saying my English wasn’t great was an understatement. I could read it reasonably well. Speaking was another matter entirely. And this was going to be my first job interview in English.

To prepare, I had written a long document with answers to the most common interview questions, something I could read from during the call. My interview was scheduled on December 21st. The pressure was starting to build.

The day came, I joined the call, and what followed was not one of the worst interviews of my life. It was the worst interview of my life.

“Hello?”
“Hi, is this Teiva?”
“Yes”
“Hi Teiva, this is … [Two minutes of him talking without me understanding a single word]”

Do you know how long two minutes can feel when you’re supposed to be having an important interview and you realize your English is too bad to understand anything?

The longest two minutes of my life.

At some point, he stopped, and I assumed it was my turn to speak. I started reading the speech I had prepared on my screen. Except I couldn’t read it. The stress had generated enough heat to fog up my glasses completely. I took them off, but I’m nearsighted, so I had to put my face about 10 centimeters from the screen just to see the words.

Take a moment to picture that…

The interview continued, and it was an absolute disaster.

That same night, I met my friend who’d had the same interview. We had probably one of the biggest laughs of our lives when he told me he’d made the interviewer repeat even the very first “Hi, is this Marc?” sentence.

Anyway. In my head, it was time to move on. In parallel, I had applied to another company and ended up getting a yes there (the interview was in French).

Moving forward to the end of January. My internship was starting the following week. Everything was settled for my move to Toulouse. I was at the supermarket, standing in line at the checkout, when I received an email:

Screenshot of a congratulatory internship offer email from Ariba (ariba.com), dated Saturday January 22, 2011 at 04:04, addressed to Teiva, confirming his selection for an internship position and noting that the HR team will follow up for further steps.

To this day, I still don’t know what happened. I swear this isn’t false modesty, but my performance during that interview had been frightful to say the least.

I was thrilled, but I had already signed with the other company. The timing was too tight, and I didn’t feel comfortable walking away from a commitment. I ended up turning Ariba down.

SOA and Spacecraft

The other company, the one I ended up doing my internship with, was Astrium, a space company known today as the space division of Airbus Defense & Space.

The domain was really interesting. Astrium’s team was building software for spacecraft control centers, the ground systems responsible for monitoring and commanding satellites in orbit. Think sending telecommands up to the satellite, receiving telemetry back down, and making sure nothing goes wrong.

The title of the internship? Service-Oriented Architecture (SOA) for spacecraft control centers.

For those who may never have heard of SOA, let me give you a quick historical introduction.

In the old days of IT, the unit of deployment was the application. When we bought a new application, there was no strong standardization for data exchange; nothing like the REST or gRPC interfaces we take for granted today. We could rely on complex standards like CORBA, which was designed to exchange data across applications, or we could build our own communication protocol on top of TCP, for example. Either way, integrating with a new application was painful.

From that pain, an idea started to take shape: what if the granularity switched from the application to the service? What if a standard contract could act as a middle layer between two applications, reducing coupling and making the whole system easier to evolve?

Does that sound familiar? It has strong similarities with microservices as we know them today. The main differences between SOA and microservices, in my opinion:

SOA came with a design-time registry for service discovery, such as UDDI, and other governance layers that simply don’t exist in microservices today.
The granularity was different. There was no concept of micro. Containers weren’t yet popular, and applications were harder to scale, so services were mostly macro in scope.

It’s hard to fully convey, but I was already fascinated by service architecture back then. To me, it felt like a revolution, and joining a company that was at the very beginning of its IT transformation and trying to make the case for why services mattered was a dream internship.

The first part was mostly about that: exploring SOA, building transferable knowledge, and convincing people about the benefits.

CCSDS

Astrium wasn’t the only one thinking along these lines. There’s an international consortium of the major space agencies of the world, in charge of defining standards for space data systems, called the Consultative Committee for Space Data Systems (CCSDS). Founded in 1982, it brings together NASA, ESA, JAXA, CNES, and around 26 other agencies. The motivation was easy to understand: most existing spacecraft control center architectures were closed, monolithic, and built with no thought for reuse. The result was a lack of interoperability between solutions, skyrocketing deployment costs, and systems that were nearly impossible to evolve.

The CCSDS had been working on exactly this problem. They defined various blueprints, such as the Mission Operations Monitor & Control Services, a set of standard service interfaces for spacecraft control centers, including:

An action service to submit executable tasks (e.g., spacecraft telecommands)
An alert service to emit notifications of operationally significant events or anomalies
A parameter service to subscribe to parameter value reports from a remote system

It was a bottom-up approach: the CCSDS defined the contracts, and to be part of the ecosystem, your service had to respect a standard service interface:

Diagram illustrating a Service-Oriented Architecture (SOA) model showing colored 3D cubes (components) sitting on a grid-based infrastructure layer, with one cube exposing a labeled "Service" via a "Service interface" connector — used to explain CCSDS standard service interfaces for spacecraft control centers.

As a service provider, if your service matched the contract defined by the CCSDS, it could plug right in.

SOA diagram showing multiple colored 3D component cubes distributed across a grid-based infrastructure layer, illustrating how CCSDS-compliant services can plug into a shared spacecraft ground segment architecture.

And one of the main benefits was this. Back then, buying a software component for your ground segment meant being tied to it for years, and switching was painful because nothing spoke the same language. A standard interface changed that: if you respect the service interface, you can easily switch to another CCSDS-compatible service, for example, because a competitor is less expensive.

SOA diagram labeled "New component, same interface" showing a green cube replacing a grey one on a grid infrastructure, illustrating how a CCSDS-standard service interface allows seamless swapping of interchangeable software components.

That may not sound impressive today, but back then, for a company like Astrium, this was a genuine win. Better interoperability, less vendor lock-in, and for the first time, a path toward a more open ground segment.

The Service Revolution I Was Sitting Inside

A significant part of my internship was about studying SOA, exploring those standards, and communicating why a service-oriented architecture was the right direction. The department wasn’t fully sold on CCSDS. It was a new standard, and it would take years before fully functional services were built on top of it. But they were sold on SOA, so I also spent time mapping the existing application landscape and proposing how the concept of services could be integrated.

What I didn’t fully realize at the time was how much was happening around me.

Indeed, the early 2000s were marked by three events that made, in my opinion, service-based architecture popular:

Around 2002, Jeff Bezos issued a famous internal mandate: all Amazon teams would expose their data and functionality through service interfaces. No other form of interprocess communication was allowed. No direct linking, no shared-memory model, no back-doors whatsoever.
Later, companies embraced a concept called the Enterprise Service Bus, a middleware that acted as a central hub to expose cross-domain services and avoid direct coupling between applications. Was it really helpful? To some degree. But the main problem was that most SOA discussions became: “What kind of ESB should we buy?” instead of focusing on the core concept: the service. A critical turning point came with a post called SOA is dead; long live services by an analyst named Anne Thomas Manne. She pulled the conversation away from technology choices and back to what actually mattered.
On March 20, 2013, Docker was born and became the engine that pushed the movement even further. As I said, applications were hard to scale before containers. With Docker making containerization practical and accessible, it became easy to deploy small, independent units of functionality, which played a huge role in what we know today as microservices.

SOA as a brand died, but the idea remained. The core concept of the service remained, lighter, smaller, stripped of the governance overhead that had weighed it down, and became one of the most common architectures we know today.

Conclusion

With hindsight, did I regret turning Ariba down? While I sometimes think my life could have been completely different if I had accepted, I don’t regret it at all. I really enjoyed my internship at Astrium. It was a great way to explore an entire business domain and practice something I hadn’t expected: convincing people, building mental models, and making an abstract idea feel concrete and worth caring about. I would have loved to stay, but there were no open positions in the area where I had worked.

There was just one thing left. My last presentation to the company was in English. Six months after that catastrophic interview. You can imagine that over those six months, I had practiced hard and made real progress, right? Absolutely not.

It was bad. Not as terrible as the interview since this time fog didn’t impair my vision, but still. My supervisor, who had sat through all my presentations, put it simply:

Your presentation? It was way better in French.

Not all stories should have a happy ending after all.

The Coder Cafe: Learn One Concept With Your Coffee.

Resources

More From the Lattes & Stories Section

Sources

1

Ariba was acquired by SAP in 2012.

Services in Space