Careers
Work on software that someone depends on
We build and run our own operational products, and we staff engineering teams for other people's estates. Both halves are production work with real consequences.
Why join us
What is different here
Real systems, not sandboxes
The work is production software that other businesses depend on — operational platforms, enterprise integrations, field applications. You will carry something you wrote.
Two sides to move between
We build our own products and we staff engineering teams for clients. People move between the two, which is a wider set of problems than either side offers alone.
AI as part of the craft
Everyone here is trained to use AI in delivery — reading undocumented code, scaffolding, tests, migrations. It is part of onboarding for every role, not a perk for a few.
Judgement over keyword count
We hire on how people think about failure modes. If you can explain what happens when a queued action is retried twice, we are interested.
The work itself
Two halves, and people who cross between them
Sazinga does two things. It builds and operates Sazinga Sarva, a set of business applications for operators — out-of-home advertising, compliance and audit, distribution and field sales, batch manufacturing, quoting, rentals and workplace training. And it staffs engineering teams inside other organisations' estates, across two pools: product and platform engineers, and enterprise application specialists working on SAP, Oracle, ServiceNow, integration and BI.
Those are not separate companies with a shared logo. The same people work on both, and moving between them is normal rather than a favour you have to ask for. A quarter spent inside a client's ERP programme teaches you things about governance, interfaces and other people's constraints that you cannot learn on a product you control. A quarter on one of our own applications teaches you what it is like to still be there when the decision you made eighteen months ago turns out to be wrong.
The honest version of the trade-off: you will not spend a year going deep on one codebase and nothing else. If that is what you want from the next stage of your career, this is the wrong place, and it is better to know that now than in month four.
The applications are at different stages, and that changes the work. Four are in production with paying operators, one is in customer trials, one is in build and one is pre-launch. Joining a product in build is a different job from joining one where a mistake reaches a customer the same afternoon. We say which is which before you accept.
Our recruitment process
Three steps, and an answer either way
- 01 A short note, not a formEmail us with what you want to work on. That tells us more than a set of form fields ever has, and it is the first thing we read.
- 02 An initial conversationA screening call about your experience and what you are looking for, followed by interviews with the people you would actually work alongside.
- 03 Clear feedback either wayWe tell you where you stand and why. Transparency through the process matters more to us than protecting an option we are not going to take.
What the interview asks
Questions about what goes wrong
We do not run a quiz on framework trivia. The questions that tell us something are about production judgement — what a system does under retry, duplication, load and partial failure. These are the real ones, published so you can think about them beforehand. Thinking about them beforehand is not cheating; it is the behaviour we are hiring for.
What happens when the same queued action is retried twice?
For mobile and backend candidates. If idempotency does not appear in the answer, something will eventually be double-counted — a payment, a stock movement, a delivery.
What would you do about a duplicate webhook arriving four hundred milliseconds after the first?
The same question from the other side of the wire. It separates people who have run a system in production from people who have written one.
How do you handle a table with fifty thousand rows and eight filters?
For frontend candidates. Operational software is dense screens used all day by someone who knows the domain better than the designer did. A hundred milliseconds matters when the action is performed four hundred times a shift.
What happens when an inbound IDoc arrives twice?
For SAP and integration candidates. Enterprise interfaces are replayed constantly — by a middleware retry, an operator, or a failed batch being rerun. The answer tells us whether you have supported an interface or only written one.
Two things we do not weight heavily: the length of the stack list on your CV, and whether you have used the exact tools we use. Someone who can explain why a decision was wrong in hindsight is worth more than someone who has never had one go wrong, because the second person has usually not been close enough to the consequences.
Your first month
What onboarding actually involves
- 01 Read before you shipThe first weeks are deliberately an overlap: reading, asking and pairing rather than opening pull requests. Teams that skip this look faster for three weeks and slower for six months, and we would rather be the second kind of team.
- 02 Learn the failure modes, not the feature listThe bar we set for the end of ramp-up is that you can describe how the system breaks — where money is decided, which writes are not idempotent, what a retry does — rather than what its screens do.
- 03 Get the AI tooling into your own loopExposure to AI assistance in delivery is part of onboarding for every role, including the consultants and the testers, not a perk for a few developers. What you learn alongside it is how to check the output, because that is the part that actually takes skill.
- 04 Own something small, end to endA change you scoped, wrote, reviewed with someone, deployed and then watched in production. Small enough to be safe, real enough that your name is on the merge.
Current openings
Open roles
No roles are listed right now. That does not mean we are not hiring — we take people on when the right note arrives more often than we run an open advert.
The roles that recur are the ones in the two talent pools: AI and machine learning, frontend, backend and mobile engineers on the product side; SAP, Oracle and Dynamics, ServiceNow, integration, BI and functional analysts on the enterprise side. If your work sits in one of those, write anyway. We would rather read a note out of season than miss someone because a vacancy had not been posted yet.
Send a short note about what you want to build to careers@sazinga.com. Tell us what you have worked on, what broke, and what you did about it. There is no form, no CTC field and no notice-period box — those are questions for a conversation, not a gate on getting one.
No form. Just tell us
what you want to build.
A few sentences about the work you want to do, and a CV if you have one to hand. We read every one and we reply either way.