Open to software engineering roles
I like building useful software, understanding how systems work beneath the surface, and solving the problems that show up when ideas meet the real world.
Software Engineering with Co-op · GPA 3.86
Scroll and the line draws itself.
McMaster University · Hamilton, ON
BMO Capital Markets · Toronto, ON
BMO Capital Markets · Toronto, ON
McMaster University · Hamilton, ON
TecCentric · Remote
LaTeX lives in Git, but a pull request only shows you the source. Swap github.com for texprs.com in any PR link and you get the compiled PDF before and after, side by side, overlaid, or with every change marked up. No cloning, no checking out branches.
Same path as GitHub, so replacing github.com with texprs.com opens the pull request's PDFs. Nothing to install, nothing to check out.
latexdiff markup, the two versions side by side, the new one alone, and an overlay that fades out everything that did not change.
Every job runs as its own unprivileged user with shell escape off, checked by thirteen tests in CI, malicious documents included.
Tested on my capstone team's pull requests, which is what found the two bugs that mattered most.
A marketplace for McMaster students, built with four friends and live at macmarketplace.ca. Sign-up is gated to @mcmaster.ca addresses, listings are searchable the moment they are posted, and buyers and sellers talk inside the app.
400+ users and 70 listings, without a marketing budget behind it.
Algolia indexed against Firestore, synced live so results never lag behind the data.
Deployed to a managed instance group of Compute Engine VMs that autoscales horizontally.
Owned the roadmap, split the work across Ahmad Allabadi, Moustafa Moustafa, Ahmed Yassin and Laith Nasrallah, and made the system design calls.
In production
400+ active users
People give advice, warnings, sympathy and stories in nearly identical language. This benchmarks four NLP architectures on telling those five intents apart — I owned the BiLSTM.
Frozen Flair contextual embeddings, concat-pooling, class-weighted loss.
2,000 comments scraped from four subreddits, annotated under a label-priority protocol.
Cohen's Kappa of 0.534 across double-annotated instances.
Out-scored a BERT-base baseline on the held-out test set.
Built with my team at McMaster, SongSnap is a cross-platform mobile app designed to identify the song stuck in your head from whatever you remember: an audio clip, a lyric fragment, or a natural-language description.
Lyric, audio and description analysers share one problem space and converge on a single result.
Repository pattern and MVC keep business logic, data access and API endpoints independent.
Reworked the FastAPI layer to stream data through rather than buffer it whole.
Pydantic validation on every boundary, Google OAuth2 handling auth.
Recycling rules change from city to city, so people guess and bins get contaminated. Photograph an item and this tells you whether it's recyclable where you actually live.
Gemini identifies the object, then it's checked against that city's rules — not a generic guess.
Cross-references municipal recycling guidelines rather than one national standard.
Prompt engineering in Google AI Studio to cut misidentifications.
Scoped to the core flow and shipped it inside the hackathon window.
Google Developer Groups
6th place at Macathon 2025
A Java maze-solving engine that parses text mazes, models them as a graph, and escapes them three different ways — breadth-first search, Trémaux, and the right-hand rule — printing the route as a factorized instruction string.
A builder walks the maze from the entrance and turns it into nodes and edges, where each edge carries the moves that traverse it — so search returns instructions, not coordinates.
BFS, Trémaux and the right-hand rule all implement the same solver interface, with an adapter letting graph traversals stand in as solvers. Adding a fourth means adding a class.
Paths collapse runs of identical moves, so forty steps forward prints as 40F rather than forty characters — and the same parser expands it back to validate a path.
JUnit covers the parser, the path forms, the graph builder and each solver independently of the CLI that drives them.
A Java exploration command center for the Island serious game, built with two teammates. It talks to the game engine, interprets what the drone observes, keeps its own picture of where it has been, and decides where to fly next across an unknown island, reporting the creek closest to the emergency site when the search is done.
FindLand crosses open water until it makes landfall, then GridSearch sweeps the island. Both implement the same DecisionMaker interface, each driven by its own state machine.
The engine never says where the drone is, so VirtualCoordinateMap tracks position and heading from the moves alone, including the diagonal step a turn actually costs.
Every echo, scan and flight costs battery. The drone watches its remaining budget and turns for home before the engine strands it.
Twelve JUnit suites cover the translator, the compass, the coordinate map, the battery and both strategies independently of the engine.
I’ve been curious about technology for as long as I can remember. Before I knew what software engineering was, I was already wondering what was happening behind the screen, how a browser knew where to take me, how an app responded the instant I touched something, how computers on opposite sides of the world could talk to each other through the internet. I didn’t have the vocabulary for any of it yet. I just knew I wanted to understand how it worked.
I grew up in Halifax, Nova Scotia, until I was eight, when my family moved to Qatar. I finished school there before coming back to Canada on my own for university at McMaster in Hamilton. By then, I finally had names for the things I had spent years being curious about, and when it came time to choose an engineering stream, software was the one I kept coming back to.
There was something different about it. With most kinds of engineering, building something meaningful seemed to require equipment, materials, labs, or factories. With software, I could sit down with a laptop, what I knew, what I was willing to learn, and probably a few dozen Google searches, and build something that could eventually end up in somebody else’s hands. A website. An app. A system running somewhere in the background. The distance between an idea and something real felt unusually short, and that fascinated me.
My timing also made learning software engineering a little strange in the best possible way. I started university just as generative AI was becoming mainstream. ChatGPT appeared near the beginning of my degree, and while we were learning data structures, algorithms, databases, operating systems, architecture, and all the fundamentals software engineers have traditionally learned, AI was improving beside us at an almost ridiculous pace.
Every year, the tools changed. Then the conversations changed. Eventually the curriculum started changing too. Courses began incorporating AI, new AI focused classes appeared, and the question slowly shifted from “Can these models actually write useful software?” to “What does it mean to learn software engineering when they can?”
Getting to watch that transition happen while I was still learning the fundamentals has shaped how I think about the field. Sometimes I think my cohort sits in an unusual middle ground. We were early enough that our education was still built heavily around understanding how software works from the bottom up, but late enough that AI was part of our engineering lives almost from the beginning.
And I’m grateful for that.
Because the thing I value most about my education isn’t knowing a particular framework, language, or tool. Those change constantly. It’s having enough of the fundamentals to pick up the next one quickly.
I’m not going to pretend I’m the person who knows the most in every room. I probably won’t be. What I trust about myself is that I can learn. Give me a system I haven’t seen before, a codebase I don’t understand yet, or a problem that sits outside what I already know, and I’m comfortable starting from “I don’t know” and working my way toward understanding it.
That is why I value the fundamentals so much. Languages change. Frameworks come and go. The way we build software will keep evolving. But understanding how systems fit together, how data moves, how abstractions work, and how to break an unfamiliar problem into smaller ones gives you something much more durable. It gives you the ability to adapt.
I think that is also why I am comfortable with how quickly the field is changing. I do not expect the tools I use today to be the tools I use ten years from now. I expect to keep learning new ones.
The tools will change. AI will probably make them change even faster. What I want to carry with me is the ability to understand what is underneath them, learn what comes next, and use it to build something useful.
I got into software because I wanted to understand how technology worked. I stayed because once you understand enough of the pieces, you can start putting them together yourself.
That is still the part I enjoy most.
