What to expect from this page?

Hi, before you evaluate, here's what this page is about.
Its purpose is to build trust and remove doubts from a technical perspective, and to give you insight into how I actually think when I'm handed a new problem.

How is the above expectation fulfilled?

To fulfill the expectation, the content of this page is presented in a way that resolves the underlying doubt: "will this guy be able to tackle a real world problem he has never seen before?".

A knowledge quiz wouldn't work here, questions like "what is encapsulation?" or "when would you use a t-test over a z-test?" can't capture real thinking, and a resume line like "I know Data Science" proves even less, since without a real test, anyone can claim anything.

So instead, this page uses the work I have already done as proof, and walks through my actual thought process when I'm handed a new problem with an example. AI has made syntax cheap. The way we write code today can be replaced. Clear, innovative thinking can't.

What follows should give you enough to decide whether I'm worth a technical interview, one where you can see how deeply I actually understand the stacks I've worked with, and whether I'd be a good technical fit for your team.

How I approach a new problem

Over the course of history, humans have solved problems using two primary techniques: by reasoning with their own minds or by using past knowledge.

I believe in a hybrid approach to solving problems. Past knowledge on its own never teaches you anything, it only gives you results until you face a problem it cannot cover. Relying purely on raw instinct, on the other hand, wastes time on problems someone has already solved. I use past knowledge to understand a problem faster, and my own reasoning to actually solve it.

In practice, this usually plays out in eight steps where the core idea is to understand the problem at a fundamental level, regardless of whether the problem is a coding question, a model, a system design question, or something I have never seen before.

  1. 01

    Understanding what is actually being asked

    Knowing the real business question behind a metric before picking a model.

  2. 02

    Defining what needs to be done

    Clarifying whether the goal is improving accuracy, reducing latency, or something else entirely.

  3. 03

    Understanding the problem from first principles

    Reading relevant articles, papers, or documentation before assuming an approach.

  4. 04

    Sketching a rough idea of the solution

    Identifying the underlying pattern behind the problem.

  5. 05

    Establishing a baseline

    Writing code to pass a sample test case, or training a simple linear model first.

  6. 06

    Iterating with justification

    Reasoning about what to try next and understanding the tradeoffs of each change.

  7. 07

    Validating

    Checking against edge cases, or observing performance on a real test set.

  8. 08

    Putting it into practice

    Shipping the code or the model in production.

What you can expect from working with me

Adaptability

I pick up unfamiliar stacks fast.

This site is proof. I did not know Next.js, TypeScript, or Tailwind a few weeks ago. It is built, deployed, and you are looking at it right now.

Honesty

I am upfront about how I work, including the tools I use.

I used AI as a tool while building this site, the same way I would use a Stack Overflow or documentation. Every architectural decision, every line of content, and every design choice on this site is one I made and can defend.

Pragmatism

I use whatever is the right tool, not the popular one.

On a retail demand forecasting pipeline, a Random Forest model beat complex neural networks like LSTM and GRU by 60% on time series data. I documented that without hesitation.

Curiosity

I do not stop at what works. I want to know why.

When Random Forest outperformed LSTM, a model known for handling sequential data well, I analysed the data itself and found it held no long-term dependency for LSTM to exploit. Model selection should be driven by the nature of the data, not by a model's reputation in a given domain. That reputation is a reason to test a model, it is not a reason to skip testing the others.

First-principles thinking

I try to understand the concept underneath the technique.

A paper encoded time using sine and cosine transformations for a train delay model. Instead of copying it, I worked out why: a clock is not a straight number line. On a number line, 6 is closer to 2 than 11 is. On a clock, 11 is closer to 2 than 6 is, because of its cyclical nature.

Accountability

I take full responsibility for my mistakes and fix them.

On a train delay prediction model, naive outlier removal looked reasonable but increased error by 129%. I caught it, reported it plainly, reassessed the preprocessing strategy, and rebuilt it properly.

Problem solving

I bring solutions, not just effort.

I ranked 1st and 2nd in two machine learning challenges during my master's at the University of Nottingham, and finished runner-up at a C programming bootcamp during my bachelor's.

Maturity

You can trust me with your codebase

Every experiment I run is tracked, not just remembered. On the demand forecasting and bankruptcy projects, every model, parameter, and metric was logged through MLflow before anything was called final, so a change that helps or hurts is provable, not a guess. Deployments run through Docker and CI/CD rather than manual pushes, so what gets tested is exactly what gets shipped. Small changes get committed to GitHub and reviewed step by step, not bundled into one large, unreviewable difference.

Case studies

Wanna explore more of my work?

Click here

Want to look at the actual code?

View my GitHub repo

Note: Curious about my formal qualifications, achievements, the full technical stack I have worked with, or the type of roles I am targeting?

Find that on the About page.

What I am building / learning right now

A real-time e-commerce analytics and recommendation engine. Kafka for event streaming, Spark Structured Streaming for real-time aggregation, Snowflake and dbt for the warehouse, Airflow for orchestration, Redis and FastAPI for serving, Prometheus and Grafana for observability. My other projects prove I can build and evaluate models. This one is about proving I can operate a full data platform end to end, the kind of system a data engineering or ML platform team actually runs in production.

Alongside that, I am picking up JavaScript for backend development, and low-level design (LLD) is next on the list.

In progress

Didn't get your question answered?

If something here did not add up, or you have a technical question I haven't covered then

here's how to reach me →