Journal: Job screening, portfolio shipped, LeetCode unblocked, hexagonal arch explored

This article is part of my journal. Read more

Morning — Woke Up Late, First Screening Done

Started the day a bit slow — had a headache, woke up late. Despite that, I had my first screening interview with Progressive Lab Company, one of the companies I recently applied to. They asked around four or five questions. The first one was just introducing myself, which is always straightforward. The rest of the questions were mostly centered around AI — what my opinions are, and how AI is currently impacting software development. I gave my thoughts and that was it.

Building My Portfolio Site

After the interview, I remembered I still hadn't built my personal website. So I started brainstorming.

My idea was simple: a minimal single-page, single-screen website that just reflects who I am and what I do. Nothing bloated. Just my name, my job title, and links — GitHub, LinkedIn, Instagram, my blog, and my resume URL. That's it. And something to make it feel alive, like a 3D animation or an aesthetic theme.

I didn't want to build the whole thing from scratch, so I started brainstorming with Claude AI. I shared my idea, got a few theme suggestions back, and eventually landed on a space like theme. I liked it. Felt right.

From there, I gave Claude my latest resume and it helped me pull together the portfolio site. Once I was happy with it, I deployed it and connected my own domain. The site is live now.

I still feel like it could use something more — maybe an interactive 3D animation, like a rotating globe with my tech stack on it, or something you can play with using the mouse. But for now, it's minimal, it's live, and I'm mostly satisfied with where it is.

Later — LeetCode #11: Container With Most Water (Medium)

Switched gears and picked up LeetCode problem #11 — Container With Most Water.

The problem gives you an array of integers where each value represents the height of a vertical line. You need to find two lines that, together with the x-axis, form a container that can hold the most water. Return that maximum amount.

My initial thinking: use the two-pointer pattern. Start with one pointer at the left and one at the right, loop while left is less than right, find the minimum height between the two, multiply it by the distance between the indices, and track the maximum.

The part I got stuck on was: after calculating the area, which index do I move? If I move both at once, I might skip a combination that gives the maximum water. For example, if I jump from index 0 to index 1 on both sides simultaneously, I might miss the best pair being index 0 and index 4.

After stepping back and thinking it through (had to revisit my earlier notes), the logic clicked: compare the two heights and increment the index of the smaller one. If the right height is greater, increment the left index. The reasoning is that since the smaller height is the limiting factor, there's no point keeping it — moving it gives us the only chance at finding something better.

function maxArea(height: number[]): number {
    let left = 0
    let right = height.length - 1
    let max = 0
    while (left <= right) {
        const min = Math.min(height[left], height[right])
        const distance = right - left
        max = Math.max(max, distance * min)
        if (height[left] > height[right]) right--
        else left++
    }
    return max
};

Once I implemented that final piece of logic, all the test cases passed. Felt good.

Reading About Hexagonal Architecture

I went through a Medium article about why senior developers prefer hexagonal architecture over the traditional layered architecture. It turned into a pretty solid reading session.

Layered architecture is what most people are familiar with — and honestly what I've been using in most of the project with NestJS. You've got your controllers, your service files with the business logic, and your repository files for data access. Clean enough, but it has a real problem: tight coupling between layers. If something changes in the controller or service or data access layer, the ripple effect can spread through the whole thing.

Hexagonal architecture (also called ports and adapters) handles this differently. The core domain logic sits in the middle and almost never changes. Around it are ports — think of these as interfaces in TypeScript. And then you have adapters that implement those interfaces. Your repository file is an adapter. Your REST API controller is an adapter on the other side.

So if your database changes, or you switch to a different third-party API, you just update the adapter. The core logic stays untouched. The article called this preserving the blast radius — changes in one place don't cascade everywhere else.

The article made a good point about when this architecture shines. In something like banking, the core business logic almost never changes. But the technology around it keeps evolving. Hexagonal architecture is a natural fit there.

Netflix came up as another example. Their UI is constantly shifting — smart TVs, mobile, web, different devices. Their database infrastructure also changes. But the core of what Netflix does — stream content — stays the same. Hexagonal architecture lets the outer layers change freely while the middle holds steady.

Translating this into NestJS terms: the use case files act like the service layer, the adapters map to repository and utility files, and the controllers serve as the REST API-facing adapters.

It was a good read. Not switching everything over tomorrow, but it's the kind of pattern worth keeping in mind as projects grow.

---

That was the day. Interview done, portfolio live, LeetCode solved, architecture concepts absorbed.