The Pragmatic Engineer
00:58:47 · Francesco Mancone
[00:58:47] S3: We have a team, we call it foundations technology. It builds all the tools, expertise and knowledge to make sure that we have the right developer experience, that we have analytics tools, monetization, user acquisition tools, and we make sure that these utilities can be used by the business units if they want. Typically, these are tools and technologies that require a lot of investment to be done. And if you don't have a wide portfolio of products, usually you find it a good investment or it's a big investment that you might not experience returns in the right time horizon. In our case, we have this luxury, let's say, that when we build a platform tool, it can be applied at scale. So we have the, let's say, the opportunity to make such investments and to see the results at large. So the foundations technology team builds the tools that allow us to, for instance, do proper AB testing to, let's say, manage infrastructure in an efficient way that allow us to, for instance, collect and define metrics for different products. We can track all the data among the different products with the same, let's say, formats, data pipelines and stuff that does prove to be extremely useful. Because when you have the let's say, when your data warehouse is built in such a way that all the products produce data with the same kind of semantic and format, Every tool that you build on top of it is out of the box ready for all the other digital products when you build it for one.
01:00:51 · Luca Ferrari, Gergely Orosz
[01:00:51] S1: It's a two way street by the way. So if a business unit has a need that's incremental to whatever shared technology is available, they can improve it and so they can pass up, let's say, toward the platform improvements that can then be propagated to benefit any other business unit in the future. We have had such situations with whether it's knowledge or an actual improvement to the software. We've had plenty of such cases, whether it's authentication being made more resilient against abuse, whether it's our payment processing systems handling more extreme loads or corner cases in certain particular types. All those sorts of things become a shared benefit across the whole company. [01:01:42] S0: Awesome. And speaking of technologies, what type of technologies, frameworks do you use inside the company or just the most popular ones at least?
01:01:42 · Gergely Orosz, Francesco Mancone
[01:01:42] S0: Awesome. And speaking of technologies, what type of technologies, frameworks do you use inside the company or just the most popular ones at least? [01:01:50] S3: Yeah. So I'd say the most popular backend language that we use is Python. We use FastAPI, for instance, to ship APIs. We also use TypeScript a lot, especially because we've been investing a lot in making engineers, let's say, full stack as much as possible. TypeScript in that regard is particularly useful because they can move from clients to backend easily. It's on Node. Js. We use Swift and Kotlin to build native iOS and Android apps typically, but we also rely on React when it makes sense. We use Electron. What else? I'd say we actually have a quite wide toolset. These are the most useful, the most widespread among the organization. But as I said, we're not prescriptive about the tech rather, let's say, technology that one can use. So we find ourselves frequently evaluating if there is a different technology that can work better to achieve a certain goal. Of course, if a certain goal can be achieved with different tools, they're equivalent in terms of output, we tend to prefer tools that have been used the most already across the organization because that allows everyone to contribute to that more effectively. It helps us avoid single point of failures in terms of knowledge. But apart from that case, we tend to prefer the right technology that helps us achieve the highest quality of output for a certain goal.
01:01:50 · Francesco Mancone, Gergely Orosz
[01:01:50] S3: Yeah. So I'd say the most popular backend language that we use is Python. We use FastAPI, for instance, to ship APIs. We also use TypeScript a lot, especially because we've been investing a lot in making engineers, let's say, full stack as much as possible. TypeScript in that regard is particularly useful because they can move from clients to backend easily. It's on Node. Js. We use Swift and Kotlin to build native iOS and Android apps typically, but we also rely on React when it makes sense. We use Electron. What else? I'd say we actually have a quite wide toolset. These are the most useful, the most widespread among the organization. But as I said, we're not prescriptive about the tech rather, let's say, technology that one can use. So we find ourselves frequently evaluating if there is a different technology that can work better to achieve a certain goal. Of course, if a certain goal can be achieved with different tools, they're equivalent in terms of output, we tend to prefer tools that have been used the most already across the organization because that allows everyone to contribute to that more effectively. It helps us avoid single point of failures in terms of knowledge. But apart from that case, we tend to prefer the right technology that helps us achieve the highest quality of output for a certain goal. [01:03:49] S0: Can you tell me an interesting technology or like maybe a one off technology that one of the teams uses because it's for their fit, but obviously it's not mainstream across the company. Do you have a fun example of that?
01:03:49 · Gergely Orosz, Francesco Mancone
[01:03:49] S0: Can you tell me an interesting technology or like maybe a one off technology that one of the teams uses because it's for their fit, but obviously it's not mainstream across the company. Do you have a fun example of that? [01:04:00] S3: Let's see. We have our tool for attribution, for marketing attribution. We built our own internally. Usually, most of the player app sites rely on mobile measurement partners, you know, such as Adjust, Kochava or AppsFlyer. At a certain time of our, let's say, when it was the right moment we decided to build our own internal tool. And as you can imagine, that must be able to handle huge loads with very high efficiency. We have seen that Rust was the right language. Nice. It's a peculiar, let's say. Rust is [01:04:47] S0: good for performance, isn't it? [01:04:49] S3: Exactly, yeah, we loved it. It was clear that it was making everything better, much more than the backend language that we used the most, which was Python. But for that aim, it was not the right one. It was clear from, let's say, an engineering perspective, just looking at the numbers. So yes, we went for Rust and the moment or internal tool for attribution, Xena, we call it, it's still on Rust and it's working. That's awesome. [01:05:18] S0: But be careful. The popularity might be spreading inside the company. [01:05:21] S3: Oh, yeah. I mean, I would be happy about it personally. We can talk about it another time.
01:05:21 · Francesco Mancone, Gergely Orosz
[01:05:21] S3: Oh, yeah. I mean, I would be happy about it personally. We can talk about it another time. [01:05:27] S0: One thing that is really unusual about Bending Spoons, I went to your career page and most career pages, you know, you're hiring and a lot of companies are hiring and most career pages, I would see senior engineer hiring, staff engineer, or or just software engineer. And I saw junior engineers, I saw internships posted. Actually, most of... A lot of them were tip... Clearly entry level engineers, which is refreshing to see. How's this always been the case? And what is your philosophy behind this? Because a lot of companies, especially in your position, would be a little bit afraid to hire less experienced engineers given all the complexity and all the, you know, revenue that you're talking about.