Software Engineering Internship at Grofers
source link: https://lambda.grofers.com/software-engineering-internship-at-grofers-bddd2dd1523e
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Software Engineering Internship at Grofers
Internships are a training ground for the professional “real world”.
What exactly does the “real world” entail? How disjoint is it from what we learn at university? Am I equipped enough to step into this simulation of the corporate world? I found myself asking these questions during my 8-week stint at Grofers.
Mine was a 2-month long journey with Grofers which came about by utter chance. I was applying for internships in my pre-final year and stumbled upon an opening for a full-time role, following which I reached out to the talent acquisition team for the possibility of an opening for a software engineering internship. One thing led to another and 3 interview rounds later, I received an offer to join the Technology team at Grofers, Gurugram.
Grofers is an online grocery platform with the largest market share in the sector and recently raised $220 million in funding from SoftBank and other investors. The inflexion point in this growth of the business can be credited to them moving from an express delivery service model to a full-fledged inventory based, supply chain model. Now, if this sounds like jargon to you, it basically means that they realised it was more important to their consumer diaspora that the product delivered be of the best quality at the cheapest of prices, rather than how quickly it was delivered (which came at the cost of quality, availability and price). This realisation transformed the business model of Grofers and lo and behold, they have reached break-even in Delhi and hope the same in a bunch of cities over the next couple of years.
The team behind the magic
The engineering teams are in Gurugram and Bangalore, with the Gurugram team handling the user journey up to the point of cart checkouts and payments on the app.
I was introduced to the entire engineering team on Day 1 and at the time the only thought that came to my head was ‘How can a team of such a humble size possibly manage a platform of such a large scale?’. Two floors with two large rooms each; too small a number for my expectation, probably because it was my first real foray into the industry and I was expecting a bigger team, or probably because the people were so dedicated toward the product and features they were building, that the size of the team was trumped by the drive of the team.
I was a part of the backend chapter in the technology team and was assigned to the Shopping Experience pod. I’ll explain what pods and chapters are here.
While scaling up the engineering team, initially it is enough to incorporate people with expertise in different technologies and platforms (Android, iOS, Web, Backend, Infrastructure, Design etc.). These areas of expertise are the chapters, namely Backend, Web, Cross-platform chapter and so forth. Now, as the size and scale of the company grow, so do the functions in the sense that now the team has to manage (say) two tracks in parallel, customer retention and customer acquisition. Both of these tracks ultimately further the product but have to be managed separately. For instance, customer retention may require a lot more personalisation and hence some kind of learning algorithm may have to be brought in the picture, targeted offers and promotions on recurring users may have to be tweaked, and so on; whereas for customer acquisition you might have to put in effort in design as well as technology to introduce some new, lucrative one-time offer and better interface for new customers. As consumer traffic and scale grows, these tracks can no longer be handled simultaneously by the same set of people and call for separate teams. Hence, pods are born. Notice how both tracks require frontend and backend skills?
A pod and chapter type of team alignment allow for the maximum number of such tracks in the team, to ensure dedicated attention to different aspects of a customer life-cycle while also ensuring there are engineers with diverse expertise onboard each track (read: pod). Hence, understandably, backend chapter might have 20 engineers spread across 6–7 pods, and similarly for all other chapters.
There are a number of pods at Grofers apart from Shopping Experience, including but not limited to Customer Acquisition, Customer Retention, Customer Journey Experience, UI/UX Research and Offline Stores team. These are just the pods I had the chance to interact with throughout my internship, there are plenty more.
Every pod consists of people according to the functions thereof, so I’ll talk about my pod, Shopping Experience. As the name suggests, it deals with all things marketplace. Product suggestions, search conversions, improving average order(monetary) values, search relevance, user-specific promotions & offers and constantly adding new features. The pod had backend, frontend and Android engineers along with a Data Analyst and a Product Manager working very closely with each other to come up with new and feasible ideas.
What stood out for me at Grofers and its teams is how closely the engineers worked with the product managers. Everyone cares about the product and thinks from a business standpoint rather than just writing software. The approach of a pod is to discuss a new feature/improvement in a current feature from a customer and business point of view and engage with the data and product people to fine-tune according to need and feasibility, followed by a discussion with engineers and finally coding it. This flow really takes the purpose of said feature home and allows for a broader vision, should the need arise to optimise/modify the current state, since extensive discussion ensure that software is written in a way that it can be scaled and morphed easily. It helps you see beyond just the code you write, to the purpose and impact of writing it.
The people, the place, the culture
I was assigned a buddy/mentor on the first day of my internship, a senior software engineer in the ShopEx pod, Aditya Bhardwaj. Thus began a journey of learning, setbacks, breakthroughs and an eventual realisation of what software development really is, the effort that goes into it, the dimensions you have to look out for, the scale, the complexity, the performance, the readability and how much I had to learn still.
There were daily scrums where the pod gathered and went around in sequence with every team member putting on the table what they achieved the previous day and what they plan to achieve that day.
The office follows an agile system with each pod having biweekly sprints, picking up stories according to their plans and bandwidth. Again, allow me to explain the jargons. A sprint is a 2-week time period within which a given amount of work has to be completed and produced for review by each pod. The stories are analogous to tasks, and bandwidth refers to the manpower in terms of engineer effort for a story. So, for instance, an engineer has 5 bandwidth points for every sprint and gets allotted 2 stories with 2 and 3 points respectively. This essentially means they’ll have to produce those two tasks in a span of 2 weeks, where ‘2’ & ‘3’ are effort points, implying that the two tasks are of moderate to high priority and require considerable effort (of 2 and 3) on a scale of 5.
There were demonstrations of each pod at the end of the sprint, which they had to present to rest of the technology team, consisting of a presentation about the impact and level of completion of the stories they picked in the said sprint, following which there was a ‘retro’ meeting of each pod wherein the team sat and discussed the good and bad parts of the ended sprint and the scopes of improvement for the next one. This entire process was recurring every alternate Friday.
What was personally exciting for me in all this, was that I was a part and parcel of all the above-mentioned team exercises. The notion of an intern there is not that of an auxiliary engineer but as an integral part of the team. I found myself sitting in the middle of those meetings, listening to people much smarter than me, understanding the vision of the product and giving inputs. Admittedly, being my first experience, I would often struggle to grasp the nuances in the beginning but the people and especially my mentor would make sure that I understood what was being talked about.
The scale of engineering at Grofers is phenomenal and in such an environment it is necessary for a compact tech team to have context about each other’s work and a broad idea about every pod’s developments in order to wrap their head around a common goal, for say, a quarter. This is where the people there go an extra mile to make sure that fellow engineers not only ask questions but get them answered as well, realising that while there is always expertise of some people in certain areas, it is always more productive if engineers have an overall threshold knowledge of various walks of software development. My take away from this approach to things, apart from the fact that algorithm design and object-oriented design are far from the only pre-requisites of software development, was that one should always try and concoct a solution to an issue they encounter and then try to brainstorm with the concerned party to yield the best possible approach to tackle it. It improves your productivity and problem-solving ability more than you realise.
Besides the biweekly sprint planning exercises and scrums, there were chapter meets every two weeks as well. The backend chapter meet used to be a very steep learning curve for me since all the senior developers used to sync up and discuss the new technologies they employed in their respective pods, their cost vs. opportunity and improvements over previous tools. The infrastructure and DevOps engineers used to convene with us as well, and because I had little prior experience with deployment services, I would always be taking notes and jotting down any terms and concepts I had no idea about. There even was hands-on for beginners to get their hands dirty with Kubernetes and other deployment services. Since the engineers at Grofers are from active developer communities, a lot of tech meet-ups and workshops were organised on the weekends for various technologies and they used to be super fun and informative.
Last but not least, random office gatherings and shenanigans were a highlight of my 2-month stint there. Lunch with the CTO, being greeted with doughnuts, vada pav and pizzas on late office days, India vs. New Zealand World Cup ODI, farewell cakes & lunches and quarter planning after-parties were a big part of the fun I had there.
What stayed with me
Technically speaking, I learnt a lot more than I had expected to, probably because I went into my internship not expecting much out of it, and it ended up being a pleasant surprise.
Code reviews were stringent there, which seemed futile in the beginning, since university projects have always taught us to do something, rather than doing something right. However, considering how a software engineer reads a whole lot more code in his career than writes it, readable and easy to debug code is of prime importance. I worked mostly on Python and picked up on a lot of intricacies about the language, the best practices and the need for efficient exception handling. When the code base goes well into tens of thousands of lines per microservice, it becomes extremely important that every method you write is unique, reusable, unit tested and documented, and leak-proof. You should make absolutely sure that you write test cases for anything new you add to validate the expected behaviour so that it becomes easy to track when someone modifies your code the odd way, or if you do the same. Best practices and writing tests with exception handling suddenly become significant in a platform with as massive a scale as Grofers, where tiny breaks in crucial code can hamper business in real-time.
I had the opportunity to learn about a lot of new stuff like ElasticSearch, a NoSQL database and an ideal search engine for text-based documents. Another very important aspect of software that I had the fortune of working on, was Design patterns. The importance and application of all those object-oriented concepts that we learn at university make sense and take form here when these OOP based patterns make life infinitely easy and software a lot more clean and scalable.
(I’ll be following up this article with more on ElasticSearch and Design Patterns, so stay tuned for those.)
A completely new aspect of a company for me, as an engineer, was the product that is offered. The alignment of the engineers with the product, writing code around that concept and designing algorithms and patterns to ship an improvement to it, was very intriguing. Quite honestly, this whole dynamic did get etched somewhere in my sensibilities.
If I could sum up my experience in a paragraph or less, I’d say that it was the best I could’ve asked for. I learnt a ton about the culture, the people, the product and the engineering behind an aggressively expanding company. I left there with some great experiences, great memories, great relationships and a great mentor.
I’d be lying if I said I didn’t want to just stay and continue there instead of coming back to college, on my last working day.
Aggregate valuable and interesting links.
Joyk means Joy of geeK