Software Engineering Internship Experience at Postman
What it’s like to intern as a Software Engineer at Postman
When I was in the second year of engineering, I heard from my college seniors that Postman is the most popular API testing tool they used for their final year capstone project.
Like hundreds of other fellow undergrads, I started exploring for the opportunities at Postman. Then I didn’t know that it’s an Indian Company. I did research about the company and was glad to see that all the three founders are from India. I applied for an Internship and I was lucky enough to have cracked the Interview and had a six months Internship opportunity.
Interning at Postman was an enriching experience and made me appreciate how Abhinav’s side project has become one of the best known developer-first companies in the world. As I look back on my past six months, I cannot believe how much I have grown personally, technically and professionally.
Here, I’m sharing my experience as a Software Engineering Intern at Postman.
Let’s start with Postman.
Postman leads the way in the API-first Universe.
Postman is an API-First Development Platform. It is used by 8 million developers and more than 400,000 companies to access 130 million APIs every month. According to a survey, there are 23 million developers in the World, and one-third of them are already using Postman to gear up their development.
I was so excited to work on something that might have an impact on millions of developers across the world.
In Short — I lived all the phases of SDLC
I started my internship as a newbie developer as I had little to no experience working on any real-time project. I was asked to build a Postman Collection in the first week so that I’ll learn the essential features offered by Postman. And then I was assigned a project “Integration of Postman Native Apps with Interceptor”. It was a long due feature request. The Interceptor was available for Chrome App but there was no support for Interceptor after the Chrome app was deprecated and Postman has released its native app.
The project was so exciting and challenging as many were waiting for Interceptor to be released.
It began with understanding the existing behaviour of the Chrome App and then I designed the workflow and finally started coding for the same. I must say, I lived all the phases from conceptualization to delivery of the feature to the end-users.
A little context about my project, which you can skip :p
Making API calls in the context of the browser’s session is a common use case. This feature is available for Postman Chrome App using Interceptor Chrome Extension. As Postman Chrome App is deprecated now, I have integrated Interceptor for Postman Native App to support two major features:
• Capturing browser cookies to make authenticated calls from Postman App
• Capturing HTTP requests from the browser and saving them to Postman’s History or CollectionClick here to learn more.
Team
The team is very supportive. Anyone can go to anyone’s desk and ask anything. Discussing with different people within the team/organization helps to develop new aspects of the same problem that you might have not even considered. No doubts are small or big, doubts are doubts here. They’ve also helped me in improving the quality of the code I wrote by following best practices and standards to ensure better performance and scalability.
I could not have asked for a better set of people to work with. Right from my super cool Manager to extremely talented colleagues, it is fun to learn, work and grow.
Mentorship: Smart people everywhere
The office is full of some of the greatest tech brains. I’ve met some of the most hard-working people, some of the super talented people, and some of the kindest people under one roof. I must say everyone here is best at what she/he does.
You won’t even feel that you’re a noob or so because you’ll be responsible for your domain within your squad as Postman follows Domain Driven Design principles.
I remember my mentor told me “Spend 15 mins whenever wherever you’re stuck! Don’t just copy and paste the code from StackOverflow if you find it. Learn the logic/concept behind the code before you paste it.”
Noone teaches/trains you here but they make you learn by yourself. If you ask for help you’d get it, but don’t expect any spoon-feeding.
Very strict code review
The code review was the toughest part. Writing code takes lesser time than addressing the comments on PR. Even if a single line of code is modified it must be reviewed by any of the team members before it goes to production or beta.
Each and every line of my code was read by my manager. I must say he has an eagle 👀 eye, he used to point out a mistake which is too small to notice.
For software that is being used by millions of users, the code needed to be as optimized as possible. Even a single unnecessary instruction has to be carefully pruned from the code before it is pushed to the master branch.
I still remember when my first PR got approved and merged! 🎉
Knowing the fact that the feature you’re working on is rolled out to the end-users, it’s a moment of pride to have your code deployed in production. And the moment of pride keeps changing as I grow with the Postman.
Flat hierarchy
The word ‘Hierarchy’ doesn’t exist in Postman’s Dictionary. You can speak up, go up to anyone’s desk. Noone and nothing is gonna stop you. For me, I work with one of the Co-Founders, Abhijit Kane. He is so down to earth, helpful and generous I never felt that he was too senior to me. I learn a lot from his modesty.
Interns are full-time employees with Intern title
People treat you like a Full-Time Employee in the office so there is no difference between an Intern and FTE. This experience is really awesome. You get to be part of the Standups, all-hands meetings and you are subjected to the same treatment as the FTEs.
Demo Days
Wednesdays are #demodays! 🎤
Demo days have been great to share what gets done and what is shipping or has shipped.
Postman has been successfully using demo days as a way of inter-team collaboration for a few years now. It is useful for the cross-pollination of ideas and information. Everyone is supposed to present their work in front of the team. The people from San Fransico HQ and other remote offices join online for demo days.
The first day of the demo that I attended was so informative. I listened to everyone talk and I was wondering what they were talking about. They’ve presented something beyond my knowledge.
I remember my first demo which I have given for the first collection made by me. I was so nervous to talk to everyone who was quite experienced than me, but when I began giving the demo, the way the individuals who were sitting in front of me listened to me made me feel confident. Everyone was listening to my words as I have been talking about the next big feature of Postman, I felt.
Strict deadlines
Deadlines are important inside the company. Everyone is supposed to finish their assigned tasks within the deadline unless there’s any blocker. Individuals should be answerable to their manager if they’re failing to meet their deadlines.
I remember my mentor telling me that my code could impact 8 million users at a moment. One day delay, there’s going to be a delay for 8 M users.
Challenging projects
As I heard from my seniors, most of the time interns are assigned a very small task that might not be of immediate concern to the organization, but here I got a chance to work for a feature request by users.
I remember the first day I was told that every single line of code written by me will go to production someday. You have to live up to the expectations of millions of developers across the globe who use Postman to power their APIs.
I worked on Interceptor Support for Postman Native Apps for which users were waiting for long. Implementing the flow to sync the browser cookies from Interceptor to the app was so challenging. It required a way to communicate between the Postman App and Interceptor.
For the first iteration, I exposed a command-line based API and later on the UI for the same is shipped.
Flexible work schedule
Employees can come in late, work from home, or leave early if they want to.
Isn’t it so good if one is allowed to come to the office at 11 AM, and one can continue staying up late and not waking up early?
I was lucky that I wasn’t supposed to enter the office at 9 AM. Yes, I can stay up till 3 AM binge-watching a series on Netflix like I did during college days.
Ownership
At Postman, everyone is expected to figure out things on their own and is responsible for e2e delivery of the product. Being through all the phases of the development life cycle from design till maintenance gives full context about the project, one is working on.
I was given a fairly challenging project, and this was my first full-blown Software Design project. Although I had a mentor I was expected and even encouraged to have full ownership of my project. Right from the beginning of my internship, I was encouraged by my manager to make decisions on my own and proceed with solving the issues. He gave me complete freedom to make changes in the codebase. With great freedom, comes great responsibility. There have been situations when I was ambiguous about choosing the right path. But as time went on, I got used to that. Thanks to Postman, I improved my decision-making skills.
I was supposed to write RFCs, RCA for reported bugs, documentation for APIs and test plans. By doing this, I get to learn business logic. I even took part in our GitHub Issues thread conversations and interact with users via Discourse.
Monthly Meetups
For monthly meetups, we’ve people joining from companies like Atlassian, Cisco, Adobe, etc. I got to interact with people outside my company and this helped me build my connections.
The best part about meetups is goodies. I love collecting stickers.
Cooper — Our Chief Happiness Officer ❤
I remember my first day Cooper suddenly started barking at me, I was so scared, Goutam, our office manager came to me and asked me to show some love to Cooper and he became friendly to me within a couple of minutes. So kind, Cooper! ❤️
As they say, a picture is worth a thousand words. These pictures will tell you how cool is our endearing Cooper!
Perks bring Fun at Work
Apart from various reasons, the following perks also made me say — “I’m not enjoying at work, I’m enjoying my work!”
- Turning Coffee into Code — There are free coffee vending machines inside the office. I must admit that coffee breaks in between my office hours helped me to increase my productivity.
- Snacks — Ah, It never let me feel hungry :p
- Foosball — Quite often, I used to play Foosball just after my lunch.
- PS4 — Frankly, I’m not good at playing FIFA or any other XBOX games. Still, I enjoy losing my game against my colleagues.
- Breakfast & Lunch — Eating with my colleagues helped me to build a relationship with others within the organization.
- Jam session — I love to enjoy the jam sessions in between my work.
Spacewalk — Team outing
The team outing has been a fuel station for us after months of coding, debugging and building. For me, it was a great opportunity to interact and have fun with the team. I am sharing a few pics of the resort where we have been for a quick break from our work.
This was all about my personal experience. Now coming to the learning part. So here’s what I learned from my Internship while working on a live project:
Scale Makes a huge difference
If the number of requests increases from thousand to a billion or more, does the code still work? Or does it take a long time to execute now?
✔ How many users are going to use the software?
✔ How much data will be processed?
✔ How fast is your software?
These are questions that we as college students, hardly think about. Our college projects were usually short-sighted. Now, these kinds of the question set an upper limit on what a piece of software is capable of. Scalability is not a code style. It’s an engineering problem, and it is closely related to system architecture.
I remember one of the functions in my code was taking approx 60ms to encrypt a payload of 6OKB size, and this was not a point of concern for me. My manager didn’t approve my PR after seeing the performance table and he asked me to reduce it to 5–10ms. Even a single millisecond matters!
The scale at which each of the features you’re working is being used today is incredible and definitely gives you a high sense of accountability. A mistake in a single line of code and it’s gonna affect millions of users! You realize you don’t want to stop when you witness the amount of impact your little piece of code is having on its users.
Using a version control system — properly
When I was in college, I was familiar with Git & GitHub. Though I knew about basic branching and merging, I used to commit all the changes to the master branch only. Once I started working here, I came to know how useful is version control for collaboration within the team.
- Each organization has its branching strategies to fulfill the essential objectives such as individuals and teams that can contribute to the codebase without needing a global context of what else is being worked upon.
- A commit should ideally include a complete, isolated change. The commit message should brief the changes made. A well-crafted commit message is the best way to communicate context about a change to fellow developers. A diff will tell you what changed, but only the commit message can properly tell you why.
- Review your own PR before anyone else does. Make the purpose of the pull request clear. See the diff and ensure the changes are intended ones. PR should have a clear description of its intention. Having a culture of writing good pull requests within a team can make a huge difference in productivity.
Luckier are those who don’t get merge conflicts. Sometimes resolving conflicts is a pain in git.
Working with a large codebase
Back in college, we used to work on projects that had like 15–20 files or so. Built in less than a week, the whole project could be understood in a few hours. Once I started my internship, I was supposed to work on a codebase containing hundreds of files spread across dozens of folders. I spent a tremendous amount of time understanding the codebase before I started writing my code. It can take months to understand the whole project, and hours to debug a bug that’s spread across multiple files.
The first time I looked at the project repository I was so scared. I didn’t even know where to start understanding the code. Later I realized it just requires little more time and little more patience.
Writing clean, readable and maintainable code
While doing college projects, all I focused on was getting the shit done and I never really cared whether the code I am writing is clean and maintainable or not. This resulted in scrambled pieces of code that somehow worked at the time. But two days later even I wouldn’t understand why I had written a certain piece of code that way. And changing some parts of the code almost always broke other parts?
Now it’s not just getting things done, but done nicely and efficiently.
Writing code is easy but maintaining isn’t? Writing code easy to read and maintain is a skill other than the problem solving.
- Knowing that the code you write will be read, understood, and improved/modified by someone else (or even yourself) in the future makes you write code that’s maintainable. It’s an inescapable fact that writing maintainable code is hard.
Writing the code that you can read is super easy but writing the code which others can read is tough.
- Always write code that is simple to read and which will be easy to understand for developers. Writing readable code will result in a better pull request because if code is easy to read, it means it’s easy to review as well. Write comments in your code explaining why you are doing something. Mention your assumptions and the business logic of the function written below your comment. This will make the code read more like spoken language.
- Code for humans not machines — Write your code as you speak. Naming variables, functions are super important. One does not simply name variable. It’s difficult but the pay off for naming things properly is well worth the effort. Proper naming lets code one level up to be read, understood, and debugged more quickly.
I encountered memes related to naming a variable many times while in college. Then it didn’t make any sense to me. Now I realize that they weren’t memes, but the reality.
- Pure functions — Break your code into pure functions as much as possible. Pure functions are easy to unit test and read.
The importance of using a Test Driven Development approach
I remember I made a mistake, I didn’t handle exception at one place in my code and it broke the production app. This could’ve been avoided if the unit test for the method had test cases with exceptions and if I had checked if all the test cases ran successfully before deploying the code. And then I fixed the code and written the regression tests for it. That made me realize the importance of test-driven development. This incident taught me that it’s okay to make mistakes, it’s a part of learning process.
Writing good tests has many benefits. One of them is to make sure the code does what it should. Write unit tests for your functions. The tests should reveal their intention. I must say “Writing mature tests is an art.”
Excellent written and verbal communication skills
Communication skills represent nothing but the exchange of ideas, views, and information with others. Communication is the key to collaboration. If you want to make a point and you want to make it clear to everyone, you need to communicate effectively, especially in the context of technical discussions. You may be very sound and technically strong, but if you’re not able to explain your point to everyone, even your strength is not appreciated! Strong written communication is equally important as verbal communication as you’re supposed to communicate with others via Slack, email, GitHub issues conversations. Sometimes, you’re also supposed to write product specs and documentation.
TL; DR
The world of software development is moving from a code-first approach to an API-first approach as it helps to ship higher-quality applications faster by building APIs before writing code. Postman leads the way in the transition from code-first to API-first universe. I got an opportunity to intern and it was an enriching experience for me.
As I look back on my past six months, I cannot believe how much I have grown, technically and professionally. And finally, I got a chance to work as a full-time employee. Currently, I am working as a Software Engineer towards the mission of creating an API-First universe where if someone talks about APIs, he must talk about Postman. I feel blessed to work with a bunch of the smartest Software Engineers, learn from them and work to lead the way in API first Universe. And yes, I am no longer exhausted after spending 8 hours of my day sitting in one position. I must say I’m getting much better at writing code day by day.
The more I dive, I came to know that hitting an API endpoint and getting a response is just one feature, Postman has a lot many features.
Thank you so much for reading this. I am glad to share my incredible journey with you! I am even more excited about the next phase of my journey. If you’re an aspiring developer, never miss a chance to be part of it given an opportunity. And that’s me smiling at you, smile back to me:)
PS: Checkout 10 lessons I’ve learned as a Software Engineer at Postman
Say Hi on Twitter! ✋
Find me on GitHub.
Connect with me on LinkedIn.
