Senior/Staff Engineer, Backend - RUST

Senior/Staff Backend Software Engineer (Rust, Remote)

Come help us build the best API testing tool, by developers, for developers.

Who are we?

ForAllSecure is a group of people united by a shared mission: making the world’s software safe & reliable. Our first step towards that goal is to democratize fuzzing.

Fuzzing is an automated testing technique with huge impact. Microsoft reports that 80%+ of their security vulnerabilities are discovered by fuzzing. But only the biggest tech companies and best vulnerability researchers have had the resources to leverage fuzzing. We are here to break down these barriers and bring fuzzing to the masses.

Continuous fuzzing will transform how we test software in our industry at large. It will be as fundamental as unit or integration testing, and we are responsible for making that positive change happen. It will empower developers to build better and safer software, faster.

What will you do?

You will join a small team passionate about API testing. We believe that there is a better way to develop and test web APIs, and that fuzzing is part of the solution. We are driven to deliver that and help out all the API developers out there.

We are looking for people with the same passion to help build this nascent product. Your day to day will likely involve, among other things:

• Adding features to our CLI and web API that will unlock more value for our customers.
• Working with our customers to understand how we can better provide a valuable & delightful experience.
• Coming up with feature ideas, and owning them from start to finish (ideation, validation, implementation, delivery, docs, ...)
• Optionally, improving our custom fuzzing engine, to improve our speed, coverage, and bugs it finds.

You don’t know fuzzing, or much about security? That’s alright! We’d love to teach you. And there’s plenty of work around the fuzzing tech (CLI/API) if that’s something you’re more comfortable.

Oh, and everything (but frontend) is written in Rust. So if you like Rust, you’ll have a blast. If you don’t know Rust but are curious about it, we’ll help you learn it as well!

Who are we looking for?

We do not care about your credentials, or whether you can implement a red-black tree in a coding interview. Instead we care about the following:

• Passion. Our mission resonates with you, and you are excited to drive it forward.
• Empathy. You care deeply about your co-workers and your customers. You will make technical decisions affecting our users, and we want users to always be on top of mind.
• Curiosity. You love to learn. You love to get better at things, through reading books or blog posts. You consider yourself a fast learner.
• Writing skills. You appreciate and are inspired by well-written documentation. You like writing your thoughts down and sharing them with others.
• Coding skills. We do not require formal education, but we do expect you to be a proficient coder. Again, you don’t need to know rust, but you should want to learn it (and will need to). Ideally, you’d have dabbled with web APIs before.

More specifically, on the technical side, we are looking for:

• Experience developing backend stack (API, Database, background jobs). Specific frameworks and tools are less important.
• RDBMS experience (ie: PostgreSQL)
• Experience operating web services in production and handling incidents.

In addition, you will likely end up using Jenkins, Docker, Terraform, Google Cloud. We don’t require experience in those, but we do expect a willingness to learn! There are also technologies that you might end up using based on interest, including fuzzing and frontend dev.

Our Team Culture

Culture is very important to our team, and therefore wanted to share with you what you can expect if you were to join us:

• Small & lean team. Highly motivated & lean team. You’ll be the 3rd engineer on the product.
• Remote-first. We have folks on both US coasts, and in Canada.
• Speed: Eric Ries claims speed at which you iterate is key. Iteration is not only about software, but about "validated learnings". He advocates a scientific approach to product development, built around quick validation of hypotheses using data from customers. This involves things like Reid Hoffman’s paper testing, and continuous delivery (we ❤️ Accelerate)
• Data-driven decision making: Iteration speed enables data-driven decision making. Instead of arguing about what to build, we look at the date collected from customers. Many times, the decision requires more data and the discussion shifts to how we can get it.
• Empowerment: Another important aspect of our decision making is that our team is empowered to make decisions. This avoids a number of issues. First, given that we are on the ground and close to customers (see "Empathy" below), we have the most context on how we can provide value to them, which is how we make this product successful. Second, we avoid design-by-committee issues. Third, giving team decision-making authority allows them to remain nimble & fast, there's not a lengthy approval process for inconsequential decisions.
• Focus: The result of iteration speed & data-driven decision making is focus. We might not always build stuff that customers want (mistakes happen, and that's ok -- see below). But the important part is we only keep what customers want. We don't want any dead weight slowing us down.
• Psychological safety: iteration speed reduces the impact of mistakes. We avoid investing too much effort without regular validation of the work. So, in our team, we embrace failure, and failure is just another "validated learning". This gives the team psychological safety, one of the 5 elements of high performing teams. On the technical side, continuous delivery also dampens any mistakes we make. While a mistake may find its way to production faster, it also gets fixed in production faster.
• Empathy: Engineers are close to customers. We get unfiltered feedback right from customers instead of playing a game of telephone. We can ask clarification questions. We can test our hypothesis. This also gives us the context and empathy we need in order to make good decisions. The product would not be successful if we did not do that. The empathy we gain from talking directly to customers also leads us to put a huge focus on usability, simplicity and user experience.
• Async communications: Another aspect of our decision making is that we embrace written communications over meetings. It enables the writer to be more deliberate with their thinking. They have the time to do research and build a coherent and backed case. It gives people a shared background to start an informed discussion. More specifically, we follow an RFD process for important technical decisions.
• Work-life balance. We care to have well-balanced & diverse team members. We can’t have that if we expect folks to work crazy hours. Heads up, you will however be expected to be part of an on-call rotation.