Moving from classic IT into iGaming: what transfers and what to relearn

Every month hundreds of developers, testers, analysts and DevOps engineers move into iGaming from «regular» IT — from food tech, e-commerce, banks and outsourcing. The reason is simple: the industry pays above market, grows faster than many verticals and is almost always short of engineers, because some candidates rule themselves out straight away over the niche's reputation. For those who stay, it is one of the few segments where engineering experience monetises without starting from scratch — yesterday's backend developer from retail is, after a couple of weeks of onboarding, closing production incidents alongside people with three years in the industry. Here is what from your current stack transfers directly, what you will need to learn, and how to make the move without the typical mistakes — from CV to bank account.

Which roles transfer 1-to-1

The good news: the industry doesn't need a "casino specialist" — it needs an engineer who can solve concrete technical problems. The domain gets added on top, not instead. The core skill set for the four most common technical roles transfers almost without loss:

Interviews for technical positions are structured the same way as everywhere else 90% of the time: code on a whiteboard or in CoderPad, an architecture discussion, walking through a past incident. Domain questions usually make up one section out of three or four, not the whole interview — a detailed breakdown of the interview format is in the article "Interviewing in iGaming". For full requirements and pay bands for each role, see the profiles of the backend developer, QA engineer page and data engineer.

What to learn: the industry domain

The domain in iGaming isn't about gambling — it's about regulation and numbers that don't occur in this concentration anywhere else. The minimum vocabulary you can't pass even a junior interview without:

• RTP (Return to Player) and house edge. The percentage of stakes that on average gets returned to the player over the long run. Backend and QA need to understand where this number gets calculated and why it can't be changed "on the fly" without recertification.
• Wagering. The bonus's playthrough condition — how many times the bonus amount has to be wagered before a win can be withdrawn. The source of half the bugs and half the support tickets, which is why QA has to know wagering logic like the multiplication table.
• Licences and regulation. Malta (MGA), Curaçao, the UK (UKGC), and other jurisdictions — each has its own requirements for bet logging, limits, responsible gaming, and data retention. For DevOps and backend this directly shapes the architecture: geo-blocking, auditable logs, data retention.
• High-risk payments. Gambling falls into the high-risk category for payment providers and acquiring banks — higher fees, harder onboarding, more checks when integrating a new payment method. That's not a blocker for you as a developer, but it explains why the payment stack in iGaming is more complex than in ordinary e-commerce — more on the role itself in the profile of the payments manager.
• Anti-fraud and KYC/AML. Identity verification, tracking fraud and money-laundering patterns — the data overlaps with data engineering and BI at almost every company; this is usually owned in the org chart by a compliance manager, who backend and data most often coordinate domain logic with.

Learning this vocabulary to the level of «confidently passes a technical interview» usually takes one to two weeks of reading documentation and job profiles; reaching «works fluently with the domain logic in production» takes the first month and a half to two months on the job. Good employers build that time into onboarding and don't expect instant expertise: at interview they more often test your ability to get up to speed quickly in an unfamiliar domain rather than ready-made knowledge of it.

It is also worth understanding the difference between licences, because the entire product architecture depends on it. MGA (Malta) and UKGC (UK) are strict jurisdictions with detailed code audits, mandatory reporting and tough responsible gambling requirements; Curaçao is faster and cheaper to obtain, but the product requirements are softer too. For an engineer this means a different level of bureaucracy around every release: where in regular e-commerce a feature simply ships, in a licensed iGaming product it may need sign-off from the compliance department or even an external auditor.

The upsides of moving over

The main argument is money and speed of growth. The industry pays engineers a noticeable premium over classic IT for three reasons: some candidates rule themselves out over the industry's reputation, production stakes run in real time with no room for error, and the companies themselves are usually profitable and willing to pay for hiring speed. Reference pay bands for a Mid-level position:

At Senior and Lead level the gap is usually even wider — here the premium starts to reflect not just the domain but the shortage of people willing to fill department-head positions. The full catalog of pay bands by level and location is in each role's profile, including BI analytics. The second upside is speed of growth: product teams are small, decisions get made fast, and an experienced engineer often grows into a tech lead or architect within 12–18 months — faster than at large corporations with long career ladders.

The downsides: stigma, banks, closed countries

The upsides aren't free. Three things worth knowing ahead of time so they don't catch you off guard after the offer.

