Fadir Reverse Interview

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. 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 recongized that maintainance is the largest long-term cost.

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 75% of what we need then we will likely use it.
• 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?

• The primary focus will be on automated integration and end-to-end testing 
• There will be some areas where full coverage unit testing will be needed but much of the system is not suited for it.
• Once we are large enough, a dedicated QA engineer will be hired.

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 will be established.

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

• We will be following full CI/CD practices. 
• Merges into the staging or production branches will run all tests and fully deploy without direct human intervention
• The CI/CD tools will be GitLab’s pipelines

Is the infrastructure described in the source somewhere?

• We will be using Terraform to fully manage the infrastructure.
• Its templates along with the CI scripts will be part of the source.

What are the key technologies used?

• The system is hosted on AWS. The key items there are
  • Elastic Kubernetes Service for servers/docker images
  • RDS for database services
  • Terraform for infrastructure management
  • Amazon MQ for managed RabbitMQ servers
  • Quicksight for BI/Reporting
  • Cloud Watch, Cloud Trail, etc for the usual monitoring
• The primary backend language is Go but others will be used in special cases.
• The frontend framework is React
• GitLab for source control, CI/CD
• NodeRed for workflow automation

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 frontend 2-3 developers
• For the backend 4-6 developers
• One were are large enough, we will add a QA and system ops

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 will be 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.

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
• Since all development is internal, we don’t have any need for formal estimations, sprint planning sessions, etc.
• We will focus on having a clearly defined and prioritised backlog that the dev team can pull tasks out of as needed.

What is the regulare meeting cadence?

• We run a 2 week sprint.
• A sprint start call on Monday. The goal is this meeeting is to make sure there are enough items 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. 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.

What do release cadences generally look like?

• In general, features will be released when they are complete rather than on a formal release schedule.
• The exception will be the launching of new brands or anything that requires coordination with 3rd parties.
• In those cases, we target a soft release to be two weeks before any hard deadline

Who sets the priorities/schedule?

• Priorities will be set by the management team with input from the development team.
• Schedule will be set by the development team based on the priorities.

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 life of a code review?

• To start with, code reviews will be very informal. 
• As the team is built, we, as a group, will define the process. 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 Product

What are your most important product metrics?

• For the company, total deposits and net gaming revenue.
• For the dev team, system uptime, outstanding bugs/issues, consistent releases of new functionality

What is the current version of the product?

• MVP

What are your highest priorities right now?

• Adding user focused features. Particularly additional payment methods and game suppliers.
• Building operationally efficient systems. This is a bit vague but, at its core, this means building the system so that it makes everyone’s jobs easier rather than something they have to fight with.