We're building infrastructure to help engineering teams understand and manage their licensing dependencies and security vulnerabilities.
Why join us?
We're building a rocketship company. Since going to market about 2 years ago, we've been crushing our revenue numbers every quarter with over 3 million dollars in ARR. Our customers include Uber, Hashicorp, Docker, Twitter, Zendesk, and more.
We're building infrastructure that powers a huge portion of the open source ecosystem. If you've ever used Docker, Webpack, Kubernetes, or ESLint, you've used code that relies on FOSSA. Our partners include the Linux Foundation, the JS Foundation, and the Cloud Native Computing Foundation. Their projects rely on FOSSA.
We care about and invest in each of our team members. Our engineering team is small and efficient. Each engineer who joins has the opportunity to take ownership and make defining technical and cultural decisions on our team.
We're a product company that's also solving a real and deeply technical problem in software engineering. This is not your average CRUD app. We tackle sophisticated technical challenges at scale, and build products that extract meaningful insights from a complex problem domain.
Engineering at FOSSA
Our engineering team operates on 2-week sprints. We have the usual engineering processes you'd expect from a modern startup: CI/CD, automated testing, code review, push-to-deploy. All of us are generalists, although different people focus on what they're strongest at.
Engineers have a lot of autonomy. Many product decisions are engineering-driven. Day-to-day work generally involves resolving time-sensitive strategic customer requests, and then focusing on product and infrastructure work. Generally, interrupt-ish work (e.g. customer requests) doesn't take more than a couple hours per sprint.
Everyone on our engineering team can interact with customers if they want too. We run a weekly support/on-call rotation, backed by a documented support and operations playbook. Our customer success, support engineer, and product teams help us field requests from customers, and we cooperate closely with strategic enterprise accounts. Engineers who enjoy working with customers often jump in across the company to help close strategic deals and manage deployments for strategic accounts.
Our business domain is intrinsically complex. Customers (and engineers) often have a poor understanding of programming systems, build systems, and package managers. We build software that needs to deeply integrate with these tools, understand their behavior, and provide meaningful insights to non-technical audiences.
Modeling this domain is complex. Different programming systems treat dependencies in different (often incompatible) ways. Enterprise customers will often have their own bespoke package management systems on top of existing build tools. Building our data and domain model is a balancing act between being general enough to work with a wide range of use cases, but specific enough to be performant and intuitive.
Integrating with customer environments is complex. Most engineers don't have a deep understanding of their tools, and build complexity is often compounded by years of legacy build tool modifications, bespoke build processes, and third-party tool plugins. Our analysis software needs to be smart enough to automatically integrate with a large variety of environments, but flexible enough to work with customer-specific quirks.
We operate this software at scale with zero downtime. We live within our customers' CI and build pipelines. When we have a bug, the customers' builds break. Performance and reliability are critical for both our analysis software and its supporting infrastructure. This infrastructure must be easily deployed, operated, maintained, and debugged on both cloud and on-premises hardware.
Right now, we solve most of these problems through heuristics, hacks, and brute force, and we think that taking a machine learning approach could be a force multiplier in developing many of our projects such as license identification, code identification and attribution. We are searching for a ML with engineering bent to help own the creation of the initial ML infrastructure. You'll have a blank slate to define how ML is done at FOSSA.
License Identification - this is a fairly simple text classification problem on the surface, but becomes more interesting when people combine multiple pieces of software together. When that happens, we need to understand which pieces were put together, and make inferences about the intent of the humans who wrote the code.
Code Identification and Attribution - we need to identify open source packages by examining their source code. At the surface, this is basically a gigantic search problem - we're building Google for all the code in the world. On top of this, we need to understand attribution (e.g. identifying project forks, or identifying the true author of code that's been copy pasted between open source packages).
Our Security team is currently developing solutions around processing vulnerability data, including: building distributed processing pipelines, defining strategies around custom taxonomy identification, creating custom policy workflows, etc.
Working at FOSSA
Our team is human. We recognize that even the best people make mistakes, and we deliberately foster a culture of psychological safety. We act in good faith, and we trust that our teammates act in good faith. We are open, transparent, and honest about all things. Internally, we talk openly about our financials, the state of our business, and our business and engineering decisions. We collaborate closely on hard engineering tasks. When we make mistakes or miss estimates, we own up to our actions and work together to become better engineers and teammates. We improve our team rather than blaming our team members.
Our team is scrappy. We don't let perfect be the enemy of done. We focus on iterating with customer feedback rather than getting everything right the first time. We prefer prototypes over speculation. We experiment with engineering and product strategies to help us build the best possible product. We experiment with our culture and processes to help us move as quickly and efficiently as we can.
Our team is deliberate. We use data and metrics to focus our engineering efforts on the areas of greatest impact. We make well thought-out trade-offs between delivery time, technical debt, and risk. We think hard about when to be customer-driven and when to follow our roadmap. We optimize for engineering impact on revenue. We build our engineering culture intentionally to help us meet these goals.
We have an unlimited PTO policy.
We have catering 5 days a week, in addition to ad-hoc team lunches.
In SF's Financial District right across the street from the Montgomery BART station. It is near delicious coffee shops and restaurants.
Work from Home
Our team members WFH whenever they need to. All of our meetings have the option to video call in.
We don't have any rules about when to be in the office, and anyone can WFH whenever they need to.
Our office has board games and Super Smash Bros., and we do regular team off-sites. We also have open happy hours every other Friday.
We do company and engineering retreats on a regular basis. Last quarter, we AirBnB'd a beautiful house in Carmel-by-the-Sea for a weekend engineering retreat.
We're located close to the BART and CalTrain, and several of our current team members commute from out of SF.
We provide full medical, vision and dental coverage.
We have a Slack channel with all the company dogs who visit! Come meet Dough, Rollie, Huffie, Moose, and others.
Interested in this company?
Skip straight to final-round interviews by applying through Triplebyte.