What It Means to Be an Engineer at SayGames

Roughly half of our team are engineers who go deep into data and technology, building complex systems and solving problems that don’t have ready-made solutions. This is where we place our bet — and a big part of our success comes from it.

So when we say we’re hiring developers, it doesn’t fully describe what the job actually is. To give a better sense of it, we’ll walk through how engineering teams work here, what kinds of tools they build, and what this role looks like in practice.

Here you’re not given tasks — you define them

In many companies, work begins with a task. Here, it often starts with a vague signal: something doesn’t add up, a process feels inefficient, or a decision takes too long. From there, the job is to figure out what’s actually going on. And even once you understand the problem, that’s just the beginning.

The harder part is building systems that let you move from a high-level view to specific insights in seconds, spot anomalies, and gradually automate things that used to be done manually.

There’s no strict separation between “business” and “engineering” here. Developers talk directly to the teams who use these tools — marketing, analytics, product — and try to understand what’s actually needed.

A typical situation is not “implement feature X”, but rather:
there’s a problem → you break it down → suggest an approach → build it.

There are no detailed specs waiting for you. You’re expected to make decisions — about architecture, trade-offs, and what’s worth building. This kind of work suits people who like figuring things out on their own.

It’s not a “keep it running” kind of job

What kind of tools do we build — and what makes them interesting?

• The tools we build work with large amounts of data.
  That means dealing with real complexity: different sources, messy inputs, constant updates. It’s not just about processing data, but about making sense of it and turning it into something useful.
• They also have a direct impact on business decisions.
  What you build is used by teams every day — to understand performance, spot issues, and decide what to do next.
• At the same time, these tools don’t stay fixed.

You keep developing them. They behave more like a living system that reacts to changes around it: new data sources appear, priorities shift, things that made sense a few months ago stop working. Some parts of the system grow into something bigger, others get simplified or removed.

A big part of the work is coming back to the same areas — rethinking them, rebuilding them, and making them work better. Because of that, the job doesn’t really feel like maintenance.

It’s a mix of technical and creative challenge — a chance to build new features, sometimes even entirely new products. Proactivity is valued here, because many of the best ideas and solutions come from engineers themselves.

There isn’t just one path

There are multiple teams working on different internal products — analytics systems, marketing tools, data processing layers, and more. They’re connected, but each has its own focus. Most of our teams are relatively small, and each has its own atmosphere.

To give a bit more context, here’s a closer look at some of the marketing tools. We build systems for user acquisition teams that help automate performance marketing and bring together the work of UA managers, motion designers, and analysts.

There’s also a platform for working with playable ads. It covers the whole process: creating playable creatives, cloud builds, configuration, A/B testing, and performance analytics. We integrate with game engines and support the full cycle — from building a playable to analyzing how it performs.

Over time, developers can move between teams. Sometimes their interests shift, sometimes new directions appear. We’re open to that. It helps people stay engaged and keep working on new kinds of problems without having to leave the company.

Who feels comfortable here — and why people stay

This environment tends to work well for people who like figuring things out. 

• Not just solving assigned problems, but understanding how a system works end to end.
• Being able to say “I don’t know yet” — and then go and find the answer. 
• Staying in the loop when something is unclear, but not needing constant guidance to move forward.

Technical skills matter, of course. But they’re not the only thing that defines a strong engineer. What matters more is how you approach uncertainty, how you communicate, and how much ownership you take.

The same things are often the reason people stay. Technology itself isn’t the rare part anymore. What makes the difference is the environment: how decisions are made, how quickly things move, and who you’re working with.

At SayGames, there’s very little bureaucracy. You can talk directly to the people you need. Decisions don’t take weeks, and ideas can turn into real tools pretty quickly. It still feels a bit like a startup in that sense — even though the company is already large and stable.

We regularly hire engineers across different teams and domains at SayGames.

If you’re interested in building technologies, working close to the business, and figuring things out as you go — we should talk.