One of the things I love about interviewing candidates for Audible is having the opportunity to meet interesting people who bring tremendous passion and a thirst for knowledge. I get asked so many great questions about what it’s like to work at Audible from these great people and even get to learn from them. Because I’ve received so many great questions, I wanted to share some of them with potential future candidates to help get a sense of Audible’s software engineering culture.

Photo of Audible employee opening door

I’d love to hear additional questions you may have too. If I get enough, I’ll write another post with these. Send them to @audible_careers and @tylopoda on Twitter and we will do our best to answer them promptly. Use the hashtag #AskAudibleEngineering

I’ve been a member of software engineering at Audible for just under seven years now. I began my Audible story in 2011 as a developer on what was then, our only website team. Including myself we had fewer than a dozen developers working on our entire website. These days we have multiple “two-pizza teams” working on a range of core domains and experiences across the site. One of my more interesting projects was leading the design and implementation of our web player as well as the supporting APIs and services that power the experience.

In 2014, I made the decision to switch to management and began leading a web team, owning the Library page with the support of my mentor and manager. Over the next few years, I moved around on several web teams, at points owning the Library, customer acquisition, web player, cancellation flow, and others.

In 2015, I decided I wanted to expand my technical knowledge and breadth, and moved to manage our Platform Services team, owning the core services for audio delivery, consumption, and device management for Audible. Most recently, I took on leadership of an entire customer experience domain team, owning the player experience across all of Audible’s surfaces. It’s been an incredible rocket-ship of a journey.

During this time, I conducted numerous interviews across a wide swath of Audible’s tech teams and heard some great questions.

These were some of the interesting ones:

”How important is code coverage to your team?”

Code coverage is important to us as a measure of quality, but not the only one we measure. We believe in upholding a high quality bar not just for code coverage, but functional test coverage, code quality metrics like style guidelines and complexity, and the performance and reliability of our systems. While we measure the code coverage and try to cover at least 80% of our code with tests, we specifically focus on ensuring we are holistically upholding quality across the whole customer experience. We employ techniques like A/B testing, blue/green deployments and canary testing, automated rollbacks, and take a metrics-driven approach to ensure we meet these goals.

We run our unit tests as part of development builds and ensure tests are included in all of our feature development. We measure the coverage during our CI/CD builds and many services and surfaces have rules to break the build if coverage decreases.

Photo of Audible employee coding

“Do you do pair coding often?”

Our teams do buddy code sometimes, especially with complex solutions or when a code review is tricky, but it’s more common for us to pair design. We believe everyone on the team should have a voice in ensuring our design is well-architected, simple and elegant, performant, and scalable so we include the team in whiteboard sessions and more official design reviews. We want everyone from interns to our senior principal engineers to contribute to ensuring our systems are well-designed.

We have documented best practices and tenets to help guide these sessions, but we don’t believe in rigid rules from top-down. We believe teams should have information and the ability to make informed decisions about their designs, especially understanding the trade-offs between various options. However, we want teams to be empowered to make their own decisions as the owners of their code and systems. If a team wants to use C# and has valid reasons, we may question it, but it’s ultimately up to the team.

Photo of Audible employees having a conversation outside the office

Our team encourages continual learning and knowledge sharing

“How much time do you code vs time spent in meetings?”

Senior engineers and principal engineers tend to spend more time meeting with other teams and reviewing design and architecture than junior engineers. Our goal is to minimize meeting time and ensure that the meetings we do have are effective and the time is well-spent. If a meeting has no agenda or nothing actionable results from it, we will cancel any subsequent meetings until this is addressed.

Our engineers can expect to participate in several recurring meetings, mostly around the agile sprint ceremonies. We conduct grooming sessions as a team to understand and clarify requirements and estimate complexity and points for stories. We hold sprint planning once every two weeks to start a new sprint and commit to the stories we believe can be completed. We also have sprint demos to show our work and solicit feedback for the next sprint as well as a team retrospective to identify and vote on the largest pain points and positive points from the sprint to adapt and improve. There’s also a daily standup for the team, but these tend to take less than 10 minutes.

