How We Do Engineering at Docker
As an engineer at Docker, you’ll be assigned to one of our cross-functional engineering teams, who will be your day-to-day colleagues. Our teams typically contain about five engineers, one Engineering Manager, one Product Manager, and one Product Designer. Most people are surprised by our high ratio of Product Managers and Product Designers. But this is important to us in making our teams truly autonomous, and in really understanding and focusing on the needs of our users.
Almost all our teams have all the members, or at least all the engineers, in one continent (either Europe or North America). Although we know how to work asynchronously when necessary, all being in a similar time zone does help with collaboration.
Below is a snapshot of our current practices. We know we are not perfect, and there are several things that have just evolved over the years and we know we can do better. In addition we are a fast-growing company, and even the practices that work well today will not continue to work as we double or triple in size. We believe in kaizen — continuous improvement: we have experimented with various changes, and will continue to experiment with more.
“The engineering team at Docker is great, I have had the chance to work with very smart engineers. The unique thing here is that everyone works on a product that they use on a day to day basis which leads to authentic/engaging discussions and innovative ideas. People truly have a passion for technology here.”
Gurleen Sethi, Software Engineer Ill
Our Engineering Teams
Each of our teams is responsible for one area, such as Accounts or Docker Extensions. We try to make them focus on a business domain rather than a component or a technology, which we have found in the past tends to lead to complicated cross-team coordination to complete a feature.
Teams are responsible for proposing their own goals for each quarter, based on their own understanding of their domain, their customers, and their priorities.
The design of our teams has been based on the book Team Topologies by Manuel Pais and Matthew Skelton. You can look at their website teamtopologies.com for more information about the model we follow.
Click on the team below to learn more about it.
The Accounts team ensures seamless and secure user and organization management across Docker and Docker Hub.
The Content Consumer team is dedicated to helping developers find and use Docker Images and keep them up to date. The team builds Docker Hub services as well as contributes features to Docker Desktop. Their stack is Go along with React (Typescript) and they deploy to AWS (EKS, Lambda) using Terraform and Helm.
The Content Publisher team is dedicated to helping publishers of Docker Images create content that developers can easily use and keep up to date. They run the Docker Verified Publisher and Docker sponsored Open Source programs. They primarily build and run Docker Hub services. Their stack is Go along with React (Typescript) and they deploy to AWS (EKS, ECS, Lambda).
The Customer Success team enables customers, developers, and their organizations, to be successfully and effectively onboarded to Docker’s tools, products, and latest features.
Docker Desktop is one of the core parts of our platform. It provides an environment for developers to build, share and run containers whether they are using Windows, Mac or Linux, seamlessly integrated into the operating system, bundling all the necessary container tools, and with a CLI and UI included. The Docker Desktop teams also develop docker compose, our tool for running multi-container applications. They code mostly in Go and React, with some C# and Swift, and on all three operating systems.
Docker Desktop Platform
The Docker Desktop Platform Team primarily serves the teams that write Docker Desktop by managing and improving internal tooling including the build and CI farm. It also manages the installation and update process within Docker Desktop. It therefore has both internal customers (developers from other teams who are contributing to Docker Desktop) and external ones (all Docker Desktop users as they install or update the product). Engineers in this team program mainly in Go with some C# and Swift, and work on Windows, Mac and Linux.
The Extensions team builds SDKs and APIs to help people extend Docker Desktop and, in the future, Docker Hub. They work closely with teams internal to Docker, partners and the community to help them be successful with the tools that they build. The team also uses the tools that they created to build extensions for Docker. The team’s stack is primarily Go and React (Typescript).
The Infrastructure team provides the compute layer that powers functions across Docker Inc, including the world’s largest library of container images, Docker Hub. We take raw cloud resources and mold them into highly available, self-service container infrastructure for our application teams. We use Docker products, numerous open source tools, cloud services, and automation we build to bind them together.
The Registry team is responsible for the storage and request processing of container images and other content available on Docker Hub. This includes making sure the services are highly available to millions of users in a performant way, as we receive up to 5000 requests/second. In terms of storage, the team manages petabytes of binary data that make up the content on Docker Hub along with associated metadata. They contribute to the Distribution open source project. Their stack is Go and they deploy to AWS (EKS and Lambda) using Terraform and Helm charts.
The Runtime team is responsible for maintaining and evolving the Docker Engine, CLI and components that make them up. This tooling is used by millions of developers all over the world and is shipped as part of Docker Desktop. They primarily work on open source projects in the Docker and Moby organizations on GitHub. Their stack is primarily Go and they work with low-level Linux features.
Processes and Meetings
Our teams are empowered to design their own processes, so although there are many similarities, there are differences between different teams.
We all follow a Scrum-like process, with standups daily, and sprint reviews, retrospectives, and planning once every two weeks.
In many companies, teams do demos of their sprint accomplishments within their teams: instead, we do them to the whole company. Everyone is encouraged to demonstrate their work in progress, not just completed work.
Some teams have additional regular meetings for grooming their backlog, or for discussing architecture and technical debt. We also have some cross-team communities, such as a Front End Forum.
As a nine-year old company, we have accumulated some tech debt over the years, but we recognise the importance of keeping it under control. For that reason, we aim to spend 20% of our time on tech debt repayment. The tech debt priorities are determined by engineers, with a focus on what is slowing them down the most.
We run Hackathons once a quarter, where we set a theme and then everyone in engineering, and anyone else in the company who wants to, spends a day prototyping innovations on that theme. (We’ve tried various other methods over the years, including annual hack weeks and 10% time, but this is the one that seems to get the highest participation). Of course we welcome ideas from engineers at other times too: we’re very meritocratic and non-hierarchical, and good ideas can come from anyone and do make it into the product.
“Docker is hands down the best team I’ve ever been a part of. No egos, challenging problems, open collaboration, and a team that shares a level of passion and developer obsession you won’t find anywhere else. Management here really cares about my personal growth and my team challenges me daily to be a better person and engineer.”
Josh Newman, Staff Software Engineer
Tools We Use
Some of our code is open source and some is closed source, but for source control, everyone uses GitHub. All code is reviewed by at least one other engineer (in some repositories, two others) before committing.
For issue tracking and sprint planning, we use a mixture of Jira and GitHub. There’s even one team who puts their sprint boards on Notion. Largely the open source repositories use GitHub and the closed source ones use Jira, although there are exceptions.
CI uses a mixture of Jenkins and GitHub Actions. Our SaaS services are AWS-based.
It is no exaggeration to say that we run a critical component of the world’s IT infrastructure, so we need 24×365 on-call support. This is split between Europe- and Americas-based engineers such that people are assigned to twelve-hour, daytime shifts for a whole week once every few weeks. Engineers working on SaaS services are expected, and other engineers are encouraged, to take part in the rotation. Being on call is compensated in addition to your normal pay, whether or not there are any incidents.
Our philosophy is that people should be able to fit their work around their life. We work from home, and we want people to be able to have the benefits of that in terms of organizing their time and their priorities. We have people who like to start early, or finish late, or take a break in the middle of the day. Various of our employees incorporate childcare or family commitments, or hobbies or exercise, into their day.
We have generous vacation allowances, and we expect people to use them. We want you to take time off and come back refreshed and ready to work! In addition, we have 12 Whaleness Days a year, which are whole company holidays, so when you come back you won’t even have a backlog of messages to catch up on.
“When I stop working, I’m not asked for more. When my family needs more support from me, I can do that. Docker supports me when life drags me down and doesn’t push me towards unhealthy work habits. From my peers, manager, and up to the executives, I feel that Docker loves me and my whole family.”
Alex Hokanson, Staff Software Engineer
Become a Member of our Engineering Team
When you’re ready to take the next step in your career and become a Docker engineer, browse our Current Openings to find the right role for you. Click on “Apply for this Position” and you will be walked through our application process. Our interviews for engineers follow the same basic format regardless of the role.
Our Engineer Interview Schedule
- 15 to 30 minutes with one of our recruiters, who will ask you about your job history, right-to-work status and salary expectations. This may immediately be followed by a quick 15 minutes technical screen with one of our engineers.
- 60 minute interview with the hiring manager for this role. The manager will ask in more detail about your job history and what you’re looking for, and will also explain to you what we’re looking for. They may also ask you to do a short programming problem.
- Two 60 to 90 minute interviews with engineers on the team. These interviews will concentrate on coding and other technical questions. You will need to screen share for these interviews.
- 30 minute interview with the hiring manager’s manager. This will cover the same information as the manager’s interview, but does not require coding.
- Some roles will have a final 30-minute interview with our VP of Engineering. This will be conversational and not require coding.
Some things to keep in mind while interviewing with us
- For the interviews that involve programming, we do want to see you write code. You can do that on your own computer using screen sharing, so that you can be comfortable in your own usual development environment. Other than having a development environment ready, no specific preparation is required.
- We do understand that some people are nervous about coding while being watched, but please treat it as if you were coding together with a colleague. We don’t ask trick questions, and you’re welcome to use Google or whatever other online resources you would normally use in your daily work, as well as discuss what you’re doing. We want you to do your best in as natural an environment as is possible in an interview, so that we can see how you think and how you code in everyday work.
- One last thing: we believe that interviewing should be a two-way process. We are looking for the right colleague, but you are also looking for the right job for you. So please ask whatever you need to in order to help you to make the decision of whether Docker is the right place for you.
“I love how Docker encourages diversity and collaboration to build new innovations. From engineering to marketing everyone’s ideas contribute to creating a better experience for the developers’ community. You feel like your voice really matters.”
Paco Valverde, Engineering Manager
Docker Engineers in Action
During DockerCon2021 Mark Higson, Staff Software Engineer, gave the presentation Beyond the UI: Hands-on coding with Docker’s new HTTP API’s. The focus of the talk was that websites, desktop apps and CLIs can’t cover every use case. When developers need to do something specialised, they turn to APIs. Mark discusses how Docker’s new API First strategy is driving internal development, and follows along on a practical, realistic coding exercise that puts them to use.
Our Docker YouTube channel and Docker blog have plenty of content from our engineers. Our engineers are actively involved in the developer community. Presentations about Docker best practices, new products,
Some of Docker’s French engineers gave talks at Devoxx France in 2021. This is the largest developer conference in France and Docker engineers were there to represent our company. Guillaume Lours, Sr. Software Engineer, talked about Dockerfile best practices while Yves Brissaud presented about building and using Cloud Native Application Bundles (CNAB) using Porter.
You can learn more and watch these talks (in French) by going to our Docker Blog.