Docker Engineers
At Docker, everything we do is about developers. Not only is engineering by far our largest department, but we’re in the privileged position of writing software for software developers like us. Every day several million developers build their own software using our products, and we’re consistently rated as the most loved developer tool. We’re honored to have such a huge impact, as well as such affection from the community, and we continue to strive to make developers’ lives better every day.
How We Do Engineering at Docker
As an engineer at Docker, you’ll be assigned to one of our cross-functional engineering teams. 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’re not perfect, and there are several things that have just evolved over the years and we know we can do better. In addition, we’re 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’ve 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’ve 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.
Engineering Teams
Accounts
The Accounts team ensures seamless and secure user and organization management across Docker and Docker Hub.
Build
The Build team is responsible for maintaining and evolving Docker Build and BuildKit. These tools are the industry de facto standard for building container images and are used by millions of Docker users and CI systems all over the world. The team primarily works 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.
Content Consumer
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.
Customer Success
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 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.
Infrastructure
The Infrastructure team provides the compute layer that powers functions across Docker Inc, including Docker Hub, the world’s largest library of container images. 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.
Runtime
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.
Billing
The Billing team ensures painless purchasing, reliable billing, proper user entitling, and robust payment reporting within Docker’s products.
Business Enablement
The Business Enablement team provides observability and control for Business users to feel secure and informed about their developers’ use of their Docker subscription.
Content Publisher
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).
Docker Desktop
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.
Extensions
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).
Registry
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 of open source projects. Their stack is Go and they deploy to AWS (EKS and Lambda) using Terraform and Helm charts.
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 for 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.
On Call
It’s 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.
Work-Life Balance
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, finish late, or take a break in the middle of the day. Many of our employees incorporate childcare family commitments, 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!
“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
Docker Engineers in Action
Our Docker YouTube channel and Docker blog have plenty of content from our engineers. Our engineers are actively involved in the developer community giving presentations about Docker’s best practices, discussing new products and more.
During DockerCon2021, Mark Higson, Staff Software Engineer, gave the presentation “Beyond the UI: Hands-on coding with Docker’s new HTTP APIs.” The focus of the talk was that websites, desktop apps and CLIs can’t cover every use case. When developers need to do something specialized, they turn to APIs. Mark discussed how Docker’s new API First strategy is driving internal development, and gave a practical, realistic coding exercise that puts them to use.
Some of Docker’s 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.
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’ll 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’ll 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 of 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’re looking for the right colleague, but you’re 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