Postman is the world's leading collaboration platform for API development. Postman's features simplify each step of building an API & streamline collaboration to help create better APIs—faster. More than 30 million developers & 500,000 organizations worldwide use Postman today, and we continue to strive humbly towards our mission of 100 million connected developers & serving companies as they seek to innovate in an API-first world. Our customers are doing more and more astounding things with the Postman product every day, and as a result, we are growing rapidly.
We highly recommend reading The "API-First World" graphic novel to understand the bigger picture & our vision at Postman.
About the team & role:
The “Automation Testing” team at Postman is responsible for a set of products designed to help users test their APIs, manually and otherwise. This means there are a wide range of problems to solve – from a globally distributed system capable of executing hundreds of thousands of collections, to a browser-based client capable of running hours-long jobs, to CLI tools used to test production-grade APIs. The team primarily operates in an asynchronous manner, leveraging tools like Slack, Jira, and Confluence to stay on the same page. There is usually only one recurring meeting for the team every week, though team members can choose to work synchronously when appropriate.
Engineers on the team are encouraged to operate across the stack instead of siloing themselves into “frontend-only” or “backend-only” modes of operation. Folks do tend to specialize in whatever they find interesting, but are perfectly capable of building quality products by themselves as well. Everyone is expected to understand that, while part of the job is to write code, their actual responsibility is to build a great product and experience. This entails working hand-in-hand with everyone outside of Engineering, taking ownership of the product and experience as a whole.
Day-to-day work:
- This is a hybrid role where you’re expected to work out of Postman’s Bangalore office three days a week – Monday, Wednesday, and Friday. The team is distributed across three timezones, however, and the working model is an asynchronous, remote-first model.
-
Folks have a fair amount of control over their work schedule and tend to start and end their days at different times. This also means that a rigid sprint/scrum/agile model with daily stand-ups doesn’t work well – so we’ve adopted a more flexible model. In simple terms, everyone starts their day with the next milestone in mind, gets a sense of what the rest of the team is aiming to achieve, and figures out what they can contribute.
-
There’s a lot of written work that happens – engineering specifications, implementation documents, and, of course, pull requests. Most of the time in a day will likely be spent on technical design, discussion, and writing. Coding tends to be the fastest and easiest part, since it happens once everyone has a clear enough idea of what to write.
-
Part of the day goes towards engaging with users on platforms like Github or Discourse. This could be as simple as answering basic questions users might have, or addressing specific issues and pushing bug fixes. These interactions tend to inform the decisions we make as a team, so these are important!
-
While we engineer solutions to the best of our abilities, it’s inevitable that things go wrong once in a while. Participating in the on-call rotation is an important part of everyone’s role, and tends to take up 2 weeks every two months or so, with one week as the secondary on-call and another week as the primary.
About You:
-
At least 3 years of professional experience in the field. This is not an entry level role and you’re expected to have mastery over the basic operational aspects of software engineering, along with some exposure to building and maintaining production-grade products. There are no strict language or framework requirements, but you will have to get familiar with Javascript, React, Node.js, and adjacent tech to succeed in this role. Of course, you’ll have a whole team helping you learn, so this shouldn’t be a huge concern.
-
Familiarity across the stack, or an enthusiastic attitude to fill in your knowledge gaps. The team is already capable of building great products without being siloed into “frontend”, “backend”, etc. roles, and the expectation remains the same for this role.
-
You have empathy for the end users and your teammates (living things in general, really). This reflects in how usable your product is, how you write your code, and how you work with others.
