The Pragmatic Engineer
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.
01:06:05 · Luca Ferrari
[01:06:05] S1: We always have favored hiring new graduates or inexperienced people. And there are two reasons for it. One is when you hire, there's a trade off between a few things, certainly talent and experience. And so the more you want to optimize for talent, the less experienced people will be on average and vice versa. Experience, we can provide a new hire with over time, particularly high quality experience being surrounded by great colleagues working on really challenging projects at a high pace. Talent, we cannot teach. And so given that we're so long term oriented, and we want to maximize our level of competence, success with a five, ten, twenty year view, we favor hiring individuals who are more talented, even if we have to be patient for a couple of years or how long is needed for them to ramp up in terms of experience. That means we need to invest heavily in training, coaching, but we eagerly do given the great benefits involved for not just by news firms, also the people we hire. The second reason is our approach, our culture are so unusual, and we only learn this over time as we interface more and more with the external world, that it's proven challenging for highly experienced individuals to adjust to them sufficiently quickly. So we do hire experienced people, but we now have a preference for inexperienced ones.
01:07:46 · Gergely Orosz, Luca Ferrari
[01:07:46] S0: Awesome. And when people join Bending Spoons, what does career goal look like? Do you have a concept of levels or titles or... Because again, you did mention that you do optimize, you have this principle of simplicity. I'm curious how career fits in here from a software engineer's perspective. [01:08:06] S1: Yeah, it's very simple relative to our understanding of what's standard out there. We don't have any titles. So if you're hired as a software engineer, you are always will be as long as that's what you do, called software engineer internally. And you can choose your own title for whatever external reasons you like, your CV, LinkedIn. We only ask that you don't do something that would embarrass us, like calling yourself the CTO if you're a new hire, something like that. But if you want to use senior staff, triple senior, of that is fine by us internally or just a software engineer. All managers are simply called leads. Super simple. We have a few levels, they're very few. The difference is pretty substantial. And so we don't try to resolve finer deltas in your contribution. And if you need very frequent, very specific adjustments, we're not a company for you. If you're happy to look at working at Bending Spoons with a multi year, very long term view and you're looking for big jumps when you've made big improvements, then that's great because we don't have to discuss every six months whether you have made a 5% improvement in your ability to contribute.