Tactile’s success is, without a doubt, grounded in our growing community. It fosters your skills no matter your discipline and gives you a place to be creative and impactful alongside other talented colleagues. In recent years, Tactile has been growing both by developing new games and reimagining old ones. This has pushed us to re-think the way we work, collaborate and the mindset we embrace throughout this process – both within our teams and also in how we recruit. We wanted to share an overview of our hiring process and what we’re looking for in future Tactilers.
We are proud of being a lean organisation. We have little hierarchy and work hard on nurturing an open and collaborative work environment in which each individual is encouraged to take ownership and grow. We do so by living and breathing our core values which emphasize trust, responsibility and mutual respect. When hiring new Tactilers, we want to make sure that we find the people who not only share these values, but who will also help to spread and cultivate them.
So, if you’re interested in a career at Tactile, we want to provide you with all the information you need to be set up for success. In this blog post, we’ll cover the steps in our typical recruitment process, explain how we interview for attitude, and also share some tips to help you nail your interviews.
💡You can always take a look at our current job openings via our Careers Page.
OUR RECRUITMENT PROCESS
Our Recruitment team has developed a standardized recruitment process across all teams, to ensure that everyone is considered and assessed in the same way.
We sometimes tweak the process for certain roles, but in general, this is what you can expect when you apply for a job at Tactile:
💡Here’s some tips to get started in your job search in Denmark and on how to write a stand-out CV.
1️⃣ Meet your recruiter
Whether you have applied via our Careers page, or were approached directly by someone from Tactile, your candidate journey starts with an introductory chat. If we’re interested in learning more about your background and motivation to join our team, one of our recruiters will reach out to you to set up a 30 minute introductory video call.
What is covered in this step? – Your experience relating to the role you are being considered for. We will also give you a general overview of Tactile, the role and the team you might be joining. This stage primarily aims to ensure that there is good chemistry between us and that our expectations towards the role are aligned.
💡We have prepared a list of tips to help you prepare for the initial call with a recruiter.
2️⃣ Meet your future Team Lead
The initial call is typically (but not for all roles) followed up with an interview with your potential future team lead. This is usually a 30 to 60 minute video call.
What is covered in this step? – The aim of this conversation is for the team lead to share more in-depth, technical information about the position and to dive further into your experience relating to this role. You can also expect them to ask some attitudinal questions (we’ll talk more about what these are in a bit) and in turn you can ask any questions which you might have around the role or the team (for example, how they work, collaborate, or how they define success within the team).
3️⃣ Showcase your talent in a skills test
The next step in the recruitment process is assessing your skills, which are relevant to the job. This is one of the most important steps in the process, because it gives you the opportunity to show off your skills and also to see what type of tasks await you if you were to accept the job.
What is covered in this step? – Our test assignments differ from role to role, but they are all prepared in-house, so they will give you a taste of what it’s like to work with our projects or our code. They’re mainly take-home tests, which you can work on for a pre-agreed amount of time.
💡We have prepared a list of tips to help you impress with your technical test.
4️⃣ Present and discuss your test results
If you do well on the skills test, you will be invited to meet with the team for a follow-up presentation and discussion. We will send you a more detailed agenda before the interview, so that you can prepare. If you’re based in (or near) Copenhagen, we will have this interview on-site at our office on Vestergade 33.
What is covered in this step? – In the first part of the interview, you will present and discuss your test solutions and why you made certain decisions in it. In the second part, you will discuss the more technical aspects of the role and the projects or products that you’ll be working on as a part of this team.
💡We have prepared a list of tips to help you nail your technical interviews.
5️⃣ Meet your future team
The last step in your recruitment journey with Tactile will be meeting your potential future team.
What is covered in this step? – You can expect the interviewing team to assess whether your values, motivation and ways of working align with how their team works at Tactile. And vice versa – this is an opportunity for you to see whether you see yourself working as a part of their team.
💡We have prepared a list of tips to help you prepare for the final team interview.
HOW WE INTERVIEW
At Tactile, we don’t only interview for hard skills, but also for attitude. What does this mean?
We follow an approach called structured interviewing. This means that when we interview for a position, we ask the same set of predetermined questions to every candidate. We use this approach because it helps us to minimize biases and it also ensures that every candidate is assessed in the same way.
During an interview at Tactile, you will be asked technical questions relating to your skills and knowledge, which are required for the role. Besides this, you can also expect to be asked attitudinal or behavioral questions. These questions help us to determine whether you are also a fit with our culture and values.
We use these questions to ask about your past behaviors in very specific situations (i.e. when you had to fix a bug in production). Besides technical situations, be prepared to answer questions about how you worked as a part of a team (i.e. how you gave feedback to a colleague).
These questions typically start with one of the following openers:
- “Could you tell us about a time when …”
- “Could you describe a situation where …”
- “Could you give an example of …”
We believe that asking about past behaviours is more valuable than asking about hypothetical situations and a much better indicator of how someone is likely to behave again in the future.
We of course understand that coming up with examples from your past is not always easy and takes some thinking power. Our interviewers are trained to help you with answering these questions – to give you space to think about your answers and to support you with some follow-up questions, in case you get stuck. The overall aim is to get to know you better!
🌱 COME GROW WITH US
Take a look at our Careers page to see our current job openings. This is also the fastest way to submit your application and get in touch with our Recruitment team.
You can find lots of relevant material, articles, employee spotlights and other content to help you prepare for your recruitment journey on our LinkedIn page.
We’re looking forward to meeting you! 👋
Time for Talent – with Riccardo Argiolas
Hi, my name is Riccardo, it’s nice to e-meet you! 👋
I’ve been part of Tactile for about four and a half years, working as a Gameplay Programmer. I started on Lily’s Garden, where I helped bring new content and features to the game. Later, I joined our Content Tools team, supporting designers and artists in shaping their creative visions. Most recently, I moved to the prototyping team, exploring new concepts and developing fresh game ideas.
As a programmer, I collaborate with colleagues across many different disciplines, so my work ranges from implementing UI to bringing gameplay designs to life.
🚀 Before Tactile
I’ve always loved not just playing games, but also creating them. As a kid, I was endlessly curious about board games and video games, always wanting to tweak them or invent my own versions.
Over time, this curiosity expanded into a passion for electronics and robotics. I spent countless hours designing circuits, soldering components, and programming microcontrollers, trying to make my little creations come to life.
After university, I decided to combine my creative interests with my technical ones, and that’s when I entered the games industry. I first worked as a gameplay designer, but soon realized I missed the technical side of development. That led me to move toward more technical design roles and eventually fully into gameplay programming.
💜 Joining Tactile
Joining Tactile has been a major step in my career. I’ve had the chance to work with highly experienced colleagues, learning from them in both hard and soft skills. The scale of the projects here has taught me how to structure and maintain code in a way that keeps it robust, readable, and enjoyable to work with.
Changing teams throughout my time at Tactile has also given me the chance to experience game development from many different angles. Each move – from a live game team, to internal tools, to rapid prototyping – came with its own rhythms, challenges, and ways of thinking. Shifting between these perspectives kept the work fresh and exciting, and it pushed me to adapt, learn new approaches, and see how all the pieces of development fit together.
On top of that, I’ve benefited from internal workshops, book clubs, and knowledge-sharing sessions that have given me new perspectives on how to solve problems and improve my craft.
💪 Having an impact
For me, the best part of working at Tactile is the people. It’s not only about competence and learning opportunities – it’s about how seamlessly ideas flow. Communicating, sharing opinions, and giving and receiving feedback happens naturally and genuinely. This environment makes it easy for me to contribute with my own ideas and grow both personally and professionally.
Being able to collaborate closely with my teammates is what makes the work truly rewarding, and I think that shows in the products we create together.
📚 The keys to success
🏗️ Be curious, and make things! Try building small games, join a game jam or two, talk to people, hear their stories, and learn from those experiences.
🗣️ I remind myself that success isn’t just about hard skills – soft skills matter just as much, and sometimes even more. Writing good code is important, but so is communicating clearly, understanding others, and learning how to turn ideas into reality.
🤝 A key to growth is embracing collaboration. Even a simple conversation with a colleague can reshape a problem or spark a new idea. Asking questions, sharing early drafts, and working through challenges together has always helped me reach better solutions than working in isolation.
In casual mobile games, live game operations have become incredibly important within the last decade. Prototyping, developing and launching a game is just the first step. The big task is keeping players engaged long-term, and this is where LiveOps come into play.
As a game developer, it became increasingly more evident and important to Tactile to have a unified place from which we can configure our games. And so, over time, we have developed an entire suite of tools that empower our teams to take full control of their games. We call it our LiveOps dashboard. It allows our teams to control exactly what players see and experience in a game.
On top of this, the dashboard enables us to stay true to our core values (such as validating all of our results with data) and to keep the promises we’ve made to our players (like 24/7 user support). The LiveOps dashboard can therefore be used for a variety of purposes – to schedule live events and tournaments, run A/B tests so that we can see what features are most impactful, to send engagement rewards and in general support users when they experience issues in a game, as well as to create curated player journeys for new or specific user groups.
We could have used a variety of 3rd party tools available on the market to do this, but having our own internal solution enables us to have all these different tools in one. Completely interconnected and managed by our Core tech team.
Taking a walk down memory lane
We tried to dig out the first line of code we ever committed to GitHub for the LiveOps dashboard project, but we were not even using Git back then yet 😂. And so, we asked our CTO, Morten, to fill in the gaps.
“The LiveOps Dashboard started out as a reporting dashboard, similar to how we use Looker today,” he starts, “It allowed us to see all of our revenue and data, mainly for our first big game called Skyline Skaters. We used it to track a variety of metrics such as ad revenue, impressions and clicks.”
At some point, the team wanted to be able to configure Skyline Skaters remotely. This was when they built a remote configuration tool within the reporting dashboard, which still exists in our current set-up. “Though it has evolved many times since then,” Morten adds. This initial version of the tool was a way for us to safely edit a JSON file that would get downloaded by a game, which allowed us to configure whatever we wanted in the game, completely remotely.
“The first version of the dashboard was built in pure JavaScript with AngularJS for the front-end, along with MongoDB and Redis, both of which we still use today,” he explains. As part of the remote configuration system, the team also built an ad mediation tool, which enabled us to control the waterfall of ad providers we worked with, as well as an additional support for remotely downloading asset bundles. This was a way for us to remotely distribute assets, such as allowing players to download a new city in Skyline Skaters to skate in.
Around that time, live operations in mobile games started growing drastically. Morten explains that they noticed some of our big competitors running events and features on a scheduled basis. “And so we introduced live events and scheduled features to the dashboard,” he says, “We basically built a tool that enabled us to remotely configure and schedule events within a game.”
From that followed the A/B testing feature, to ensure we’re making data driven decisions when releasing new features and… the rest is history.
From an old Angular project to automated game set-ups
This is where Tyler and Vera, our LiveOps Backend Engineers, come in.
When Vera joined Tactile in 2020, the LiveOps dashboard was a, well … cluttered AngularJS project. By then, AngularJS was already quite old and it was painful to add new features and functionalities to the dashboard. On top of this, updating it to a newer version turned out to be really difficult.
“We were stuck,” Vera says, “Either way we had to re-build the entire front-end from scratch, either in Angular or in a brand new framework.” After some discussion within the team, they decided to switch to React, which would allow them to build a much more modern dashboard UI.
The challenge was that the developers on our Core team at the time were primarily backend experts, but they had to take care of the entire stack. This meant that all of our front-end was built by backenders, without a product designer, which caused some UX challenges. When we started transitioning the dashboard to React, we decided to do so step by step, page by page.
As the first step, we decided to do a little trick. We made a basic React page, but displayed our old AngularJS version within an iFrame. “This allowed us to be quick, instead of having to build an entire new version of the dashboard, which would have taken a long time before being able to release it to our users,” explains Vera. Building it page by page allowed them to show the new UI whenever it was ready, and then remove the old AngularJS in iFrame display.
At the same time, we also hired our very first Product Designer, who came up with a brand new dashboard design, and soon after also our first ‘proper’ frontend focused engineer, who worked on integrating it in React. Our Product Designer spent a solid amount of time with the teams who use our LiveOps dashboard to really understand what they do and come up with a design that serves their needs as best as possible.
During this transition process, the team discovered that the back-end, just like the front-end, was outdated and hard to manage. “This is why we started experimenting with Dependency Injection,” explains Vera, “Everything that we build new is built using dependency injection (DI) and the old code is being refactored along the way.”
Tyler, who joined the team in 2024, joined the dashboard project several years post migration. He shares his thoughts on the state of the current dashboard codebase: “We are an extremely opinionated team, but also very democratic and flexible. We adhere to guidelines, but are open to changing them when there is a strong argument for it and when it makes sense. When there is a pattern in the code, it’s easy to see what is happening, so I can really feel the impact of the transition to DI.”
Future plans
Post-migration to React, the dashboard kept growing and expanding with new features and tools to enable our teams to work even faster and more efficiently.
One of the most significant additions in the last few years was the Player Journeys tool – designed by our Solutions Architect in close collaboration with the LiveOps and Product teams, and built from the ground-up in-house. This tool allows us to segment players and give them completely tailored experiences based on what live actions they take within the game. As our games are picked up by a wide variety of players – from experienced match-3 players to those who have opened a mobile game app for the very first time – it’s important to recognize their unique playing styles and tailor their player journey based on that.
Another big system we’re currently working on will enable us to empower new game teams to set-up their own projects on the LiveOps dashboard. At the moment, we have a manually maintained list of games. However, as our new company strategy is to ship (ship ship) more games, we have started building faster and more often. This created a lot of additional work on the Core team’s side, having to set-up and calibrate all the new projects for individual game teams. “We want to hand over the building power to the teams,” says Tyler, “This will remove us from the equation and empower the teams to start new projects themselves and to choose the modules they need to start building live game operations.”
But… Why build it and not just buy it?
“There is no one single tool on the market that offers what our LiveOps Dashboard does,” explains Tyler. Building this huge tool happened very organically for us. It started small, but over time we started adding more features to it, as we found a need for them. Vera adds: “We have built this tool with the user perspective in mind, which has allowed us to both get and act on feedback from our users very quickly.” Another aspect is that building it ourselves has given us the flexibility to make it exactly as we want it to be. “We can do whatever we want with our dashboard. It’s already very dynamic and we are still implementing more things to it,” she says.
By saying we can do what we want, Vera means that we can optimize workflows for specific roles in the company. For example, our User Support page includes a lot of game-specific data. Instead of using an external tool to display this and forcing the user to switch between several platforms, our LiveOps dashboard automatically enables this connection for them. “This makes their workflow faster and less tedious,” explains Tyler.
The requirements for building new features come from different sources, but most often it’s from the teams themselves. Recently, we added a Scheduled Feature Importer tool because Morten (our CTO) found a pain-point when working directly with the LiveOps team. This was great because the users don’t always know how to make their workflows better or that there are ways to automate them.
Building it well and building it for the future
We have already talked about the team applying dependency injection to the codebase and switching from Angular to React. This idea, like most others, originated from their book club. All of our Core programmers regularly meet to read and discuss technical books. This stems from their culture of wanting to improve as developers, but also to make continuous improvements to the code base. None of the big changes happened as a ‘light bulb moment’ or an ‘order from above’. Instead, they spawned from the team democratically and developed through a gradual iteration process.
“It’s important to note that we do not look at the books we read as Bibles,” laughs Vera, “We use our common sense to take ideas from them that make sense for our team.” On top of the book club, they also meet weekly to discuss different ways to improve things. The main purpose of these meetings is to create a common mindset about coding best practices, as well as to ensure a common vocabulary within the team when talking about different software engineering patterns and strategies.
“One thing that has had a huge impact on upholding our coding practices have been code reviews (PRs),” says Vera. “And we have a culture of being very picky in them,” Tyler chimes in. The aim is not to bring someone down and mark their code as bad, but rather to leave small comments and/or suggestions for improvement, which do not necessarily need to be applied. It’s usually things like: “You could rename this…” or “Have you thought about doing it this way instead?” “We always want to make the best code possible,” he explains. Vera adds that we always try to make changes in iteration and therefore keep PRs small so that they’re easy to review and understand.
Unit testing, CI/CD and DDD
All of our code is covered in unit and integration tests. On top of this, we have a QA team within our Core team responsible for testing what the programmers produce.
We also have daily automated deployments and can deploy manually at any time. There are basically no barriers to what can be deployed, which is enabled by the PRs and our amazing QA team. This continuous cycle allows us to build and deploy quickly, but it also enables us to react quickly if something isn’t working as it should be. Tyler explains that if their daily release does not go out, then it becomes their immediate #1 priority – having longer release cycles is not an option for the team.
Whilst things on the surface of our LiveOps dashboard might appear ‘simple’, the logic underneath is actually very complex. This is mainly due to this tool being extremely domain-heavy. For the team this means keeping as much as possible focused within one single domain and building ubiquitous language in collaboration with other teams.
“During my onboarding, the most challenging part was navigating all the complexity and figuring out how everything ties together,” Tyler remembers. There are a lot of things happening within our games – there’s the user experience, engagement and monetisation aspects – and we want things to keep happening. The games need to run and we also need to be able to collect data at the same time. For Vera the challenge is managing it all on the LiveOps side and that’s what makes her work so meaningful.