Growing as an engineer

Engineering work isn’t always exciting by default. Over time, tasks can become familiar, systems predictable, and challenges less obvious. You may find yourself stuck in the routine, propagating yet another field from the database onto the UI.

In Infobip, that is not likely to happen.

It might be the scale of work: we do have over 40 data centers, process billions of messages, we run thousands of micro-services types on tens of thousands of VMs, we store petabytes of data. We deploy changes to production over 2000 times a day.

Or it might be the way work is organised: we try to keep it agile, adapting our product, organization and ways of work to new opportunities and needs of our clients.

It may be the fact that we are constantly adapting to use the best technology available. All options are on the table and experimentation is encouraged. With the use of AI tools we can quickly try many approaches to find the one that works the best for the current problem.

Or it's just that you work with 800 more highly skilled engineers, so there is probably always someone that knows more than you on any topic, that you can consult.

You get the picture. There's no time to be bored at Infobip.

It helps that our requirements come from our clients and their real world needs.

For example, a client wants to run a contest over RCS:

• They'll send a personalised introduction text, wait for a response and, upon receiving it, send an acknowledgement. They will engage 10% of their country's population. And they will limit the voting to one hour. Let's do some back of the napkin math: that's 2 outbound + 1 inbound message for every participant. Let's say there are around 7 million of them. All this needs to go down in one hour, or 3600 seconds. That's average of ~4000 outbound and ~2000 inbound messages per second, which all need to be properly paired up and processed individually. They all need to go through the billing process, all need to be routed to the most reliable telecom operators and their delivery needs to be tracked and reported back to the client. And all this needs to happen without interfering with existing traffic from other clients.

We try to ask the right questions:

• How would we design for this requirement and test this case, to find performance bottlenecks and assure SLA of 99.95% with acceptable latencies?
• Would scaling existing infrastructure to take on this extra load work?
• What kind of algorithmic optimizations can we try out?
• What kind of networking throughput would we need for this?

Then, there are challenges that emerge less directly.

Some of our clients operate in regulated industries and are required by law to deliver notifications to their end-users. If we fail to send even a few of their messages they may get in trouble with regulators. That's exactly why we are always chasing after high availability of our services on individual level, and the platform as a whole. When the conversation moves to 9s of availability you need to find an out-of-the-box solution.

Much has been written on topics of distributed systems, redundancy etc. But theory is one thing and practice brings its own set of messy problems. How do you achieve data redundancy across AWS, Azure and on-premise data centers? How do you improve HTTP API availability if clients refuse to implement retries on their end? Theory jumps in with helpful suggestions: separate command requests (like sending RCS) from query requests (like fetching delivery reports). Then we can enqueue messages and cache delivery reports. But now we need to set up and maintain those queues and caches. How boring do you find a prospect of becoming a Redis expert?

In addition to relieving you from boredom, all these technical challenges will quickly help you hone in your problem-solving skills.

Solving hard, real-world problems is not an extraordinary occurrence in Infobip, it's what we do on a daily basis.

Growing alongside more than just engineering

The Engineering Job Architecture at Infobip opens with a statement worth taking literally: "Engineering @Infobip is about solving business challenges with Product Management." That's not a value statement - it's how the engineering function is defined here.

In practice it means you work alongside a Product Manager from day one - not just on customer-facing products, but on internal platforms and infrastructure too. That's less common than it sounds. Most companies reserve that pairing for products customers pay for directly. Here it's structural across the board.

What that gives you as an engineer:

• Context before solution - you understand why something matters before deciding how to build it
• A natural check on scope - someone whose job is to ask "what's the minimum that delivers real value" keeps work grounded
• Business and customer thinking as a daily habit - not a separate skill to develop later, but part of how you approach problems from the start

The engineering culture stays strong - this isn't about turning engineers into business people. It's about more context around the work, not less craft.

For commercial products, the organizational model goes a step further. Teams are part of a broader unit where engineering sits alongside commercial, marketing and customer-facing roles - market signals and business reality flow into engineering conversations rather than staying on the other side of a wall. For other areas the model adapts to what the work actually needs - the structure follows the nature of the product, not the other way around.

A wide portfolio, a career path designed to use it

Infobip's platform is genuinely wide - communication channels, AI agents, contact centre, automation, customer data platform, mobile, enterprise integrations, and the internal platforms underpinning all of it. The career path is explicitly designed to expand your scope across this range, from your feature team through to company-wide influence at the most senior levels. The range of what you can learn here doesn't sit behind a door you have to push open yourself - it's built into the progression.