I started GitHub Copilot Beginner to Pro - AI for Coding & Development Udemy course and wanted to learn agentic coding. By following the course, I added custom agents and prompts to the GitHub Copilot setup inside the profiler. Basically treating Copilot like a proper agentic coding partner for the first time.

The first prompt was simple:

create a /dashboard page, no real content yet, just a placeholder.

Then I layered in the standards — a follow-up prompt told it to make sure the dashboard page follows the authentication coding standard. What surprised me was that the agent actually went and read the authentication.md file inside the /docs folder on its own. No hand-holding needed.

I did the same for the home page, and again it read the relevant instruction doc. Then I asked it to make sure the sign-up and sign-in buttons follow the UI component coding standard — and it pulled up ui-component.md, read it, and updated the header accordingly using the shadcn component. That felt like a proper workflow clicking into place.

Tightening the Agent Instructions

After watching the agent work, I realized the instruction chain needed to be more explicit. I gave it a prompt to update AGENTS.md to make it crystal clear that reading the relevant individual instruction files inside /docs before generating any code is non-negotiable.

The agent rewrote the AGENTS.md file — added a new critical section, listed all the directive documents, and restructured things so the priority order was obvious. Small prompt, meaningful change.

Signing Up for the Anthropic API

Since I'm actively learning agentic coding, I went ahead and signed up for the Anthropic API. Bought $5 of credit to start experimenting with the models directly — coding, audio processing, that sort of thing.

Understanding Agent Types

Took a moment to properly understand the different types of agents available:

• Local agent — you give it a prompt and it runs directly on your device.

• Background agent — starts working in the background after receiving a prompt.

• Cloud agent — similar to GitHub Copilot's cloud-based execution model.

Each has its own trade-offs depending on the task. Good to have the mental model straight before diving deeper.

Designing the Link Schema with Drizzle ORM

Moved on to actual feature work. I needed a database table to store shortened links. Gave the agent a prompt to design a simple table schema and it created a schema file inside the /db folder using the Drizzle ORM.

The schema had the right fields: id, shortcode, url, userId, createdAt, and updatedAt. Table name: links. Clean and straightforward.

import { pgTable, text, varchar, timestamp } from 'drizzle-orm/pg-core';

