Checks the result
before trusting it.

Network Performance Dashboard

Problem

2Operate needed a reliable way to track telecom network performance across many sites, using time-series data, in a format the wider team could actually use day to day rather than something only a database query could answer.

Approach

Gathered requirements directly from the colleagues who'd use it, then built an interactive Power BI dashboard on top of SQL Server data: hourly and 10-minute granularity controls, state filters, and a power-vs-time view for spotting anomalies. Wrote the DAX and Power Query logic to keep the data accurate as new records landed daily.

Outcome

Delivered as a working tool for a specific stakeholder's operational monitoring needs, tracking user throughput through 2–3 KPIs with adjustable time granularity. Built and refined over about two months around a part-time schedule.

Code: repository pending

Inventory Management Database

Problem

An inventory system needed a database that stayed accurate and fast as it grew: a schema clean enough to hold up under joins across items, stores, buyers, and employees without slowing down.

Approach

Designed a fully normalized relational schema, populated it with structured test data (CSV and Mockaroo) under strict constraint validation, then wrote and tuned the SQL: queries, stored procedures, and indexes, using execution plans to find and fix the slow paths.

Outcome

↓ 98% query row scans after indexing and optimization, on a schema clean enough to serve as a real master-data structure rather than a working prototype.

Code: repository pending

GSRec: Hybrid Sequential Recommendation

Problem

Sequential recommendation models need to balance two signals: what a user is into right now, and how their taste has shifted over a longer history. Transformer-based models like SASRec are strong on the first; recurrent models like GRU are built for the second. The question was whether combining them in one pipeline would outperform using either alone.

Approach

Built GSRec: SASRec's self-attention runs first to capture short-term patterns, then feeds into a GRU to model longer-term dependencies. Implemented in Python with PyTorch, and benchmarked against four established baselines, POP, GRU4Rec, SASRec, and BERT4Rec, across two public datasets with different characteristics: Amazon Beauty (sparse, around 7.6 interactions per user) and MovieLens 1M (dense, around 165 interactions per user).

Results

Standard ranking metrics (HR@10, NDCG@5, NDCG@10, MRR) across both datasets:

Outcome

GSRec beat the naive popularity baseline and GRU4Rec on the sparse dataset, but didn't outperform SASRec or BERT4Rec outright on either one, and notably underperformed its own SASRec component on the dense dataset. The likely explanation: the GRU stage may be reprocessing a signal SASRec's attention layer had already refined, acting as a bottleneck rather than adding new information, particularly where recent behaviour is most predictive.

Code: repository pending