Reflections on My Fourth SWE Internship at GovTech Singapore as a Final Year Computer Science Undergraduate at NUS
A multipart series where I reflect on my university opportunities- Final Year Summer @ Government Technology Agency (GovTech), Singapore
Author’s Note: About two months ago, during a conversation with my mentor from my internship at the Government Technology Agency (GovTech), I was inspired to reflect on my various internship experiences. I believe this reflection could be valuable in helping me clarify what I want for my future and serve as a great way to document what I’ve learned from each experience.
And so begins this multipart series! I hope to go beyond just sharing my internship experiences and dive into other university and pre-university experiences as well.
Context
I joined GovTech during the summer of my third year as a Computer Science undergraduate at NUS and interned with them during my first semester of my final year as well. In fact, it has been just over a week since my last day in the office!
As mentioned in my post on my second internship, I was unprepared when I was applying for internships for my Year 2 summer. After that summer, I became more proactive in my internship hunt, starting applications early, practicing LeetCode, and brushing up my portfolio. The hard work paid off (or maybe it’s simply because I was considered a penultimate student), as I received a lot more OAs and interview opportunities. Unfortunately, I fumbled a few great companies, and was disappointed that I couldn’t secure my internship before the end of 2023.
For my Year 3 summer internship, I restricted myself to applying only to larger organizations. Having had my past three internships in startup settings, I gained valuable exposure; however, I wanted to experience what it was like to work in a big organization and see if I enjoyed it there before graduation. Fortunately, I had another window in February-March 2024 to secure another internship and set my sights on GovTech.
GovTech is an organization where I always wanted to intern and had tried applying for both Y2 Summer and Y3 Semester 2 (before I received the news that I was going for exchange), but I was unsuccessful in both cases. I think GovTech has grown in popularity in recent years, especially after the intern pay increment back in 2022, which made its intern pay competitive even among some of the bigger MNCs. It’s also one of the few government agencies known for its “leaner,” “younger” tech environment, unlike the traditional government boards.
GovTech has many different divisions, and the division I was in is a newly formed division called Government Anti-Scam Product (GASP). This division primarily develops products to combat scams in Singapore, and I was assigned to a team called SATIS, which is a platform that supports the Singapore Police Force (SPF) in combating scam websites and protecting citizens from scammers.
What Did I learn?
My projects at GovTech were sensitive since they dealt with scammers, so I won’t delve into the specific functionality of these projects. Instead, I’ll focus on the technical knowledge I gained during my time there!
OAuth and Authentication Flow
One of the major things I learned was more about authentication flow for OAuth (specifically OAuth 2.0 and how to securely use OAuth alongside OIDC (an extension of OAuth2.0) for both authentication and authorization. In an organization, users often already have an identity account with a provider like the Microsoft Identity Platform or Google. If we are building an application meant for users in this organization, instead of creating a username and password to handle the login process, we can integrate with these identity providers to authenticate the user. After authentication, we can either create a session (e.g., for web apps) or issue tokens (e.g., JSON tokens) to maintain authentication and authorization for subsequent interactions.
There are many different ways to obtain the relevant tokens (access or ID), and certain methods are more secure than others. In the end, I looked into and implemented the Authorization Code Flow, as it is the most secure flow when used with PKCE. The Authorization Code Flow can be roughly broken down into two steps: the first step is obtaining the authorization code when the user logs in to their identity provider and authorizes the application to request tokens (e.g., access token, ID token) or user information. The second step is exchanging the authorization code for the tokens. The authorization code can be intercepted, especially in Single Page Applications (SPAs) where it is exposed in the browser URL. To mitigate this risk, I read up on and implemented PKCE (Proof Key for Code Exchange), which adds an additional layer of security by ensuring that the authorization code can only be exchanged by the legitimate client. Additionally, the use of a client secret or certificate for confidential clients further secures the token exchange process. This was interesting knowledge for me, as I often take login matters for granted when working on school projects or simple prototypes.
An Extension of Infrastructure as Code (IAC)
During my internship with Novatech, I got a glimpse into IAC and saw how useful it is for setting up systems in the cloud by expressing the setup with code. At GovTech, I saw it in action with Terraform and the Serverless Framework. It was pretty cool to see the code create all the necessary services on AWS when deploying them. This approach provides a way to better track changes and version control instead of relying on instructions like “click this, then this, and then this.”
I had the opportunity to perform some minor configurations, such as using it to store secrets in AWS Secrets Manager and retrieving them to load into the application as environment variables during deployment, and also got the chance to set up some basic AWS services using Serverless Framework during our division’s internal hackathon.
Working with AWS Lambda and Data Processing
I had previously worked with AWS Lambda during my time at Novatech, but that involved simpler operations like CRUD with our database. At GovTech, I had the chance to work more extensively with Lambda and experience some of its limitations.
One of my tasks involved using AWS Lambda to process a relatively large chunk of data in Parquet format. To handle this, I used PyArrow and Pandas. However, these packages were too large for Lambda’s layer size limit of 250 MB. As a result, we switched to Docker, which allows Lambda functions to utilize up to 10 GB. I also experimented with using S3 Select instead of PyArrow and Pandas, but I realized that 1) it was slowly being phased out, and 2) the response didn’t guarantee that a record would be self-contained in one record frame, as it returns data in a byte array that may contain partial or multiple result records.
Additionally, as we were retrieving the data from another S3 bucket, there was significant I/O involved. The boto3 client we used was synchronous, and AWS Lambda had a timeout limit. While the maximum timeout of 900 seconds was sufficient in most cases, it could be optimized by reducing the time taken for I/O. To address this, I implemented some simple multithreading to improve the I/O process, which sped up the overall processing time.
This was an interesting task as it allowed me to explore simple optimization techniques and work with “big” data.
How is a BIG Organization different from a Startup
Of course, the most obvious difference is the size. In a big organization like GovTech, there are many teams working on different projects concurrently, and you may go through your entire internship without interacting with most of them. In a startup, most teams (be it marketing or sales) are within arm’s reach. At GovTech, there were instances where I needed to collaborate with another team, which added to the overhead as things moved slightly slower. Furthermore, there are more regulations and policies (rightfully so), with other teams checking each other for things like security, which adds to the overhead.
Big organizations also have more comprehensive metrics and systems for teams to follow. In a startup, the main metric is often revenue or user growth, and systems are much more flexible since employees may need to work on different things at different points in time and can’t solely stick to a specific task. In a big organization, with enough people, systems work well because they are great when each employee has a clear set of responsibilities. If people stick to their responsibilities and complete them, the system runs smoothly.
And then there’s capacity. This was my first internship where I was greeted with a big lobby, large pantries, multiple floors, and many offices. The organization carries more weight and is able to do more, such as hosting events for interns or mentor-intern programs, which I thought were awesome! You feel more noticed outside of work as you’re working for a recognizable establishment. However, you feel less noticed inside of work due to the sheer size of the company.
That said, capacity is a double-edged sword. With greater capacity, there’s a risk of overcapacity, where resources are underutilized. In a startup, every resource is maximized, and efforts are made to save as much as possible. During my time at GovTech, I noticed a slight difference — costs/resources were less prioritized if they fell within budget. In fact, sometimes I felt they didn’t need as many interns, and internships seemed more like a headcount issue so that HR could justify similar numbers for the next intake.
My division was kind of cool — more startup-ish, as they were a newly formed team. Hence, it lacked some of the structure that more established teams might have, though most structures were still present. They also held an internal hackathon, which I thought was pretty cool since it’s a great way to generate “public good” ideas. I also got to interact more with colleagues from other teams during this hackathon, which made it more enjoyable, as the division is relatively large, and you don’t often get the chance to know everyone.
Overview: Looking beyond Graduation
My time at GovTech has definitely been meaningful and rewarding. I think my biggest takeaway was learning how a big organization, especially a government agency, operates. This gave me a better understanding of the types of organizations I am considering joining post-graduation. Although I wished my internship had been slightly more challenging with a more focused program and structure, I am still appreciative of this opportunity.
Working at GovTech is definitely meaningful, as the organization uses tech for public good. GovTech works on many impactful projects, and my division, Anti-Scam, addresses an issue that is becoming increasingly important. Finding meaning in your work is crucial, especially for sustaining a long-term career in a particular environment.
As this is most likely my last internship, it has also made me think about what I really want to do after graduation, which is my next big milestone. I am considering moving into areas that are more backend-focused, such as low latency systems or distributed systems, rather than continuing with web development, which has been the primary focus of my internships so far. These are new possibilities to explore!
Conclusion
I ended my internship on the first of November, completing a five-and-a-half-month internship that started in May. As mentioned earlier, I am grateful for this opportunity, which allowed me to meet new people and make new friends. Definitely going to miss the office view!
This marks (most probably) the end of my four internships as a Computer Science undergraduate at NUS. As I was writing this, I realized I missed out on a couple of experiences that might be worth mentioning (such as volunteering and being a teaching assistant). I hope to include them in the future before doing a final wrap-up of the things I’ve learned through this multi-part series on internships.
Thank you for reading!
