The Process

What is the hiring process?

Our typical interview process consists of four steps:

1. Phone screen with our recruiter
2. A non-technical interview with the hiring manager
3. 1st technical interview with the hiring manager
4. 2nd technical interview with a second developer

We try to complete these interviews in a fairly short period of time. We don't want the process to last months.
Having a very long process doesn't help us hire better people and we want to be respectful of our applicants' time.

Step 1:

The phone screen is a quick call to make sure that you are a fit for the role and to explain the basic parameters for it.

Step 2:

The non-technical interview with the hiring manager is to discuss your work history, what you are looking for, if we are a good cultural fit as well as providing an opportunity for you to ask questions.

Step 3:

The 1st technical interview is not a whiteboard coding interview. It is about your overall understanding of software development. The goal is to learn how you think, not your ability to write a sorting algorithm.
If possible, it is very useful to have some project you worked on to review and discuss. However, we fully understand that not everyone has something they can share so this is a nice to have not a requirement.

Step 4:

The 2nd technical interview will be more targeted about your knowledge of the key technologies we use: Typescript, nodeJS, pixi.js

There will still not be any whiteboard coding but there will be a number of more technical questions.

What is your hiring philosophy?

We try to make sure to hire not just on technical ability but personality as well.
If someone is an amazing developer but is very hard to work with then they are not for us.
We spend a lot of our time interacting with our co-workers so we feel very strongly that everyone should have a good experience.

The Role

What does onboarding look like?

The onboarding focuses getting you making small changes as quickly as possible

On the first day, you should be able to have the development environment working and be able make changes.

For the first few weeks, the focus will be on making small changes in a variety of areas to give you a broad understanding of code.

How much freedom for decision making do individual developers have?

As long as you follow the agreed upon code styles & solid programming principles, you will have a lot of freedom of decision. Particular in areas where you are leading the development.

That said, we feel that it is extremely important that major decisions such as those relating to system architecture, technologies used, etc are made by the team as a whole not any one individual.

What are core work hours?

10 - 15 CET

What management style does my immediate manager have?

Very good of course (but they are one writing this document)

Overall, our management philosophy is to hire good people, give them the tools they need and get out of their way. We have no interest in managing everyone’s day to day tasks. 

Because of that we also expect everyone to be able to be given something to work on and manage the details themselves. And that they will let everyone know if they run into any problems or delays, ask for additional help when needed, etc.

What is the ratio of remote to office workers?

We are fully remote but have shared offices/coworking available in some places

What peripherals and hardware does the company provide?

We provide all equipment needed for your work.

The Tech

How would you describe your engineering culture?

We are focused on building long-term maintainable systems. There will always be a need to deliver in the short-term but we recognize that, by building good tools for non-developers to use, we can optimize the game development process and make everyone's work better.

Do you tend to roll your own solutions more often or rely on third party tools? 

As a general rule, anytime we can use a third party tool, we will. At least to start with.

The goal is ultimately to get functionality out so if a third party tool gets us most of what we need then we will likely use it to start.

However, over time, as we have a better understanding of what we need and the limitations of third party tools, we will move to more custom inhouse implementations.

How is code tested?

While we implement automated, integration and end-to-end testing, the nature of games requires extensive manual testing.

Is static code analysis used?

Yes

How are bugs tracked?

To start, informal reports which are then added to the primary task tracking tool.

If volumes get large enough, a more formal process and dedicated tool will be established.

What does the team's CI/CD workflows look like?

We will be following full CI/CD best practices.

Merges into the staging branches run all tests and fully deploy without direct human intervention

Due to the regulator requirements, deploys to production are a more manual process to initiate but most the deploy will be automated

The primary CI/CD tool is GitLab’s pipelines

Is the infrastructure described in the source somewhere?

We are using Terraform and Gitlab pipelines to fully manage the infrastructure.

Those templates along with the CI scripts are part of the source.

What are the key technologies used?

The platform we use is provided by Tequity

Their platform provides all the non-game specific functionality.

So we only need to write the code need for our games (math & mechanics on the backed, game engine on the frontend)

The backend language is NodeJs.

The frontend framework is Typescript using Pixi.js for rendering

GitLab for source control, CI/CD

What development environment / OS is used.

The system should be environment and OS agnostic.
It will be up to the individual what they want to use.

The Team

What will be the size of the team?

We are still growing so these are long term estimates

For the game engine and tools team will be 4-8 developers

For the individual games, the goal is for one developer to be able to handle 2-4 games. But that will depend heavily on the quality of the tools. If needed to maintain quality, we will hire more devs and reduce the number of games they work on.

What is the junior/senior balance of the team?

The goal will be 1-3-1. 

One senior, three mid-level, one junior

But, given the team sizes, that might not always be the case

How does intra/inter-team communication typically work?

We are very informal.

Slack is primary communication tool

Outside of the regular meetings, we expect everyone to raise any issues or needs directly with the relevant people

There will never be a requirement to formally schedule meetings when a quick chat will do.

One requirement to make this work is to fully document any decisions made and to communicate them to the rest of the team.

What happens when the team misses a release target?

Missed release targets are a process failure not an individual one so we figure why it happened.

• Were the requirements incomplete?
• Were there enough resources?
• Were the estimates just wrong?

What is the project management style?

Kaban more or less

We are in the process of reworking our project management to better suit the overall game development process. This part will be updated as soon as the changes are finalized.

What is the regular meeting cadence?

We run a 2 week sprint.

A sprint start call on Monday. The goal of this meeting is to make sure there are enough items in the backlog for the sprint.

Checkin calls every other day (Monday, Wednesday and Friday when there is not a sprint start or end call). These could be considered standups but they will be more informal to start. The goal is to keep everyone in touch rather than have a formal process.

Finally a sprint end call on the second Friday.

Other meetings will happen but we try to keep them to a minimum and as early in the week as possible.

Who sets the priorities/schedule?

Priorities will be set by the management team with input from the development team.

There are two different parts to the schedule: internal commitments and external commitments.

Internal commitments are much more flexible since we can still adjust the overall schedule.

External commitments are very important to meet since they directly affect our reputation as a company.

Maintaining a clear understanding of the two is a key component of the planning & project management.

How are differences of opinions resolved?

With a bias towards action. We feel it is generally better to make a decision quickly whenever possible.

If the team can't come to a consensus quickly, the final decision will fall to whoever is the lead in that area.

What is the style of code reviews?

With code reviews, it is important to fit the process to the team, not the team to the process.

One of the most important things is make sure the reviews do not cause delays in the development process. If people have to wait days for a review then the process is not working.

The overall philosophy of code reviews isn't to drill into anyone code but to ensure the code meets our development standards.

This means the main statements during a review should be 'why?' not that the code is wrong or that it should have been done a certain way.

For example, if the reviewer feels some code isn't structured right or is not following standards then they should ask why the developer implemented it that way. Not just tell them they are wrong and need to change it.