• Stigma. Not all relatives, friends, or even future employers in other industries view gambling neutrally. Gambling is associated with addiction and social harm, and some people react warily to "I work at a casino," even if your role is writing backend code for the payment queue rather than talking anyone into betting more.
• Banks and payments. Gambling is flagged in payment systems as a high-risk MCC category. If your salary or contractor fee arrives with an explicit mention of casino/betting/gambling in the payment reference, some banks — especially in conservative jurisdictions — may request additional source-of-funds documents or temporarily freeze the transaction pending review. It is solvable, but better to know before the first transfer rather than after.
• Countries closed to hiring. The legal status of online gambling varies widely by country: in some jurisdictions it is licensed and legal, in others it is partly or fully banned, including working for foreign operators. For compliance reasons, some international companies won't hire employees from certain countries directly on payroll, working only through contractor arrangements or not considering those locations at all. This is worth clarifying on the very first call with the recruiter, not after the offer has been agreed.
• Regulatory instability of markets. Online gambling is regulated at the level of individual countries and even states, and the rules change: a market can tighten licensing, raise taxes or temporarily shut out operators without a local licence. For a product team this means the area you have been working on for six months sometimes gets wound down not through any fault of the business but because of a regulator's decision — factor that into your expectations just as you would in any other regulated industry such as fintech.

None of these cancel out the upsides — most engineers in the industry go through this without serious consequences. But preparing ahead is cheaper than sorting it out after the fact.

How to present your experience on a CV

A CV for an iGaming job barely differs from an ordinary technical CV — with one important adjustment: the domain doesn't scare off the recruiter here, it actually works in your favor if the emphasis is placed correctly.

1. Technical stack comes first. Languages, frameworks, infrastructure, metrics (latency, RPS, uptime, test coverage) need to be visible right away, before the recruiter even reads the industry name.
2. The domain as an achievement, not an excuse. "Designed a fault-tolerant queue for 50K+ bets per minute during a live event" sounds stronger than the neutral "worked at a betting company."
3. Regulatory experience is a universal skill. If you've worked with KYC/AML, PCI DSS, GDPR, or licensing-body audits, call it out as a separate line item. It's a direct bridge into fintech if you decide to switch industries again.
4. How you word the company name. You don't need to hide the brand, but you can use a neutral "international iGaming platform" or "regulated online gaming operator" at the top of your CV — this is standard, respected phrasing in the industry, not a euphemism.

Another practical trick is keeping two versions of the summary at the top of your CV for different application streams: one that explicitly names your iGaming experience and metrics for the industry's recruiters, another that emphasizes transferable technical skills if you're also considering offers outside the niche. A breakdown with good and bad phrasing examples, a structure template, and common mistakes is in a separate guide "How to write a CV for iGaming".

The stigma question at the interview

Sooner or later on a call (usually from the recruiter, less often the hiring manager), a direct or indirect question comes up: "how do you feel about this being gambling?" It's not a trap — companies genuinely screen out people who'd leave three months later over a values mismatch, and they'd rather find that out upfront.

• Answer honestly, without forced enthusiasm. You don't have to say "I love gambling" — most engineers in the industry aren't gamblers themselves. A calm "I approach it professionally: it's a regulated industry with serious engineering challenges" is enough.
• Lean on facts about regulation. Mention licensing, mandatory responsible-gaming mechanisms (limits, self-exclusion), and the fact that legal operators care about this just as much as the regulator — this shows you understand the ethical framework rather than ignoring it.
• Focus on the engineering challenge. Real money in real time, load spikes during sports events, RNG fairness under audit — these are genuinely hard technical problems, and it's more interesting to talk about them sincerely than to justify yourself.

If the doubts are serious and about personal values rather than phrasing, that's also a legitimate reason not to go into the industry — and it's better to figure that out at the CV stage than after moving to a new place.

The first 90 days on the job

By the end of the third month, most engineers from classic IT stop feeling like newcomers to the domain — after that, it's just another vertical on the CV, only with a higher pay range. Current tech jobs with a format filter are on the remote positions page, and for a specific stack — for example, backend roles — through the job search.

FAQ

Do you need a specialized degree or gambling certificate to get a technical position? No. Technical roles are hired on engineering skills, and the domain is learned on the job over the first one to two months.

Is it true that it's hard to move back from iGaming into ordinary IT? No, not if the CV is framed around technical achievements and metrics rather than just the industry's name — recruiters outside iGaming look at the stack and results the same way they do anywhere else.

Which role is easiest to enter from scratch with no prior industry experience? QA and backend — because of the high volume of open positions and because the domain part in test scenarios and APIs is the fastest to pick up.

Are there companies that won't consider candidates from certain countries? Yes, because of compliance requirements and local regulation, some operators restrict hiring by geography — this is a standard question to clarify on the first call with a recruiter, not a reason to skip applying in advance.

Is it worth mentioning on a CV that you previously worked outside iGaming? Definitely — experience in other industries is exactly what shows your core engineering skills have been tested outside the niche, and that's valued just as much as domain knowledge, which gets learned on the job anyway.