Working at Speakeasy
At Speakeasy we’re building the next generation of API infrastructure. APIs both external and internal are increasingly important but are often artificially restricted in usage and potential revenue, often through poor developer experience. This is especially true of REST APIs which are 80%+ of the ecosystem. Consumers who rely on these critical interfaces are left with little to no last mile tooling meaning their “average time to 200” is measured in days and weeks. We have been building out Client SDKs as a Service as our first product along with a suite of tooling for API authentication, telemetry and more. We believe this is just the beginning and are expanding deeper into the stack capturing more of the API value chain as we go.
How engineering works at Speakeasy
How are the teams structured?
There’s 9 of us total, 5 on the West Coast of the US, 1 in central, and 3 in London. Being so small there’s no hierarchy. We want everyone at the company to have autonomy to make decisions. We trust everyone on the team to know when to gather feedback on major design decisions and when to push on their own. One of the great things about working at a infrastructure company is that the engineers are able to be involved in the full scope of the business. Engineers join sales calls, and user interviews; marketing is a shared responsibility with everyone working on putting out blog posts. The non-engineers on the team (dev-rel & product) are also required to use the product. Thus far, every member of the team has submitted a PR to the core repo.That is a tradition we want to maintain as we scale the team.
What tools do engineers use?
However, as a company providing developer experience products , we end up working in every language: Go, Python, Typescript, Ruby, PHP, Swift, Terraform, and more. It’s incredibly fun having the opportunity to dip into all these different communities. We’re a polyglot team !
Can developers pick their own tools?
What tools someone uses are up to each engineer’s preference (besides github). People are allowed to pick their own laptops. Most work on mac, but we have engineers who have opted for windows. Like most teams, opinions on IDEs vary greatly. Most common is VSCode, but some people prefer IntelliJ Our team has definitely adopted AI as part of our day to day work. The whole team (not just developers) is using co-pilot, and chatGPT. We also strongly believe in dogfooding.
How does the development process work? What's the process for working through bugs, features and tech debt?
Most people would describe us as agile, although we don’t have the formal trappings of Scrum (scrum master, TPM, etc). We maintain a backlog of tickets on an ongoing basis. New things come in everyday, and we slot them into our existing queue of work wherever necessary. Once a week we do a high level review to make sure we’re still working on the most important things.
There’s a high level of autonomy when it comes to addressing bugs and tech debt. We hire engineers who are empathetic towards customers and understand the product. We trust the team to determine when something is urgent, and when it can wait. For tech debt, we let people tackle it whenever they think it’s important and is becoming an impediment to the team’s success.
How does code get reviewed, merged, and deployed?
We run everything via Github. PRs are opened by whoever took the lead on the feature, and they select their reviewers. We do our best to spread reviews around the team to make sure there aren’t any bottlenecks. Reviews are expected within 24 hrs of a PR being posted. If that timeline passes, the feature lead can use their discretion to either merge in the change, or to follow up with reviewers and make sure they do it.
Our team’s velocity is prolific and the number of features being worked on concurrently is high, so we’ve orchestrated a merge queue to make sure that we’re not accidentally introducing regressions.
Deployment is all automatic. Deployment to a dev environment happens whenever a PR is opened. Deployment to prod is automatically triggered whenever a PR is merged into main.
What is the QA process?
We have a lot of automated QA in place. We test new versions of our SDK creation workflow against a directory of OpenAPI files that contains ~4000 specs. That exposes our generation to the full breadth of OpenAPI and helps us make sure that we are not introducing any regressions. Our vision is to provide a standardised developer experience across all APIs.
What are some recent examples of interesting development challenges solved by internal teams as part of building the product?
Our code generation system is truly next gen, one of the problems that we had to solve along the way was crafting a way to make adding languages more repeatable. Our code generation engine therefore works off of a combination of templating and AST type manipulation. We also use LLMs to make sure our customer’s APIs are described in the best way possible.
How does on-call work?
One of the major benefits of being split between London & the west coast is we have folks online 24 hrs a day, that makes the OC burden a lot more manageable, there’s no need for 1am pagerduty alerts.
At any given moment we have one person in SF & London as our primary OC. They hand-off when they end their work days.
Hiring process at Speakeasy
How does the application process work? What are the stages and what is the timeline?
We’re hiring, so please get in touch. The best way is via the job postings on our company page. We offer two different flavours for the application process. Most common is the traditional path, two phone screens followed by a (virtual) onsite where you meet the whole team. Our interview process focuses mainly on collaborative work and problem solving, rather than in-person coding exercises.
For some candidates, we also offer the option of a collaboration period, where they contract with us for a couple of weeks. Joining a startup is a big decision for both sides. A collaboration period gives everyone the opportunity to see what it would look like to be a full time member of the team.
What is the career progression framework? How are promotions and performance reviews managed?
We are very flat, we don’t have any managers. As we grow and reach scale, we’ll add in formal frameworks for promotion & performance reviews. Today, performance reviews happen as part of our day to day work and daily discussions. “Promotion” is simply whether the company is growing and gaining more customers. For the foreseeable future, we all succeed and fail as one team.
Console is the place developers go to find the best tools. Each week, our weekly newsletter picks out the most interesting tools and new releases. We keep track of everything - dev tools, devops, cloud, and APIs - so you don't have to.