Continuous integration and delivery platform
Distributed across the US, Canada, Ireland, UK, Germany, Japan
CircleCI is a modern continuous integration and continuous delivery (CI/CD) platform. So, naturally, we practice this ourselves. There are more than 1M+ users on the CircleCI platform, which processes 3M+ builds on a typical weekday. If you’re reading this, it’s very likely you’ve used CircleCI to automate build, test, and deployment of software before at a previous company. Customers like Samsung, Ford Motor Company, and Condé Nast International all rely on CircleCI to operate, and more than 22,000 organizations have integrated CircleCI orbs into 65,000 repositories and nearly 18 million CI/CD pipelines. 🙌
We dogfood our own product and deploy anywhere from 400 to 700 times every week. We have very little manual testing, but lots of automated unit tests, automated integration tests where feasible, and lots of canaries and A/B testing. In the last 12 months, we’ve released over 100 features in addition to dozens of technical investments in our platform and services. If you love CI/CD, there’s no better place to work!
Automated financial management to save, plan, and invest all in one place
Palo Alto, CA or Remote (US)
At Wealthfront, we don’t have a QA team by design. Instead, we rely heavily on engineers to own their code’s quality throughout the software development process by investing heavily in multiple levels of automated testing, monitoring, and reporting. We’ve been working in a CI/CD environment since before it became common and our approach to continuous delivery is a core part of our product development process. We actively use A/B tests and feature flags to get code safely into production quickly and often. Don’t believe us? See when we last pushed to production here!
A perfect implementation isn’t necessary when a good implementation delivers value. We believe in iterating and recognize that we won’t have all of the answers up front. By taking bold, but educated steps to collect more information, we build a trove of data to drive future decisions. Engineers submit GitHub pull requests, which trigger linting, testing, and code quality scans before allowing a reviewer to approve it. After it’s approved, the PR triggers CircleCI to deploy to different environments (staging, prod, etc.). Automating our deployment pipelines allows us to deploy multiple times per day to production.
23 Open Positions
It’s safe to say that at Sibi, shipping is our heartbeat. We love quick iterations that refine our assumptions based on our learnings. That said, it’s not a madhouse. We lean heavily on feature flags and testing in production. If something goes wrong, we’re able to simply turn it off. We view everything we write as a hypothesis, and the goal is always to validate our assumptions in tiny bits and learn from each iteration. At the end of the day, if something goes wrong, recovery time is always more important to us than perfection. We work hard to create an environment where it’s safe to fail (see above).
3 Open Positions
Shipping code is the most visible way that engineers contribute to the success of Asana, and doing so in a fast and sustainable way is key.
Shipping fast starts with serious investment in tooling, such as continuous deployment with multiple pushes per day. It also takes focus and flow, like the kind you can have during our “No Meeting Wednesdays.”
But shipping fast and sustainably takes more than just effective work. When we’re focused, we write higher-quality code, and this translates to less technical debt, faster iteration, and less time fighting fires. While lots of hours in the office lead to the illusion of a lot of work, it often results in just a lot of energy spent treading water.
This is a long-term investment against the pervasive misconception that shipping fast means working unsustainably. Software isn’t going anywhere, and Asana’s engineering culture aims to support people to work well for decades to come.
48 Open Positions
We have a live test environment for every pull request and our latest “main” branch is always auto-deployed to our staging environment. We have one-click deployment to production and employ code reviews for every change, big or small. We invest into creating an excellent development and delivery experience to ensure users are constantly delighted with our progress (and so that we ourselves can enjoy working on our product!).
13 Open Positions
We have built a continuous integration system and strongly believe that our shipping velocity differentiates us from our peers. As an engineer, you can expect to push to production multiple times a day. We have a lightweight process to ship through the different stages of our pipeline and no explicit separate release is needed.
We also run a mature test suite on all code commits, which we monitor continuously with failures fixed within a certain SLA. Tests take minutes to run with an expectation that they should be fast, reliable, and not the long pole to pushing features.
Check out our roadmap, which we recently introduced to detail features as they are rolled out. We keep a tight feedback loop with our users, and build all features with them in mind.
We work on sprints primarily around planning, but we push to production every day. We strive to efficiently prioritize the features in our development pipeline and deploy as quickly as possible. The quicker we have a feature out, the quicker we can start iterating to provide our users with the functionality they really want. That’s not to say we’re not pragmatic! We take test coverage seriously. Millions of end users depend on our app, so if a bug happens during checkout, we’re losing people real business.
Still, we’re not fearful about deploying (and deploying quickly) because we trust our deployment process. Abe and Andy are always on-call and everyone else on the engineering team is on a weekly rotation. If you’re on-call, you’ll cycle in to help with our error alert feed. This helps expose everyone to different parts of the codebase, yet everyone has support should they need help figuring out an issue.
The life cycle of a project often starts with product requirements and engineers writing up an engineering design review. Unlike at other startups, Color invites the entire engineering team to participate in the design review of every design. On Tuesdays, the whole org gets together for an hour to take a look at all of the proposed engineering designs and provide feedback. Not only is it a great way to get a broader set of eyes on our work, but it also helps avoid silos with other teams and supports continuous delivery by keeping feedback loops tight.
Since most teams work on a weekly (or bi-weekly) sprint cadence, engineering designs can be implemented and shipped quickly. Production code deploys twice a day and we rely on both unit tests and end-to-end testing to ensure code ships smoothly. Rather than having a QA team, we rely on engineers to own their code’s quality through the CI testing, monitoring, and reporting process. Hand in hand with our focus on continuous delivery, is an emphasis on delivering reliably, and we’re always working to improve the performance of our database and queries. We integrate and test daily. This unique blend of systems engineering and bioinformatics enables us to build a revolutionary product that can easily scale, while keeping costs low.
We’re intentional about our onboarding process and try to lift up the entire engineering org by passing down best practices. To be on the same page, we try to make the codebase a clean, pleasant place to be with practices like automatic linting and formatting. As Anastassia, one of our senior software engineers says about the codebase, “It’s a nice house to be in.”
17 Open Positions
One of our core engineering principles is “Ship Fast” and we build in small batches and deliver often. Changes are made in individual branches with continuous integration pipelines. New features can be controlled via feature flags and our deployment process allows us to push code at any time. Ownership of code is end-to-end, so individual developers are pushing code to production themselves and can do so at any time of day.
We are constantly thinking of ways to make it safer to push new code. We depend on feature flagging to push features rapidly and with confidence, and are continually revising our end-to-end testing to balance coverage without the need to rewrite tests with each push. We’ll also borrow inspiration from other monitoring tools (like PagerDuty) to build features for Amplitude.
30 Open Positions
We believe that speed is one of the attributes that sets an organization apart, and we strive to support our engineers in moving as fast as possible. We place a heavy emphasis on automated tooling so we can write quality code and have it live in production without worrying about lingering issues. Our tests and live deployment previews are automatically run and built on every push. This avoids the need to run all tests locally and saves you precious time on your local machine. Our CodeBuild pipeline verifies and builds your changes, while Lerna enables you to deploy after your tests have passed.
We value not only code quality, but also speed. Tasks should take two hours, two days, or two weeks (and it’s never two weeks). This speed helps us remain nimble and fix previous issues quickly, so they don’t fester.
3 Open Positions
We invested heavily in automation from day one, so now all it takes to deploy is to approve and merge a GitHub pull request. Our staging environment is continuously updated every time anyone merges their branch to main, so our engineers can test their changes within 10 minutes against a full replica of our production environment.
Feature flags play a big role in helping us stay safe while moving fast. No matter how large a feature, we implement it in parts and wrap it in a flag so we can enable it just for ourselves and our friends in the product team. While our code never touches servers unless it has sufficient tests, uncovering unknowns in an environment where it's safe to make mistakes is what, at the end of the day, keeps our promises to our patients and users.
Researchers and clinicians from some of the leading neuro labs and hospitals in the country count on us to ensure their work helps everyone affected by brain disease. We've built Rune on the soundest principles of infrastructure and code management so we can bring them the data they need.
At WorkOS, we’re building a modern API platform that empowers any developer to quickly build and ship enterprise features. Everyone from early-stage startups to Fortune 500 companies rely on our platform to build enterprise-ready apps.
We are the antithesis of a slow-moving, big, technology company. Our customers are engineers as well, which means they can speak with a level of technical precision that enables us to iterate faster. We move quickly. We deploy many times a day. We keep a tight feedback loop with our customers.
It’s far better to constantly iterate with small changes than it is to build something new. We always do code reviews (typically from someone furthest from the code), and try to release bug fixes and deploy new features into production safely and quickly. We use per-PR sandboxes to easily test out changes during code reviews, use feature flags to guard larger changes, and a pre-prod staging environment for final testing before deploying to production. We don’t have a QA team, and our engineers own their code’s quality throughout the software development process by investing heavily in automated and manual testing, monitoring, and reporting.
We work hard to ship quickly (multiple times per week and sometimes daily) without sacrificing quality as we have so much to get to in our product roadmap! We invest in our processes, but also in our people. In exciting news, we raised a $20M Series A in February 2022, so if any of the above interests you, we encourage you to reach out and apply!
3 Open Positions
Once your commit has been approved by another engineer, it is immediately deployed to production when you hit merge. Our services are deployed to ECS and will be gracefully auto-rolled back if they fail to start. We use a variety of tools (Cloudwatch, Sentry, Pingdom) for monitoring and alerting, and Terraform to manage our infrastructure as code. (These are manually applied first to a staging environment, then to our production environment.) We use experiment flags to ship new features to production early, and then develop and deploy incrementally until they’re ready to turn on for all of our customers.
3 Open Positions
Part of our first sprint on every project is to push an MVP version of their product. We do this through multiple avenues, whether it’s using Netlify Deploy, GitHub Actions, or TravisCI. Our chosen method of delivery depends on the client team and their product, but we believe it’s the most important step for getting the feedback we need and streamlining our development process.
Want to List Your Company?
Submit a team profile!
Select 8 Values
Contact me (Lynne 👋)
Qualify Your Values
Reach Thousands of Devs
Find Value-Aligned Candidates
Have Meaningful Initial Conversations
Don't Fill Roles, Hire Teammates
Celebrate
You can post as many job openings as you want.