I'm an aspiring software engineer and a fourth year Computing student at Imperial College London.
I have a strong interest into Machine Learning and Distributed Systems, with a focus on back-end development. My main languages are Java and Python. As part of studies and interest, I have also experimented with C, C++, Haskell and Kotlin.
This personal website outlines some of my past and on-going projects and experiences over the last few years. My CV is linked below, but you can find more details on my work lower down.
Feel free to get in touch with me via email, or send me a message on LinkedIn!
Here are some helpful links:
The following are some of the recent projects I have worked on in relative detail, as well as links to other resources:
Please take a look at the repository below on GitHub, as well as the detailed report produced over the course of the project which includes: platform choice, system design, implementation details and both quantitative and qualitative evaluation of the results.
During my third year of university, we built a third-party automatic background replacement tool for video streams, agnostic of a specific streaming platform. Over the course of 8 weeks, in a group of 6, we used SCRUM engineering principles with a 2-week sprint time to build the project. This has involved researching papers and implementing some novel techniques to match the demands of live video.
Personally I had been working on data processing to look into a machine learning approach, as well as facilitating the communication and implementing features between our image matting pipeline and a graphical user interface.
I learnt a lot about working within a larger team throughout the project, including how to resolve conflicts and problem solve when hitting platform issues. One example of this was our choice of development language and platform was causing significant delays to implementing features and reaching our performance targets. Due to us being halfway through our timeline, there was valid pushback to us migrating to a new platform and language which would involve a complete redesign of our GUI and porting of the significant progress we had made in our background matting strategies. To resolve this, we met as a group and outlined the benefits and issues with both sticking to the current platform and with migrating to something new. Ultimately we reached a majority vote to move to the new platform, but was sure to consult with our stakeholder and project owner to get their view on our options. Ultimately the migration took significantly less time than our concerns had us believe, and it in fact yielded essential performance uplifts to the matting pipeline. Additionally, the new GUI could be built in a much-more extensible and modern format.
During my STEP Internship at Google, I was given 6 weeks to design, plan and develop an open-source project, fulfilling some basic requirements of being a web-based application, using some Google APIs, and something that aligned with one of Google's core values or OKRs.
Because of the remote-working situation we were currently in, I came up with the idea of creating a platform to be able to meet people 'randomly' like people otherwise would do around the office and in the canteens. There was a very basic system in-place for interns to meet with each other, but it was completely random and had no customisability or responsiveness, all being managed through some initial frequency preferences in a Google form. The idea was to expand this functionality to a web page which would allow you to submit 'chat requests' with some parameters such as: dates and times, topics and interests, length of time, group size and the ability to add more!
For this project I was working in a pair with another intern, so I set up and lead our daily standups to keep each other informed of progress and possible issues we were facing. Not being in person meant that these meetings became critical for our communication and coordination to complete the project. We also kept in touch with our hosts who served as secondary reviewers for our pull requests and helped to answer any questions we had.
We decided on React as a framework for the frontend due to its versatility and the speed at which we could develop new features within the time-constrained project. TypeScript felt like a sensible choice due to the added level of type safety we got while developing, which helped to diagnose bugs and issues quicker, especially when there isn't a continuous feedback loop of what interfaces were being used by each other while we were integrating our features with each other's work. Before the project, I had worked on a small portfolio project to familiarise myself with using Google Cloud Platform and how to deploy applications using Google App Engine, so it made sense to use something similar on the backend, Java was also fairly effective and helping us to keep interactions modular and simple to comprehend.
For the project, I worked on the full-stack of the platform, integrating frontend and backend for features that I was responsible for. I worked on the core functionality of the project, namely the submission of chat requests by users, and the matching and scheduling of requests. The chat requests required some additional functionality than that of a simple HTML form, such as autocomplete for interest-tags (based off of user-generated tags), intuitive date-time selection (taking into account timezones), as well as providing a simple and more responsive interface for users to use over a simple form. In addition, I also set up the authentication of users to ensure that requests were attached to the correct users, and that users were signed in. This was done via integration with Google's OAuth 2.0 servers that deploying with Google App Engine allowed us to interface with.
Some of the main complexity of this project was implementing a matching algorithm efficiently, that was run periodically, and was suitable for a scale of ~200,000 users. Some of the key motivations of the project was the ability for users to customise additional parameters such as group sizes and availability, so this created a more algorithmically complex problem than just a simple bipartite matching algorithm. In fact, matching algorithms in general graphs is already a complex algorithmic problem, however the added complexity of variable group sizes would likely cause any 'ideal' matching strategy to become NP-hard. After much research into algorithms such as Edmond's 'Blossom' algorithm, I opted to implement an iterative approach which ranked the importance of parameters, performing pre-processing and calculations where possible to reduce time complexity.
Unfortunately, by request of the university for plaigarism purposes, the repository cannot be public. If you are interested in viewing the repository, please don't hesitate to contact me!
Below are the reports generated by our group on the implementation after the emulator (initial checkpoint) and the final report, including the extension:
Given a Raspberry-Pi which was based off of the same ARM architecture, we were first tasked as a group of 4 to create an emulator that could execute the instructions given in the format of a binary file which covered the whole range of processing, data-transferring, and branching instructions. The program utilised a multi-stage pipeline operating on an anonymous union of structs (representing the current instruction). Thus the instructions had to be initially parsed, and then executed according to flags and register shifts.
The assembler used a similar format to represent each instruction and operated using a multi-pass method as to be able to calculate memory locations. The hardest task was being able to parse the given strings of assembly instructions and tokenise them, in order to parse them correctly to the correct binary representation (making sure to also set the correct flags and register calculations).
For the extension we quickly created a simple game of Connect-Four. We then added in functionality to display the game on a custom PCB and hand-made LED-matrix. I also decided to implement a "Computer" to play against, and decided to use the Monte Carlo Search Tree algorithm in order to traverse the current decision space for each move the computer made. Once implemented, even at just 10,000 iterations, it remained unbeatable.
All of the tasks ran on the Raspberry-Pi and so we made sure to optimise for speed and heavily reduce memory usage. With manual data-allocation and freeing, we were able to reduce our memory usage significantly, as well as by making use of data structures such as anonymised unions rather than having several unused struct members.
Inspired by the confusing number of tasks and assignments we were face during our time at school and university, decided to create an aid to help schedule time to complete those tasks, keep reminders on upcoming assessments, as well as serve as a platform to discuss those assignments.
Messaging would work in threads, similar to the structure built into Slack, and would allow messages to contain text content or for a file to be uploaded and sent. Each assignment and/or module would contain its own channel for sake of organising chats and streamlining the process of effectively spreading and receiving information relating to a certain assignment. This would be more effective than questions being lost in random conversation of large, generic group chats.
I was familiar with Android Studio, and so built the user-facing UI and also handled the parsing of data from JSON to usable data, that would be sent to and recieved from the server.
The server was able to store users and link them to certain channels, threads and messages. It also handled creation and authentication of users.
Unfortunately, despite both front and back-end having working data-parsing functionality, the app was unable to connect to the endpoint given the methods we had tried in the time constraints.
If you would like to see the project's stages and corresponding docuemnts, see the link below:
Project developed as part of my Computer Science A-Level, during which I had lea rnt to work with Python. With my idea for the project I decided to take it upon myself to learn a new language to work with as researching graphical interfaces with Python yielded not many simple solutions to migrate to a mobile platform.
Thus after market research and analysis of implementation options, I had three main possibilities: iOS application using Swift, Android application using Java, a web-based application. Due to unfamiliarity with web-based platforms at the time, and no permanent developer access to an Apple ™ device, I decided to use Android Studio and learn how to develop with Java. Additionally, it gave me the opportunity to work with a more traditional object-orientated programming language.
I made extensive use of the Android documentation and some third-party libraries for tasks such as visualising graphs. Furthermore, I self-taught myself the structure and concepts of databases, including how to create, manage and query a database stored on-device on Android with SQLite.
Once the project was complete, I wrote an extensive documentation docuemnt on each section of the code, detailing the function of each class, method, or code snippets. Lastly, I wrote an evaluation report outlining constructive criticism of my own work, shortcomings and possible improvements and future features.
If you would like to see the final document, see the link below:
After being introduced to the concept of Machine Learning and biologically-influenced computational techniques, I immediately took an interest into the topic and formalised it through this project.
I conducted some initial research by watching lectures from university courses such as MIT, as well as conferences displaying bleeding edge technology such as Google Cloud. With a basic understanding and equipped with the sorts of concepts and fundamentals that exist, I then began formally researching them through videos, news stories, as well as projects and implementations of the technology.
Neural Networks took a particular interest to me during my research. I learnt their fundamentals and mathematical operations (activation and loss functions), as well as the processes when dealing with a whole network such as backpropagation during training. While looking at newly introduced technologies, I also learnt about a variety of the issues that are faced when implementing Neural Networks - overfitting, class-variability, vanishing gradient.
Taking the understanding I had accumulated, I started to look at some practical work, building a simple classifier with the MNIST data set, as well as looking at how more complex solutions were structured and developed.
One of the most interesting demonstrations I looked at was a 3-layer Recurrent Neural Network, that was being fed the plays of William Shakespeare. And then once trained, it was able to generate new scripts for any given length. It was able to not only correctly format for a script with stage directions, but also generate new character names with the correct capitalisations and emphasis. When I displayed this running in real time at my presentation, it struck people with a real glimpse into what the technology is possible of.
During the Summer of 2020, I was a STEP Intern at Google attached to an SRE team based in Dublin. I spent my time between trainings and software engineering projects, all while gaining exposure to the working environment of being a developer within a large technology company.
I spent the majority of my time on an 6-week open-source software engineering project alongside a partner, whilst adhering to the strict testng and code cleanliness methodologies enforced by our hosts and each other during code reviews.
The project was self-lead and involved designing the platform from the ground up including writing and continuously updating a central design document to outline design decisions and system architecture. This also provided a 'single source of truth' for the platform to be built from so that development would stay in-line with the designs we had planned. It also provided an opportunity to discuss and review design suggestions and ideas before their implementation so that decisions could be well-informed and take on the insight from a variety of perspectives.
I was able to learn a great deal working within a larger team of engineers, attending team meetings and daily standups, as well as coordinating progress with my peers. This is especially true when it came to actual development techniques and best practices that I have been able to take with me onto future work and projects I have been working on at university since: design and discussion continuously during and before development, writing code to a high-quality standard for seamless integration of features with other people's work (making use of testing and CI), as well as reviewing code on a regular basis to ensure knowledge is shared on the inner workings of features amongst the team.
The experience I was able to gain during my internship was truly valuable and has better prepared me for my future as an engineer in the real world.
At Fire Tech, I was one of a handful of tutors running a summer courses in Cambridge with a focus on technology and coding. Together we managed around 25-40 children each week, ageing from 8-17 years old.
My role involved the general running of the camp each day, as well as delivering and preparing course content to groups of size from 3-16.
The courses I taught included:
Alongside my A-Level studies, I tutored in Mathematics and English from a 7 year-old level to A-Level Mathematics and GCSE English.
Each student was at a different skill-level, thus requiring me to personalise the curriculum to each student's ability and weaknesses. Additionally, I had to report and give feedback to parents and lead teachers, providing effective and actionable advice for the child to improve.
In addition to the teaching, I also had the responsibility to set the lesson plans, mark past work and assessments, and handle sensitive information on each child with confidentiality.
During my first year of A-Levels, I was introduced to the Young Scientists Journal: A science journal researched, written and edited by 12-20 year olds. A fellow classmate and I decided to get in touch with the YSJ and organised our own 'hub' to create a termly Leicester Grammar School edition of the YSJ.
Once the organisation was complete, we presented to the school, advertised and spread the word about needing writers, editors and any interested parties. Amassing a sizable group of young, enthusiastic members with both STEM and non-STEM interests, we created a heirachy of roles and pipeline of writing, editing and publishing to release a copy at the end of each academic term.
This involved organising several groups and individuals on different tasks, and actively seeking out reports and updates on the process, to keep in line with an agreed production timeline with the school.
To further interest and exposure to the outside world, my co-leader and I presented at the Big Bang Fair, hosting STEM-related activites, companies and opportunities to 1500+ visitors from across the Midlands. We had a booth explaining the project, and the organisation as a whole. This garnered interest within the school and spread to other instituions by talking to teachers and students from a variety of areas and backgrounds.
Even after passing on the baton to the year below once we had left the school, the production of the school's edition of the Young Scientists Journal continues to this day, and is still featured as a prominent part of the school on its website.
Even after passing on the baton to the year below once we had left the school, the production of the school's edition of the Young Scientists Journal continues to this day, and is still featured as a prominent part of the school on its website.
YSJ Issues