Our team encourages continual learning and knowledge sharing, so we also have a weekly brown-bag session where engineers—and others—can share something they’ve learned recently or trends in technology they’ve found interesting. Recent examples include a deep dive on an interesting production issue that uncovered unknown tight coupling between microservices and resulted in plans for new Chaos Experiments, an overview of Kotlin, and an explanation of the different audio and video streaming protocols and codecs. It’s one of my favorite times of the week.

In general, our engineers plan to spend about 15-20% of their time in these meetings, but should be getting something in return. If not, our managers are happy to address the problems.

Put simply, when you write code at Audible, it’s going to be seen by our customers very quickly.

“How often will my work get released to production?”

Our different surfaces have different release cycles, but in general, we prefer to minimize the release cycle, have smaller batch sizes, and increase cadence of customer-benefiting experiences. Our iOS, Android, and FireOS apps are released to the major stores according to the platform timelines which tend to be once every two weeks to one month. Our website is released once per week. Many of our services are fully automated with Continuous Deployment and are released immediately—as soon as the tests pass after code is checked in.

Across all of our platforms, we are exploring mechanisms to increase the pace at which we can deliver features and beneficial experiences to our customers in general. In many cases this results in decoupling from the release cycle. We perform A/B experiments where new experiences are rolled out to a subset of users for testing and feedback. We use feature flags and toggles across surfaces to enable the ability to enable and disable certain features without releasing new code. Lastly, we prefer to build business logic in the services which sometimes allow us to enable or disable features on the back end without a release.

Put simply, when you write code at Audible, it’s going to be seen by our customers very quickly.

“What’s the ratio of testers to developers?”

Audible does have a QA team that focuses on general quality across the breadth of Audible’s experiences. This team is considered a platform team for the rest of Audible and works to provide guidance, tools, and frameworks for enabling teams to own their own quality. We believe—much like DevOps—that teams should run the code they write in production, teams should own the quality of the code they build. In many teams, the developers write the automated tests—both unit and integration—for the features they build. We prefer to have different engineers write the feature and the test to improve documentation and quality standards. In some teams, developers write the automated tests—unit, integration, performance, and reliability—while some work closely with QA engineers who help to develop tests for particularly complex domains.

Because we tend to have developers writing tests, the majority of Audible’s technology organization are developers. However, we have, and are hiring great SDETs and QA Engineers as well. Some of the most successful engineers I know at Audible have grown their careers through test engineering. We have career paths for senior and principal test engineers, not only software developers, I believe the regard for quality, the understanding of the full system and it’s dependencies, and knowledge of the entire business domain are key requirements for test engineers, so they tend to develop these skills, but they are also incredibly useful in becoming a senior engineer in general. I personally started my development career building test automation harnesses and tools, and carry that passion for quality and insistence on high standards with me today.

Since you’ve read along so diligently to this point, I’ll throw in a bonus question I get in almost every interview.

“What is your tech stack?”

Most teams at Audible use Java as the primary programming language. Nearly all of our services, the website, shared libraries, and the Android/FireOS applications are built with Java. It provides a lingua franca for much of the engineering organization.

On top of this though, we use a variety of open source and internal frameworks, as well as embracing Amazon Web Services. Our web applications are built on an Amazon framework on top of Spring MVC and use front-end technologies like React and Angular. Our services use an internal RPC protocol for internal requests, but also have REST endpoints that serve JSON. Our framework allows us to simply define the service model and instantly build a service scaffold where just the business logic needs to be built as well as client libraries for a variety of languages including Java, Ruby, Python, Perl, and C++ if desired.

We also use AWS heavily and have been users of S3, EC2, and SQS since the beginning of AWS. These days, we use many of the services including DynamoDB, RDS, Cloudfront, and Lambda for serverless applications.

I hope the answers to these questions provide a nice glimpse into the engineering culture and what it’s like to be on one of our engineering teams at Audible. If you have additional questions send them over. If this all sounds great and you’d like to explore our opportunities, check them out on our careers site at We look forward to meeting you!