export const links = pgTable('links', {
  id: text('id').primaryKey(),
  shortCode: varchar('short_code', { length: 20 }).notNull().unique(),
  originalUrl: text('original_url').notNull(),
  userId: text('user_id').notNull(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
  updatedAt: timestamp('updated_at').defaultNow().notNull(),
});

I started with the ask agent type to let it design the schema first before committing to implementation. Once I was happy with it, I told the agent to start the implementation. I also asked it to properly declare and type the id fields.

Then came the sync step — I asked how to push the schema to the Neon platform. It walked me through:

1. npx drizzle-kit generate — generates the SQL migration file inside the /drizzle folder.

2. npx drizzle-kit push — syncs the schema to the Neon database.

Worked first try.

Using MCP Inside VS Code with Neon

This was a new one for me. Learned how to connect an MCP (Model Context Protocol) extension in VS Code to an external service — in this case, Neon.

The flow is roughly:

1. Install the Neon MCP extension in VS Code.

2. Connect your Neon account to the extension.

3. Configure which tools you want to expose to the Copilot chat.

4. Enable those tools and start prompting.

Once connected, I could just type list my Neon projects and it would return actual project data from my Neon account. I also ran list out tools you have with the Neon MCP and got back the full list of available operations.

The most satisfying part: I asked it to generate 10 example link records following my schema, and it produced a JSON file with 10 properly structured entries. Then I told it to insert that data into my links table using my user ID — it generated a small script and ran it, populating the Neon database directly.

Switching to Native GitHub Copilot Instructions

Found out that GitHub Copilot has a native instruction system built around the .github/instructions/ folder. You put instruction files there, give each one a description in the front matter, and Copilot agents automatically pick up the right ones based on the description.

This is basically the same pattern I was already using with the /docs folder — but now it's native. A few things to note:

• All instruction files use the .instructions.md extension.

• You write a description in the front matter — that's what the agent reads to decide if a file is relevant.

• You no longer need to manually reference these files in AGENTS.md.

I migrated my existing instruction files into .github/instructions/ and that cleaned things up nicely.

Building the Dashboard — Links List View

With the instructions in place, I gave the agent a real feature prompt: build out the dashboard page, query for the currently logged-in user's links, and display them as a list. I referenced the dashboard file directly using # in the prompt.

It updated the dashboard page, wired up the query, and the list rendered correctly — showing links tied to the logged-in user. There were a couple of UI issues after the first pass, but one follow-up prompt fixed them. Dashboard was functional.

Server Actions — Writing the Instruction File

Before building out more features, I created a new instruction file specifically for server actions. The rules I put in:

• All data mutations go through server actions only.

• Server actions must be called from the component that needs them.

• Files must be named action.ts and live in the same directory as the calling component.

• All incoming data must have proper TypeScript types — no any.

• All data must be validated via Zod.

• Always check for a logged-in user before touching the database.

• Database operations go through helper functions (located in the /db directory) — server actions don't write raw queries.

• Server actions must never throw. They return either { error: "..." } or { success: "..." }.

Create, Edit, Delete, and Redirect

With the standards locked in, I moved fast on features:

Create: Prompted the agent to implement the link creation flow from the dashboard. It added a create button and the supporting logic.

Refresh bug: After creating a link, the dashboard wasn't updating. Gave a prompt describing the bug and it traced it back to the codebase and fixed it.

Edit & Delete: One prompt — implement edit via a modal, delete via a confirmation dialog, referenced the dashboard file. It implemented both. There was a small typing bug in the edit modal's input field; another short prompt fixed it.

Redirect: Asked it to implement the redirect functionality via an API route handler. Whenever someone hits /l/[shortcode], they get redirected to the full URL. It created the route handler and it works.

Learning About Subagents

Took a detour to understand subagents. The idea is:

When a task is large, the main agent's context window can fill up fast. Subagents are isolated agent instances spun up by the main agent to handle specific chunks of the work. Each subagent gets its own full context, so you're not cramming everything into one window.

They're especially useful for parallel tasks — things that don't depend on each other can run at the same time across separate subagents.

Skills and Context Management

Related to the context problem — learned about "skills". The issue is that loading all instruction files and MCP tool definitions on every prompt burns through context quickly.

With skills, the agent only loads the description of each skill upfront. Based on the prompt, it decides which skills are actually needed, then loads only those specific instruction sets. It's lazy-loading for agent knowledge.

For a project with lots of directive files, this makes a real difference in how far you can go before the context fills up.

Wrapping Up — Course Done, Model Costs

Finished the GitHub Copilot Beginner to Pro course today. The project — a working link shortener — turned out well. Honestly impressed with how capable agentic coding was throughout.

Here is the final project.

One thing I noticed along the way: the Claude Code model is noticeably more expensive than alternatives. Worth looking into Minimax M2.5 AI as cheaper options that apparently perform close to Claude. Planning to watch a few comparison videos on YouTube and also explore running the Qwen 3.5 AI model locally to see if I can get similar results without the cost.

Total features shipped: dashboard, create/edit/delete links, redirect handler, server action standards, MCP-driven seed data. Next up: model cost comparison, local model experiments.

The past couple of days were mostly travel and life-admin. Couldn't get much done on anything. Today I was pretty tired coming back to it, so I decided to just continue with the course as much as I can and call it a day. No shame in that — slow progress is still progress.

Getting the Project Off the Ground

Started a new project today — a URL shortener app. The approach here is a bit different from how I'd normally do things: I'm using whiteboarding alongside a Udemy course called GitHub Copilot Beginner to Pro to build and treat this as a proof of concept at the same time.

First things first — scaffolded a new Next.js project.

Setting Up Authentication with Clerk

Next up was signing up for Clerk for authentication. The process was pretty smooth — created an account, set up a notification, selected the framework, and copied the integration prompt that Clerk provides.

The nice thing about Clerk is that it ships with a ready-made prompt you can just hand straight to GitHub Copilot Chat, and it handles the integration for you.

Database Setup — Neon.tech & Drizzle ORM

Spinning up Neon

Created an account on neon.com and set up a new project there. Neon gives you a free-tier server-less Postgres database, which is perfect for this kind of proof-of-concept work. No overhead, no cost to get started.

Drizzle ORM — The Manual Route

This is where things got a little bumpy. The course has you follow all the steps manually to connect Drizzle ORM with Neon, and honestly — it felt off compared to how the Clerk section was handled.

Maybe the reason Clerk was smoother is that Clerk actually ships a ready-made integration prompt. Drizzle just doesn't have that, so there's nothing to hand off to the agent. That context makes it make sense, even if it slowed things down.

What I Learned Today — Custom Agents & Instruction Files in VS Code

The video I watched today was actually really useful. It walked through how to create custom agents and custom prompts inside VS Code, and then use those inside GitHub Copilot Chat.

The workflow goes something like this:

1. Create custom prompts in VS Code

2. Use those prompts to generate instruction files

3. Store instruction files inside a /docs folder in the project

4. Reference those files in AGENTS.md file so Copilot picks them up automatically

This is actually a pretty powerful pattern. Instead of re-explaining the project context every time you open Copilot Chat, you bake the context into files that get pulled in automatically. It keeps the agent grounded in what the project actually is.

What's Next

The plan for tomorrow is to start putting those instruction files to actual use — generate some real components and hopefully get the dashboard pages started. That's where things should start feeling like a real app rather than a setup exercise.

Spent the morning going through LangChain chaining. The core idea is straightforward — you build multiple prompt chains and wire them together so the output of one feeds into the input of the next. Think of it as an assembly line for LLM calls. You kick off the first chain with raw user input, and by the end of the pipeline you've got a final, refined response.

The more interesting bit was the routing chain. The use case that clicked for me: imagine a chatbot that supports multiple domains — physics, math, history, science. Each domain has its own system prompt tuned for that subject. When a user asks something, the routing chain figures out which "expert" chain is the best fit, then passes the input there. There's also a fallback default prompt in case nothing matches.

The routing chain actually makes two LLM calls: one to decide the route, and a second to get the actual answer using the matched system prompt. Took me a moment to internalize that it's two round-trips, not one.

RAG: Four Ways to Query Documents with a Vector Database

Next up was a video on using vector databases to build a question-answering system over documents. The gist: you embed your document content into a vector store, then query it. But how you query and pass context to the LLM makes a big difference. There are four approaches covered:

1. Stuffing — Dump the entire document content into the context window and send it with the prompt in one shot. Simple, but falls apart with large docs.

2. Map Reduce — Process each document chunk individually, passing each one along with the prompt to the LLM. The catch is the model only ever sees one chunk at a time, so it has no awareness of what came before or after. That limits the quality of answers that need cross-document context.

3. Refine — Similar to Map Reduce, but each iteration carries a summary of the previous response forward. It builds up context progressively, which gives the model a better running picture of the document as a whole.

4. Map Rerank — Each document chunk gets a relevance score when processed. After scoring all chunks, the highest-scoring one gets pulled and used as the context for the final answer. Good when you want the model to focus on the most relevant passage.

AI Agents with LangChain — Moving On

Finished the agents section of the course. The pattern is: wire up an LLM as the reasoning engine, attach tools to it, and you've got an agent. Nothing too surprising there conceptually.

Honestly, I got to the end of this course and realized I haven't found a concrete project to build with this yet. The knowledge is there, but nothing has clicked as an immediate "I can build this now" moment. Closing this one out and moving to the next course.

HackerRank Algorithms: Warmup Done, Then Hit a Real Problem

Switched gears to HackerRank for some algorithm practice. The warmup subdomain had around 10-11 questions — all very beginner level. Knocked them all out in under 5 minutes, every piece of code running on the first try. Nothing worth writing home about.

Then the last question actually made me think. The task: convert a 12-hour AM/PM time string into 24-hour format. Sounds trivial. Wasn't quite.

Solving the 12-Hour to 24-Hour Clock Conversion

The tricky part is the edge cases around 12:00. The conversion rules are:

• 12:xx AM → 00:xx (midnight edge case)

• 1:xx AM through 11:xx AM → same hour, no change

• 12:xx PM → 12:xx (noon, stays as-is)

• 1:xx PM through 11:xx PM → add 12 to the hour

My first pass extracted the hour, minutes, seconds, and the AM/PM suffix into separate variables. Then I wrote the conditions:

1. If hour is 12 and it's AM → set hour to 00

2. If it's AM (and not 12) → keep the hour as-is

3. If it's PM → add 12 to the hour

Ran it and immediately hit a bug. When the input was 12:xx PM, my code was outputting 24 — because it was blindly adding 12 to 12. The fix was one extra condition: if the hour is already 12 and it's PM, just leave it at 12. Don't add anything.

function timeConversion(s: string): string {
    const h = s[0] + s[1]
    const m = s[3] + s[4]
    const sec = s[6] + s[7]
    const isAM = s[8] + s[9] === 'AM'
    let fullHour = ''
    
    if (h === '12' && isAM) fullHour = '00'
    else if (isAM) fullHour = h
    else if (h === '12') fullHour = '12'
    else fullHour = `${12 + +h}`
    
    fullHour += `:\({m}:\){sec}`
    return fullHour
}

input 07:05:45PM
output 19:05:45

That one edge case was the whole puzzle, really. After patching it, all test cases passed.

Up Next: GitHub Copilot for Agentic Coding

Picked up a Udemy course by Tom Phillips on using GitHub Copilot for agentic coding workflows — how to use it to actually build applications, not just autocomplete snippets. Just getting started, carrying this into tomorrow.

Picked up LeetCode problem #20 today — Valid Parentheses. Honestly not a hard one once you recognize it's a classic stack problem. The core idea is simple: every time you see an opening bracket, push it onto the stack. When you hit a closing bracket, peek at the top of the stack and check if it's the matching opener.

I started by initializing an empty stack and a hash map that pairs each closing bracket to its corresponding opening bracket — so } maps to {, ] to [, and ) to (. Then I looped through every character in the string. If it's an opening bracket, push it and continue. If it's a closing bracket, pop the last element from the stack and check if it matches what the hash map expects. If it doesn't match, the string is invalid — return false right there.

After the loop, the final check is whether the stack is empty. If there are still elements sitting in it, that means some opening brackets were never closed, so it's still invalid. Empty stack means we're good.

function isValid(s: string): boolean {
    const stack = []
    const pair = {
        ')': '(',
        '}': '{',
        ']': '['
    }

    for (let bracket of s) {
        if (bracket === '(' || bracket === '{' || bracket === '[') {
            stack.push(bracket)
            continue
        }
        const lastBracket = stack.at(-1)
        if (lastBracket !== pair[bracket]) return false
        stack.pop()
    }

    return !stack.length
};

Why I'm Pausing LeetCode for HackerRank

While browsing around today I ended up on HackerRank and spent some time thinking about interview prep strategy. A few of the bigger tech companies here in Nepal actually use HackerRank for their technical screening rounds, which I didn't realize before. That changes things a bit.

I'm going to put LeetCode on hold for now and shift focus to HackerRank. I also want to take the front-end developer certification they offer — and honestly any other relevant certification on the platform. Better to align prep with what companies are actually going to throw at me.

LangChain Memory — Four Types Worth Knowing

Watched a couple of LangChain videos today. The first was mostly introductory stuff — how to set up the library, specify models, write prompts, and parse outputs. That level of detail is pretty well covered in the official docs anyway.

The second video was the more interesting one. It digs into how memory works in LangChain, which is really the core of building any useful chatbot.

1. Buffer Memory is the straightforward one — store the entire conversation history and feed it all back on each call. Simple, but it gets expensive fast.

2. Buffer Window Memory is a smarter version — instead of keeping everything, you only retain the last k messages (say, 5 or 10). Anything older just gets dropped. Good for keeping token usage in check.

3. Token Buffer Memory puts a hard cap on the number of tokens the model can use for context — something like 50 or 100 tokens max. It's a more granular way to manage cost vs. context tradeoff.

4. Summary Memory is the one that actually excited me. After each exchange, you ask the model to summarize the conversation so far and store that summary instead of the raw messages. You're keeping the semantic content of the whole conversation without burning tokens on verbatim history. This feels like the most practical approach for real-world chatbots.

5. Vector Data Memory. Instead of keeping conversation history in a list or summary, you store it in a vector database. When you need context, you query the DB for semantically relevant chunks rather than pulling everything. This is probably the most powerful option for long-running or knowledge-heavy applications.

Short day but productive across three different areas — algorithm practice, interview strategy, and AI tooling. The LangChain memory types are going to be useful soon.

Finished the ChatGPT Prompt Engineering for Developers course on deeplearning.ai today — or at least got close enough to call it done. It's a beginner-level course, but honestly it had a few good reminders worth writing down.

The core message of the whole thing boiled down to two rules: be as specific as possible, and give the model time to think. Everything else kind of builds on top of those two ideas.

For being specific, the course pushes you to:

1. Use delimiters to structure your prompts

2. Provide the output format

3. Add conditions so you can verify whether the output actually satisfies what you were looking for

Simple stuff on paper, but easy to forget when you're just throwing things at a model hoping something sticks.

The "give the model time to think" part was about breaking your prompt into explicit steps — basically treating the model like it needs a recipe, not a vague instruction. Specify each step, ask for output in a defined shape, and let the model work through it rather than expecting a magic one-liner to do everything.

Beyond the prompting basics, the course walked through a handful of practical use cases: iterative prompting (start rough, refine gradually), summarizing content, inferring meaning, transforming text, expanding ideas from a seed concept, and finally building a chatbot. The chatbot section was probably the most useful — it showed how to use a list of messages with a system prompt at the start, then alternating user and assistant turns, to maintain context across a conversation.

Next Up: LangChain for LLM App Development

Right after finishing the prompt engineering course, I jumped straight into the LangChain for LLM Application Development course. Haven't gotten far yet, but that's where the focus is moving next.

LeetCode 42 — Trapping Rain Water

Took a break from courses and worked on a LeetCode problem. The problem gives you an array of heights and asks how many units of water the elevation map can trap between the bars after it rains. Classic.

For example: [1, 0, 2] can trap one unit of water in the dip at index 1. The goal is to figure out the total across the whole array.

My first instinct was to go with a two-pointer setup and find the next greater element using a monotonic stack. The problem is, I couldn't remember exactly how the monotonic stack worked. I tried to reconstruct it from memory — empty array for the stack, another array for the output, fill with the same length as the input — but I got fuzzy pretty quickly.

I attempted it anyway. The rough idea was: for every element, if the current number is smaller than the top of the stack, pop it and push the new number. That gets rid of any smaller numbers and leaves you with the next greater elements. In theory. In practice, I was going in circles and not actually extracting anything useful.

First Real Attempt — Next Greater Element from Both Sides

I stepped back and thought about it differently. The idea was to find the next greater element going left to right, and then separately going right to left. For every index, the water it can hold is determined by the minimum of those two "walls" minus the current height at that position.

// Pseudocode sketch
for each index i:
    leftMax[i]  = max height to the left of i
    rightMax[i] = max height to the right of i
    minWall = min(leftMax[i], rightMax[i])
    if minWall > height[i]:
        water += minWall - height[i]

I coded it up, but my output was off — expected 5, got 6, didn't match. The indexing or the boundary conditions were wrong somewhere. I decided to look at the algorithm more carefully instead of guessing.

Prefix Max Array Approach — The One That Actually Worked

After reviewing, I found two clean approaches. Started with the prefix sum (or prefix max) array method.

The idea is straightforward: precompute an array leftMax where leftMax[i] is the highest bar seen so far from the left up to (but not including) i. Then do the same from the right with rightMax[i]. Once you have both, loop through every index and compute the water.

For the left pass, start from index 1 and at each step take the max of leftMax[i-1] and height[i-1]. For the right pass, start from index height.length - 2 and move backwards, taking the max of rightMax[i+1] and height[i+1].

I logged leftMax and rightMax first just to sanity-check they were right, and they looked good. Then I added the water calculation — only add if minimum - currentHeight > 0, otherwise skip. Submitted. It worked.

The final code

function trap(height: number[]): number {
    const leftMax = new Array(height.length).fill(0)
    for (let i = 1; i < height.length; i++) {
        leftMax[i] = Math.max(leftMax[i - 1], height[i - 1])
    }

    const rightMax = new Array(height.length).fill(0)
    for (let i = height.length - 2; i >= 0; i--) {
        rightMax[i] = Math.max(rightMax[i + 1], height[i + 1])
    }

    let water = 0
    for (let i = 0; i < height.length; i++) {
        const min = Math.min(leftMax[i], rightMax[i])
        if (min - height[i] < 0) continue
        water += min - height[i]
    }

    return water
};

Monotonic Stack Approach — The Hard Way (and also working now)

With the prefix sum solution accepted, I went back and made myself figure out the monotonic stack version properly.

The stack stores indices, not heights. You loop through every height, and before pushing the current index, you check: if the stack isn't empty and the current height is greater than the height at the top of the stack, that means you've found a "bowl" — a dip that can hold water.

When that happens:

1. Pop the top of the stack — that's the bottom of the bowl.

2. If the stack is now empty, there's no left wall, so break out of the while loop.

3. The left wall is whatever is now at the top of the stack.

4. The right wall is the current index.

5. Compute the width: currentIndex - leftIndex - 1

6. Compute the effective height: min(height[left], height[current]) - height[bottom]

7. Water trapped in this segment: height * width

8. Add to total and keep looping.

The -1 on the width tripped me up for a bit. If the left wall is at index 3 and the right wall is at index 5, the raw difference is 2, but there's only 1 cell in between (index 4). So you always subtract 1.

function trap(height: number[]): number {
    let water = 0
    const stack = []
    for (let i = 0; i < height.length; i++) {
        while (stack.length && height[i] > height[stack.at(-1)]) {
            const gap = stack.pop()
            if (!stack.length) break
            const left = stack.at(-1)
            const width = i - left - 1
            const boundHeight = Math.min(height[left], height[i]) - height[gap]
            water += boundHeight * width
        }
        stack.push(i)
    }

    return water
};

The while loop runs inside the for loop, and the stack push happens after the while loop exits. That's the rhythm of the whole thing.

What I Took Away Today

The prompt engineering course was a good foundation even if it felt basic — the iterative prompting section especially. For the LeetCode problem, the prefix sum approach is the easier one to reason about; the monotonic stack is more efficient in some ways but demands clean mental model to avoid off-by-one bugs. Got both working, which felt like a good ending to a long day.

It started simple enough — I was going to apply for a senior software engineer position and needed to update my portfolio. But the moment I opened my blog site, I noticed something that had been bugging me for a while: my journals and my proper articles were sitting side by side on the same Hashnode blog, and they just didn't belong together.

My detailed, meaningful articles deserve a clean space. And my journals, well, anyone who wants to follow the day-to-day grind can read those separately. Mixing them together makes neither look good. So I decided to split them.

Hashnode: multiple blogs, multiple headaches

The plan was straightforward. Create two separate blogs on Hashnode and map my subdomains:

• blog.ramankarki.dev → the real, polished articles

• journal.ramankarki.dev → the daily dev diary

The blog site came up fine. The journal site, though? Nothing. It just wouldn't work properly. My best guess is there's a bug in Hashnode when you try to run multiple blogs under a single account. I couldn't pin it down exactly, but something is clearly broken there.

On top of that, I ran into 3 more annoying issues on the platform:

Bug #1 — Publication switch not working. There's supposed to be a way to switch between multiple blog publication, but clicking it did nothing for me. Posts just stayed as-is regardless of what I selected.

Bug #2 — Date/time update broken. I tried to correct the publish date on a few journal entries. The date picker lets you set the date and time separately — I'd pick, say, February 18 at 9 PM — but after hitting update, it would save as February 18 at 12 AM. I confirmed this by right-clicking and checking the actual post data.

Bug #3 — Inconsistent dates across views. There's also a mismatch between how the date appears on the homepage vs inside the article itself. One article showed February 18, 2026 on the listing, but February 17, 2026 when you actually opened it. I don't know what's going on there.

Looked at alternatives — Dev.to and Notion

At this point I took a detour and looked at other platforms. Dev.to was the first one I checked, but it doesn't support custom domains and you're fully locked into their platform. That was a no-go — I want to own my content and my URLs.

Notion was next. You can technically turn Notion pages into a public-facing site, but the customization options feel too limited. I need full control over the UI and the ability to serve the journal and articles from clearly separate paths so readers don't get lost jumping between them.

Neither was the right fit.

Rethinking the whole approach: build a unified portfolio

Here's where my thinking shifted. I originally wanted a super minimal portfolio — just a single page with my name, my job title, and links out to my blog and whatever else. Quick, clean, done.

But if I'm going to have two separate content sections (detailed blog posts and journals), making visitors bounce between two different sites creates a bad experience. Every time someone clicks a link, they're context-switching to a completely different domain.

The cleaner solution is to build a single platform that has everything in one place: a projects section, a blog section, and a journal section. All under one roof.

I've been resisting building a custom portfolio because it felt like time that wasn't directly productive. But now there's an actual reason for it beyond aesthetics. The plan is to get through a web development with AI course first so I can leverage that to build the site faster, then actually build it properly.

LeetCode #15 — Three Sum

Later in the day I worked through LeetCode problem 15, Three Sum. The problem asks you to find all unique triplets in an array where the three numbers add up to zero, with no duplicate triplets in the result.

I'd solved a similar problem before — find a pair of numbers in a sorted array that sum to a target, using a two-pointer approach. Left pointer starts at index 0, right pointer starts at the last index, and you walk them inward based on whether the current sum is too high or too low.

Three Sum extends this by one dimension. The input isn't sorted, so first step is to sort it yourself. Then you loop over each element, fix it as the first number of the triplet, and run the two-pointer search on the rest of the array to find the other two.

The deduplication part is where things got interesting. To avoid returning the same triplet twice, I tracked already-found triplets using a map. I'd represent each triplet as a sorted array joined into a string, then check if that string already existed in the map before adding it.

Here's the rough flow:

sort the input array

for each number (fixed as first of triplet):
    set left = next index, right = last index
    
    while left < right:
        sum = fixed + nums[left] + nums[right]
        
        if sum == 0:
            build triplet string (sorted, joined)
            if not in map:
                add to output, store in map
            move both pointers inward
        
        elif sum > 0:
            right--
        
        else:
            left++

I hit an infinite loop bug early on because I was checking for duplicates before checking if the sum equalled zero. The loop would find a sum of zero, see the triplet already in the map, and then just... break without moving the pointers. So it'd re-check the same indices over and over.

The fix was simple once I saw it: check if sum equals zero first, then check the map. If it's a duplicate, still increment and decrement the pointers before continuing. That way the loop always makes progress.

function threeSum(nums: number[]): number[][] {
    nums.sort((a,b) => a - b)
    const map = new Map()
    const output = []

    for (let i = 0; i < nums.length; i++) {
        let left = i + 1;
        let right = nums.length - 1
        const num = nums[i]
        while (left < right) {
            const sum = num + nums[left] + nums[right]
            if (sum === 0) {
                const triplet = [num, nums[left], nums[right]]
                const tripletKey = triplet.sort((a, b) => a - b).join('')
                if (map.has(tripletKey)) {
                    left++
                    right--
                    continue
                }
                output.push(triplet)
                map.set(tripletKey, true)
            }
            else if (sum > 0) right--
            else left++
        }
    }

    return output
};

Day summary

A day that started as a quick portfolio update turned into a platform architecture decision and a bug-hunting session. Hashnode's multi-blog support has some real rough edges. Might end up building my own thing sooner than expected. And Three Sum is solved — that infinite loop was a good reminder that control flow bugs hide in the order you check conditions, not just the conditions themselves.

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.

LeetCode 125 — Valid Palindrome

Today I worked on LeetCode 125, the Valid Palindrome problem. The task is to check if a string is a palindrome after converting all uppercase letters to lowercase and keeping only alphanumeric characters.

My first instinct was to reverse the string and compare, but I quickly realized that approach would create problems because of special characters mixed in between. So instead, I decided to initialize a variable to keep track of the valid alphanumeric characters in straight order, then reverse it and check if both are equal.

I looped over every character, lowercased it first, checked if it was alphanumeric using a regex range (0–9 and a–z), and only then appended it to my string variable. The code was working. Then I moved the lowercase step upfront — before the loop — that made the code cleaner and a bit faster.

It was working, but only 10% of users ranked below me, which told me my solution was not optimal. One edge case tripped me up: I was using \w in my regex which includes underscores. I fixed that by manually defining the alphanumeric range as 0-9 and a-z. Since I had already lowercased the string, I didn't need to include capital letters separately. After that fix, it passed all test cases.

Here is the final code

function isPalindrome(s: string): boolean {
    let reverseStr = ''
    let str = ''
    for (let char of s) {
        const lowerCase = char.toLowerCase()
        if (/[0-9a-z]/.test(lowerCase)) {
            str += lowerCase
            reverseStr = lowerCase + reverseStr
        }
    }

    return str === reverseStr
};

Optimizing the Approach

Rather than creating a reversed copy of the string, I explored a two-pointer approach. The idea: lowercase the whole string once before the loop, replace all non-alphanumeric characters with an empty string, then use a left pointer starting at 0 and a right pointer starting at the last index. Loop while left < right, and if the leftmost character does not equal the rightmost character, return false. Otherwise, increment left and decrement right.

One thing I learned along the way — in regex, using a caret (^) inside brackets means "does not match this range." That made it easy to strip out non-alphanumeric characters in one line.

I ran it and the runtime percentage jumped around — 20% one run, higher another. I concluded that comparing runtime percentages on LeetCode is not very reliable since results vary each run.

Here is the final code

function isPalindrome(s: string): boolean {
    s = s.toLowerCase().replace(/[^0-9a-z]/g, '')

    let left = 0
    let right = s.length - 1
    while (left < right) {
        if (s[left] != s[right]) return false
        left++
        right--
    }
    return true
};

LeetCode 167 — Two Sum II (Input Array Is Sorted)

Next I moved on to LeetCode 167. Given a sorted integer array in non-decreasing order, I needed to find two numbers that add up to a specific target and return their indices.

I used the two-pointer pattern. Left starts at index 0, right starts at the last index (numbers.length - 1). I loop while left < right, compute the sum of the two pointed values, and check against the target. If the sum equals the target, I return the indices. If the sum is greater than the target, I decrement right. If the sum is smaller, I increment left.

My first test case failed because I forgot the question uses 1-based indexing. The answer needed to be [1, 2] instead of [0, 1]. Once I added 1 to both indices before returning, it passed.

Here is the final code

function twoSum(numbers: number[], target: number): number[] {
    let left = 0
    let right = numbers.length - 1

    while (left < right) {
        const sum = numbers[left] + numbers[right]
        if (sum === target) return [left + 1, right + 1]
        else if (sum > target) {
            right--
        } else {
            left++
        }
    }
    return []
};

Career Goals & Personal Project

I've been thinking about switching companies and targeting a top-tier company in Nepal. To prepare, I'm focused on three areas: refreshing my memory on DSA, design patterns, and advanced system design for a senior position.

I also realized I don't have a solid personal project to make an impression, so I've decided to build one. The idea is a budget management system — a combination of Splitwise and a money tracker app, so users can track both personal expenses and group expenses in the same place. I'm planning to use PostgreSQL as the database since I haven't used SQL based database in real world project. This project will give me the confidence that I need to get my carrier into the next level.

AI & Generative AI Exploration

I want to gain more knowledge in AI, so I've been going through AI content on YouTube. First priority is setting up a proper development environment for coding to improve productivity.

I also came across a repository from Karpathy — one of the founders of OpenAI — called microGPT. It shows how the core logic inside GenAI works, and the entire core codebase is only 200 lines of code. I'm going to dig into it to understand how AI works internally and strengthen my knowledge of generative AI.

I also found a video by Alex Jinskind where he talks about Claude Code and agentic coding — definitely going to watch that too.

System Design — CQRS vs Read Replica

I watched a video by Core Opinion that cleared up a confusion I didn't even know I had: read replica is not the same as CQRS.

CQRS (Command Query Responsibility Segregation) is a code-level pattern. When a feature involves expensive reads — say, multiple SQL joins — you create a separate read table where data is de-normalized and pre-computed. Write queries go to the original table. Read queries pull from the optimized read table. Many developers are probably already doing this without knowing it has a name.

Read replica, on the other hand, is an infrastructure-level solution. You use it when you're hitting actual traffic and scaling issues at the database infrastructure level — not just slow queries in code.

The distinction is clearer now: CQRS is a code optimization, read replica is an infrastructure scaling strategy.

End of day. Good progress on DSA, a clearer project direction, and a useful system design concept locked in.

Encode and Decode Strings (NeetCode)

Yesterday I started with a NeetCode problem: encode and decode strings. The idea was to take a list of strings, encode them into a single string, send that over the network, then decode it back to the original list.

The trick was figuring out how to tell where one string ended and the next began. What I landed on was a simple format: for each string, prefix it with its length followed by a special character as a separator — so something like 5:hello3:hey. Concatenate all of them together and you had your encoded string.

Decoding worked by scanning for the special character. Whatever came before it was the length. I used that length to slice out the original string, then moved the pointer forward and repeated until everything was recovered.

Here is the final code

class Solution {
    /**
     * @param {string[]} strs
     * @returns {string}
     */
    encode(strs) {
        return strs.map(str => `\({str.length}:\){str}`).join('')
    }

    /**
     * @param {string} str
     * @returns {string[]}
     */
    decode(str) {
        const output = []
        let i = 0
        while (i < str.length) {
            const delimiter = str.indexOf(':', i)
            const length = +str.slice(i, delimiter)
            output.push(str.slice(delimiter + 1, delimiter + 1 + length))
            i = delimiter + 1 + length
        }
        return output
    }
}

Product of Array Except Self (LeetCode #238)

Next up was LeetCode 238. The problem: given an array of numbers, return a new array where each index held the product of all the other numbers — no division allowed, O(n) time.

The solution used the prefix sum pattern, but with multiplication. I looped from start to end keeping a running left-side product, and assigned it to each index. Then did the same from right to left with a running right-side product, multiplying into what was already there.

I also worked out a trick to handle both directions in a single loop — using length - currentIndex - 1 to get the mirrored index, so I could update from both ends simultaneously without two separate passes.

The key insight: the product of everything except the current element was just the product of everything to its left multiplied by everything to its right. Prefix products gave me exactly that.

Here is the final code

function productExceptSelf(nums: number[]): number[] {
    const ans = new Array(nums.length).fill(1)
    let leftProduct = 1
    let rightProduct = 1
    for (let i = 0; i < nums.length; i++) {
        ans[i] *= leftProduct
        leftProduct *= nums[i]

        const rightI = nums.length - i - 1
        ans[rightI] *= rightProduct
        rightProduct *= nums[rightI]
    }
    return ans
};

Valid Sudoku (LeetCode #36)

Then I worked through LeetCode 36 — checking whether a Sudoku board was valid. Each row, column, and 3×3 box had to contain 1–9 with no repeats.

My approach was to initialize three 2D arrays — one for rows, one for columns, one for boxes — then loop through the grid with nested loops. If a cell was empty (marked as .) I skipped it. If it was a number, I subtracted 1 to get a zero-based index, then checked the corresponding slot in each tracking array. If it was already marked true, the board was invalid. Otherwise I marked it and moved on.

Rows and columns were straightforward. The tricky part was finding the correct box index. The formula I worked out:

boxIndex = Math.floor(i / 3) * 3 + Math.floor(j / 3)

This took a while to reason through. Dividing the row index by 3 gave which box row I was in (0, 1, or 2). Multiplying by 3 scaled it so there was room for the column offset. Adding the column index divided by 3 gave the final box index from 0 to 8. I wrote a quick test loop to console log the output and verify it matched what I expected — and it clicked into place.

Here is the final code

function isValidSudoku(board: string[][]): boolean {
    const rows = Array.from({length: 9}, () => Array(9).fill(false))
    const cols = Array.from({length: 9}, () => Array(9).fill(false))
    const cube = Array.from({length: 9}, () => Array(9).fill(false))

    for (let i = 0; i < 9; i++) {
        for (let j = 0; j < 9; j++) {
            const value = board[i][j]
            if (value === '.') continue

            const index = +value - 1
            const boxIndex = Math.floor(i/3) * 3 + Math.floor(j / 3)
            if (rows[i][index] || cols[j][index] || cube[boxIndex][index]) return false
            rows[i][index] = cols[j][index] = cube[boxIndex][index] = true
        }
    }
    return true
};

Longest Consecutive Sequence (LeetCode #128)

The last problem of the day was LeetCode 128 — finding the longest consecutive sequence in an unsorted integer array. Had to run in O(n) time.

I converted the array to a Set to remove duplicates and allow O(1) lookups. Then looped through the set. For each number, I checked if number - 1 existed. If it did, that number wasn't the start of a sequence — skip it. If it didn't exist, that number was the start. I began counting upward, kept incrementing and checking if the next number existed, tracking the count until the sequence broke. Then compared against the running max.

I caught a bug mid-implementation: I was looping over the original input array instead of the set. That meant doing redundant work on duplicate values. Once I switched to looping over the set, everything worked correctly.

Here is the final code

function longestConsecutive(nums: number[]): number {
    const set = new Set(nums)
    let longestSequence = 0
    for (let num of set) {
        if (!set.has(num - 1)) {
            let newLongest = 1
            while (set.has(num + newLongest)) {
                newLongest++
            }
            longestSequence = Math.max(longestSequence, newLongest)
        }
    }
    return longestSequence
};

Conclusion

Four problems yesterday. Good mix of encoding tricks, array manipulation, grid logic, and set-based searching. The Sudoku box index formula was the most satisfying thing to work out.