toxdes.com - Blog

Devlog 0x004

2026-09-08T10:30:00.000Z

It's been a while since the last devlog. I've got a lot to share about what I've been spending my time on, but due to IRL things unrelated to code, I had to be AFK for a week or so, so I couldn't publish this earlier.

Vylk

I briefly discussed the initial working implementation of vylk in my last devlog.

Since then, I have done a lot of improvements:

The UI now updates in real-time when synced across devices.
There's a new UI popup for resolving merge conflicts in notes.
Better "Preferences" UI.
There are new pre-bundled well-known themes beyond the default light and dark.
Ability to "pin" notes.
Popular google-fonts for UI, editor and preview. Selected font is downloaded once and cached locally until font is changed.
Automatic session renewal once the user is logged in and connected to the server. Currently, session expiry invalidates local unsynced notes. So, if you keep using this app offline for more than 6 months, all of the data will be lost, which is awful. I'll think more about this.

I've been using this to share text across devices - which I used to do earlier by sending messages to myself on Telegram, taking notes, writing draft posts - all day.

It actually feels like a native app now, and being a PWA, it works on every single device. Everything is offline-first, syncing happens via a web-worker, either periodically or after any user activity.

mousr

Another fantastic utility I've been working on is mousr. The idea is simple: I use sway window manager as my daily driver which means I use my keyboard a lot more than my mouse.

I wanted to simulate mouse controls with the keyboard - I saw this on ppy's streams. The program he uses finds potentially clickable elements on the screen selectively - either via API or OCR, not sure - but it doesn't seem to be reliable enough. He often needs to fall back to moving pointer like a joystick with keyboard - I wanted something more deterministic.

When I want to click somewhere, my eyes are already looking at the target position. So if I geohash my screen, potentially recursively if where I want to click isn't covered correctly by a rectangle, clicking doesn't take any cognitive effort to find the correct grid. I looked at existing open-source alternatives, but NONE of them allow me to simulate mouse button at any level of this recursively geohashed rectangles. I can simulate clicks only in the last level? WHY?

So I built one, currently it only supports sway. Geohashing the screen is the primary use case, but it also supports a joystick-like pointer control as a fallback too. I've been daily driving this on sway, which is the only window manager it supports, and so far it's been perfect. I'm also thinking about adding hexagonal shape would help, let's see.

This is what my sway config looks like with this tool:

# start the daemon
exec mousr daemon

# grid mode across all displays
bindsym Mod1+space exec mousr grid --scope all

# mouse mode
bindsym Mod1+Shift+space exec mousr mouse

# bind scroll up/down
bindsym --inhibited Mod4+bracketleft exec mousr scroll down --step 20
bindsym --inhibited Mod4+bracketright exec mousr scroll up --step 20

BTW, this does not eliminate the mouse entirely, for a mouse-heavy workflow like drawing something. But most of the time, I just want to emulate a click at some position on my screen, and this lets me do it instantly.

I'm planning to support hyprland first, probably with a VM, and after that I'll see if macOS support is possible.

jiotv_go

I'm also maintaining a fork of jiotv_go, which adds an alternative webOS-friendly UI and some small goodies that I needed for myself.

I finally got root access to my LG TV's webOS using this script. Now I can directly run the aarch64 server binary on the TV and configure it to start the server at boot. The ipk can now use localhost, so no more network hops and cumbersome local https setup with caddy and an extra device!

Alright, that's about it for now. Also, I promised I wouldn't change fonts for the next three years on this website in my last devlog, but Recursive was too good to pass on, I'm sorry.

Interesting links

Unfortunately, nothing to share this time. Been busy with working on stuff mentioned above.

Until next time :^)

By the way, if you're interested, you can check out all devlogs here.

Edits

(2026-09-17) - Renamed MDNotes to Vylk.

Devlog 0x003

2026-08-05T10:30:00.000Z

I promised in the last devlog that I'd write posts more often. Let me share what I've been up to.

Running LLMs on Android

I have made this cards app that I've been using it almost everyday for the past year or so. It's like cards feature of Bitwarden, extracted into a standalone app. It works completely offline (no INTERNET permission in the manifest), and I want to keep it that way.

I've been thinking about how I could add credit card bills and expenses tracking to this app without using internet. The obvious way is to let the user enter the amounts. That's trivial but feels like a very cumbersome UX for the users.

The other way is to let the user select the PDF statements from their device, and the app extracts and parses the text. This would work if there was a set standard in place that all PDF files followed, but sadly there isn't.

Each bank has their own fancy-looking PDFs, and it's impossible for me to have access to all of them. Also, it would require updating the parser logic every time some bank updates their bill's PDF layout. So a deterministic parser doesn't seem to be the solution.

I was curious if we could do better by running smaller LLM models on the device. I built a quick prototype in Flutter to play around with different <=1GB models from Hugging Face.

I tried different ways to process the PDFs - ranging from feeding the LLM text blocks with positions encoded for each text block, rendering the PDF to PNG and using vision-enabled small LLM models, OCR results with position-encoded text and so on. So far, I've not been able to achieve any reliable results. Maybe my ideas are wrong, or small on-device LLM models are just not there yet.

Vylk

theo-image

I feel like I'm on the far left here, I've been this way even before the AI happened, but does it even matter atp? We're in a world where everyone just makes what they want. This feels like the era of personalized software, and open source is slowly dying. There's no good answer to "If I can vibe code an app the way I want it, why should I use yours?".

Indeed, I spent an hour searching for a self-hosted markdown editor that's

Low on resources
Functional enough
Can auto-save
Work offline when the server is down, and sync when the server comes back up
Can work reliably from all of my devices (Android, MacOS and Linux)
Has decent UI and is mobile friendly

but I couldn't find one. Not even a single person vibecoded this? NOO :(

Every solution there tried to do too much, or the solutions that remotely match my needs, the UI feels like it's from the 2010s.

So, I did what I was trying to avoid all along, write a 1 viewer vibe coded slop website, yet again.

I wrote a prompt in about 5 minutes, gave permissions and went AFK. Came back in an hour, and it had a working prototype ready. Polished the UI a little bit for another hour and now it's deployed. It just works on my 1vCPU VPS. I'm using it right now, to write this draft.

Update: I've polished it a bit more, you can check the source code, even though it feels pointless.

Btw, only used deepseek-v4-flash from opencode free plan for the MVP, and then terra-5.6-high from OpenAI for the sync functionality. while wr're at it let me glaze real quick - deepseek-flash-v4 model is so underrated for how fast and useful it is.

Here's how it looks:

vylk-screenshot

Commiting secrets to git repo

Ever since I've come across gpg, I've been finding so many usecases for it - be it signing / encrypting the messages, or password protecting any files before sharing.

I recently made an rsync wrapper script to sync specific files, the way I wanted. The specific dirs, I didn't want them to be in my codebase, so I added the encrypted syncm_vars.py to version control.

Now, the script that installs syncm, asks for gpg passphrase at install time, and upon successful entry, replaces the content between # BEGIN SYNCM_VARS and # END SYNCM_VARS. I know it's probably better to leave secrets out of the repo, but for small one-off things like these - things that are not-so-secret but are still secrets, this is fantastic.

Alright, that's about it.

Interesting links

By the way, if you're interested, you can check out all devlogs here.

Edits

(2026-09-17) - Renamed MDNotes to Vylk.

Devlog 0x002

2026-07-25T10:30:00.000Z

I want to start this post with an apology. I did not expect it would take this many days to write another devlog post. I've been postponing writing this, mainly because I was busy with things, but the main reason was the lack of motivation, which is the worst excuse one can ever use. I'll post more frequently, either weekly or biweekly, NOT or whatever like I said in the last devlog.

Anyway, let me start sharing what I've been up to.

Fonts

One thing I've been spending unnecessarily long time on is which fonts to use on this website. When I started this blog, I wanted to use less common fonts that looked nice. So, I started with Zalando Sans, which was short-lived because I came across Funnel Sans, it felt like a better Inter to me.

As I went on reading others' posts on their websites, I realized reading paragraphs with a sans font felt very distracting. So I decided to move to a serif font. Then spent some more days deciding whether to be a sans guy or a serif guy, and the result is what you see right now. I ended up defaulting to a serif font, but added extra options for sans and monospace. I'm now locking-in on these chosen fonts for 3 years, no matter what happens.

One little optimization I'm doing is limiting the charset of the said fonts to ASCII (plus some other characters), saving ~40% of network bandwidth per font. Of course, the underlying assumption is that I control all of the text content on the website, and it's mostly English.

That's about it. Now y'all can choose whichever one you like :)

Promptr

I've started working on a new idea I've had for a long time. I know C, but don't know GTK APIs that well, so this is a slop-first project. As of now, the latest release v0.2.3 works like OpenCode CLI wrapper. The high level architecture looks something like this:

promptr-current-arch

I'm currently working on a new architecture that will allow switching the providers. I've picked OpenRouter as the next provider. The plan is to allow adding more providers as plugins. This is the high level overview of the WIP architecture:

promptr-next-arch

Moving back to Neovim

I used to use Zed as my primary text editor (with vim keybindings), and for terminal's $EDITOR, with near-default config. My problem with Zed was simple, forcing AI features down my throat even though I don't like to use it.

So far I've used Sublime Text, VSCode, Neovim, Emacs+Evil and Zed as my primary editors. I wanted emacs to give one more chance, this time with native keybindings instead of the evil-mode, so I did, and it's not my cup of chai. Too much effort to do simple things. So, I'm back to neovim. My only small problem with neovim is that I'm restricted to what TUI can offer, which feels limiting but other than that it's all good.

I wanted to have two variants of neovim, one lightweight variant with near-default config and plugins - used when I want quick text editing, e.g. git commit messages, configs etc and the other more sophisticated variant with more plugins, LSPs, formatter etc. $NVIM_APPNAME environment variable lets me do exactly this. Now I have two aliases in my .bashrc:

alias v="nvim"
alias ve='NVIM_APPNAME="nvim-dev" nvim'

You can check out my dotfiles for reference. There's still more to learn, I have yet to come across a conflict-resolver that's as good as VSCode though.

That's about it for now.

Interesting Links

Some of the things I've read or been reading over the past few weeks -

Rewriting Bun in Rust - https://bun.com/blog/bun-in-rust
Client-Side Load Balancing at a Million Requests Per Second
Bitchat Protocol Whitepaper
Atomic Habits (Book) - https://jamesclear.com/atomic-habits

By the way, if you're interested, you can check out all devlogs here.

Building Promptr

2026-06-30T10:30:00.000Z

Growing up, I've always wanted to build a Linux-first GUI app. It's the one thing that always bothered me when I first decided to move from Windows - the scarcity of the GUI apps on Linux. Eventually, browsers got stronger, and a lot of stuff moved from native GUIs to web apps. Also, the WINE based workaround for Windows apps wasn't really a great experience either.

The problem with modern LLM chat interfaces is (at the time of writing this post) that they're too slow, especially when a conversation is too long, the UI in general looks bad (non-optimal use of screen real estate), and the whole experience isn't ...ergonomic.

Here are some of the chat interfaces I've had the misfortune to use since the announcement of ChatGPT back in 2022 (opinionated ranking by their horribleness):

Out of these, the first three are really horrible, and unusable to this date for some reason. Perplexity and T3 Chat have a nice UI and allow using different models, but they require a paid plan just for chats, and these are the only two AFAIK that support ?q=<text>, which people usually combine with Firefox's keyword bookmarks for quicker access. Btw, The only reason Perplexity is even in the list is because of the 1 year free promotional offer for Indian users, otherwise perplexity seems way more expensive, and now that the free offer is about to end, I, as a novice freeloader myself, am looking for alternatives.

I just want something that's -

Fast AF to pull up when I'm in the middle of doing something, send a query, get a response, and continue asking follow-ups as much as I want.
Preferably free, for reasonable LLM usage (with web-search and web-fetch toolcalls)
I've spent enough time with markdown files that I can use my brain as the markdown parser.
I don't want to launch a browser (Electron) just for this. It defeats the whole purpose.
First class keyboard support.

This is what I'm building with Promptr:

promptr-screenshot

Edits

(2026-07-03) - Add link to firefox's keyword shortcuts for search

Devlog 0x001

2026-05-15T10:30:00.000Z

This is a new "series" I'm starting. I haven't decided the frequency yet, but probably like weekly or biweekly or just whenever. Let's see how it goes. The goal of this series is to share what I've been spending my time on, some thoughts and some cool or interesting things I've learned or come across since the last Devlog.

Dev

For the past few weeks, I've spent time building chronobsky and adding support for LG's WebOS to my own fork of jiotv_go. Finally, my legacy frontend engineering skills are coming in handy. Kinda sad to see that after almost 3 years of offering free premium TV channels, Jio is now introducing subscriptions, but it was fun while it lasted.

Having worked extensively with React from the pre-LLM era, I automatically used to underestimate how performant the browser's HTML rendering is by default for static content, and used to add things like pagination and virtualization. With LLMs, dynamically stitching HTML components at build time has become really easy.

One thing I've realized is that with AI, it's very addictive to introduce slop in your projects. For example, adding a TUI dashboard in glesha turned out to be pretty much a useless feature, but at the time of introducing it, I just couldn't resist "vibe-coding" one specific independent-ish module in the project, and I've spent the past week de-sloppifying the codebase. Nowadays, I kinda sit on any idea that comes to my mind a little bit longer to see if I really want it in.

Tailscale

If you use more than one device and need to ssh to and from each other quite frequently and haven't heard of Tailscale yet, you should drop everything you're doing and take 5 minutes to set all devices up, and it's definitely worth it. I have been hearing about Tailscale every now and then for the past few years, but never bothered to actually check it out because I didn't even know what it does. I wish I had looked into it way earlier.

I have two laptops and a Raspberry Pi (Zero 2W), and I also have two different ISPs for my internet, one is stable but slow, another is unstable (frequent disconnects) but fast. pi is always connected to the stable but slow network, but this is not the case for my laptops. I also have a tiny VPS for tinkering, and I ssh into these devices very frequently.

Before this, I used to switch networks just to be able to connect to my Pi. I had also looked into both routers' settings if I could connect them so that I could access devices connected to two different routers, but there was no easy way to do this so I just didn't bother. I knew one way to do this by editing /etc/hosts and similar files on each device and using static local IPs for each device, and maybe setting up port-forwarding to access over the internet, but it just felt like too much work, and then there's the obvious exposure-to-internet aspect. As a last resort, I googled "how people usually do this" and found out that Tailscale does exactly this, automatically, and only devices in the tailnet can communicate with each other, and external actors cannot because Tailscale uses a reserved IP range that isn't publicly routable.

Moving back to Alacritty

I was using alacritty terminal for the longest time, and I've been trying out alternatives like st and foot. Mainly because each window of alacritty terminal took ~200MB (wasn't aware of create-window yet), which seemed very unfair, and also I never really noticed why GPU-acceleration was needed to just render text on screen.

I tried st at first. It felt way too barebones but on the bright side, it also took very minimal ~10MB memory for each instance. For st, the font-rendering somehow felt worse for me. Also to configure st, it required patching source code and recompiling. As a result, I decided to move on to the next candidate, the builtin default of sway, the foot terminal. It took ~24MB for each instance, had saner configuration support. I had been using foot ever since, until last week when the opencode CLI just kept crashing foot. I never thought a CLI program would be capable of crashing a terminal. After spending around 5 to 6 months with foot and reconsidering other options yet again, this time the candidates were ghostty and alacritty, and ghostty just felt too early-stage for me.

By the way, after using a terminal that uses CPU rendering for a while, the difference of GPU accelerated rendering is very noticeable to me, and ~200MB feels worth it. One good thing I didn't know earlier is the use of alacritty msg create-window which is a life-saver and makes all the difference to me. Now it's just a single ~200MB, with ~8MB of /bin/bash for each newly spawned terminal window. So, for the foreseeable future, I think I'll stick with alacritty until something better comes along.

DSA

One micro-optimization in Java is computeIfAbsent. Not only is it shorter to type, it also avoids creating throwaway ArrayList<>() instances.

// bad
List<Integer> existing = map.getOrDefault(x, new ArrayList<>());
existing.add(y);
map.put(x, existing);

// good
map.computeIfAbsent(x, k -> new ArrayList<>()).add(y);

BFS can be done without explicitly creating the entire graph upfront, especially when finding neighbors of a vertex isn't expensive.
Sometimes, you can introduce auxiliary/dummy vertices in a graph problem; this can simplify the problem by representing repeated transitions as one step, and you can avoid doing extra repetitive work.
When creating a prime sieve, it's more efficient to start marking composite numbers from i*i instead of 2*i if i is prime, because all composite numbers from i...i*i already have a prime factor that's less than i so they would have already been marked composite by a smaller prime number.

Interesting Links

Some of the things I've read or been reading over the past few weeks -

Open social - https://overreacted.io/open-social
How OpenAI delivers low-latency voice AI at scale - https://openai.com/index/delivering-low-latency-voice-ai-at-scale

By the way, if you're interested, you can check out all devlogs here.

Ropes Data Structure: From the Original Paper to Implementation

2026-04-22T10:30:00.000Z

One day, I was looking for asymptotic complexity of ECMAScript String's += or concat() operation out of curiosity, and wondered why JS doesn't have a traditional StringBuilder since the strings are immutable. Turns out, the JS spec doesn't specify any Big-O complexity guarantees and they are left to the implementers, but still I couldn't wrap my head around how concat() operations could happen in near-constant time. Coincidentally, almost all popular browser-based JS engines - V8, SpiderMonkey, JavaScriptCore and LibJS - implement this data structure internally and I still don't see people talk about it more often: Ropes.

Tradeoffs

Of course, there are tradeoffs. Otherwise ropes would have been the de facto standard for implementing strings in any programming language. The reason they're not quite as popular is because they solve a very niche problem involving large immutable strings, frequent concatenation, substring sharing, or editor-like updates. As a result, almost all of the popular engines use different underlying representations for strings, based on the length. One possible use case that I can think of is React's renderToString().

Ropes actually perform worse for short strings because of the pointer overhead and cache locality, and in a typical workload, most strings are usually small. As a result, engines use plain one-byte (ASCII) or two-byte (UTF-16) strings, until the length of the string exceeds a threshold, at which point a rope-like (extending the idea of ropes from the original paper) structure is used which uses flatten-on-demand. It means concat()s are O(1) since it modifies ~2 nodes, and when the tree is rebalanced (rope is flattened) is engine-specific. Mostly it's flattened when there's a request for linear char buffer, indexing, native interop, or certain substring paths. It gives the best of both worlds, concat()s are faster, and we don't have to spend time rebalancing until we actually need it. The amount of ad-hoc optimizations these engines do is fascinating.

Implementation

Alright, let's go through the original paper. The idea of storing data in the leaf nodes and information about the data in internal nodes of the tree isn't new, B+ trees existed since early 1970s. However, B trees self-balance on insertion, with at most O(log n) node updates, but in case of ropes, rebalancing could cost O(rope_len) in the worst-case, which means worst-case adversarial input can be generated that triggers rebalancing after every concat().

The paper mentions length of rope should be at least F(n+2) for a depth of n. But how do fibonacci numbers come in the picture while describing the definition of a balanced binary tree? The usual definition of a balanced binary tree is abs(h(left)-h(right)) <=1 (i.e. heights of left and right subtrees of every node in the tree differ by at most 1), which means for a tree to be balanced -

For depth=0, min_leaves_required=1
For depth=1, min_leaves_required=2
For depth=2, min_leaves_required=3
For depth=3, min_leaves_required=5
For depth=4, min_leaves_required=8 ... and so on

which forms a sequence 1,2,3,5,8... which is a standard fibonacci sequence shifted by 2, hence the bound ofF(n+2). You can verify these values by drawing a balanced binary tree on paper. So, given a rope's total length and current tree depth, we can efficiently get a rough estimate of whether the tree needs rebalancing after a concat() operation.

I also like how the paper just assumes you have a garbage collector at your disposal, and even hints at using reference counting if you're implementing in a language like C. Let's not implement a GC here, maybe some other day, in another post. Let's use Go and for simplicity we will only consider ASCII strings for now. We'll see how things might change for UTF-16 later.

The API contract looks something like this -

type Rope interface {
  Len() int
  String() string
  Concat(other Rope) Rope
  At(index int) byte
  root() *node
}
type rope struct {
  root *node
}

// expose root via root()
func (r *rope) root() *node {
  if r == nil {
    return r
  }
  return r.root;
}

The paper specifies, we require some notion of "sequence of characters" for leaf nodes. Let's use strings for that. It also mentions tree indexed by position, it means we need to store some information about the length of string represented by a node. Let's use totalLen for that. The node will look something like this -

type node struct {
  left *node
  right *node
  leaf string
  totalLen int // length of substring represented by this subtree
}

Let's start with implementing easier and straight-forward Len() and Concat() first. Since we're maintaining totalLen for each node, Len() is trivial. For Concat(), we just create a new parent root node, and attach roots of the two ropes as left and right children of this newly created node. Note that since we're not doing any rebalancing, this operation is O(1).

// length
func (r *rope) Len() int {
  if r == nil || r.root == nil {
    return 0
  }
  return r.root.totalLen
}

// concat
func (r *rope) Concat(other Rope) Rope {
  return &rope{root:concat(r.root, other.root())}
}

// helper
func concat(a *node, b *node) *node {
  if a == nil {
    return b
  }
  if b == nil {
    return a
  }
  return &node{
    left:a,
    right:b,
    totalLen: a.totalLen + b.totalLen,
  }
}

Let's implement String() now, which is a standard in-order tree traversal.

func (r *rope) String() string {
  if r == nil {
    return ""
  }
  return r.root.String()
}

func (n *node) String() string {
  if n == nil {
    return ""
  }
  if n.left == nil && n.right == nil {
    return n.leaf
  }
  return n.left.String() + n.right.String()
}

The idea for implementing At(x) is to do a DFS from root node, since we store total length represented by subtree under the node, it tells us if we need to explore left or right subtree. Once we are at the leaf node, we just return the character in the leaf string chunk. For simplicity, let's ignore out-of-bounds errors.

func (r *rope) At(index int) byte {
  return r.root.at(index)
}

func (n *node) at(index int) byte {
  if n.left == nil && n.right == nil {
    return n.leaf[index]
  }
  leftLen := 0
  if n.left != nil {
    leftLen = n.left.totalLen
  }
  if index < leftLen {
    return n.left.at(index)
  }
  return n.right.at(index-leftLen)
}

Now the only challenging part remaining is rebalancing the tree. The idea is to rebuild a balanced tree. Since the left-to-right order of leaves gives the canonical representation of the text we are storing, we first collect leaves by traversing similar to how we did it in String() implementation. After collecting the leaves, we build the new tree by recursively splitting the collected leaves in half and combine the two halves with concat().

            root                            root
           /    \                          /    \
        node     "gh"       ---->       node     node
       /   \                           /   \    /   \
    node    "ef"                    "ab"  "cd" "ef" "gh"
   /   \
"ab"  "cd"

collected:["ab","cd", "ef", "gh"]

Let's implement rebalance() now. We can call this rebalance() whenever it's optimal to do so.

func (r *rope) rebalance() *rope {
  if r == nil || r.root() == nil {
    return r
  }
  return &rope{root:rebalance(r.root())}
}

// helper
func rebalance(n *node) *node {
  if n == nil {
    return n
  }
  if n.left == nil && n.right  == nil {
    return n
  }
  leaves := make([]*node, 0)
  collectLeaves(n, &leaves)
  return buildBalanced(leaves, 0, len(leaves))
}

// collect leaves in order
func collectLeaves(n *node, leaves *[]*node){
  if n == nil {
    return
  }
  if n.left == nil && n.right == nil {
    *leaves = append(*leaves, &node{leaf:n.leaf, totalLen:n.totalLen})
    return
  }
  collectLeaves(n.left, leaves)
  collectLeaves(n.right, leaves) }

// build a new balanced tree
func buildBalanced(leaves []*node, L, R int) *node {
  if L >= R {
    return nil
  }
  if R-L == 1 {
    return leaves[L]
  }
  M := L + (R-L)/2
  left := buildBalanced(leaves, L, M)
  right := buildBalanced(leaves, M, R)
  return concat(left, right)
}

This wraps-up our basic implementation of ropes. Of course we could re-use leaf nodes and do a ton of other optimizations, but hopefully the basic idea is clear now.

References

For further reading:

Amazon SDE-II Interview Experience

2026-04-12T10:30:00.000Z

I have recently fumbled my interview rounds for the SDE-II role at Amazon big time. I think it's worth sharing. Since all of my professional work experience so far has been for early stage startups, I didn't get a chance to work on stuff where horizontally scaling the servers was necessary. So, my long-term goal is to work at a place that has a product with a lot of users. Amazon is one of them, despite how bad rep they get for their work culture.

I applied to a few positions on Amazon's career portal a few months back because even though Amazon looked very busy breaking their own records in laying off employees, their careers page also had a few recent openings. Anyway, after 3-ish days, I received an OA, which had 2 problems to be solved in 90 minutes, a "work-style simulation" based on their "leadership" principles and a somewhat basic system design quiz.

Online Assessment

It had two problems, surprisingly both problems were based on bitwise operations. First problem was of medium difficulty, I cannot share the exact problem, but it was based on range XOR sum queries (via prefix XORs), and was trivial if you knew the ball knowledge:

XOR_SUM(a[i]..a[j]) = pref[j]^pref[i-1];

Second problem was this one, it was hard but I was able to come up with a greedy approach where we start with 0 as our candidate answer for final AND, and try to get 1 at each position of our candidate answer starting from MSB to LSB, where we check the feasibility of including m least expensive elements using at most k total increments.

I was able to solve first problem within ~15 minutes, and spent the rest of the time on the second problem.

I also skimmed through the Amazon LPs before the OA, so I don't mess up the workstyle assessment questions.

Round - 1

Interviewer was SDE-2, he was younger than me, he joined 5 minutes late, I was already nervous pro max and panicking because this was my first time interviewing for FAANG, he joined and said don't worry we'll extend by 5 minutes. We introduced ourselves, and he jumped to problem solving right away.

First problem was this one, which I knew how to do, so I told the optimal solution, stated complexity, asked if I should start writing code, coded it up, we were past 20 minutes by now.

Then he asked the second problem this one, for which I was able to come up with a brute force BFS solution, but I ran out of time. I regret picking java as my language of choice for the interview. Also, my solution wasn't really optimal, the interviewer tried to give me hints, but I crumbled under pressure of time running out since he had mentioned in the beginning he is expecting optimal solutions to BOTH problems. As soon as the interview was over, the hint he gave clicked, but it was already too late. I was not able to complete the bfs(...) function because it's standard and I have run out of time. He said now he has to ask me some questions based on LPs, which he asked and I answered.

Round - 2

Two weeks went by, and my second round was scheduled, this guy looked really tensed for some reason. After introduction, he asked me to write API for music library app, expectation was to tell class design for entities and only requirement was that he wanted low latency for getTopKPlayedSongs(k) and getTopKPlayedSongs(artistId, k), addSong(artist, song). I started with listing out entities like Player, Artist, User, Song, Library etc, and then I went blank, I knew how to do getTopKSongs(k) in O(log n) with a HashMap<Count, Set<SongId>> and a TreeSet<SongId,Count> combo, which I told when I ran out of time, but again, the expectation was to get a "production-level" code in 30 minutes.

It requires at least one soft yes to get to round 3 and round 4, and knew immediately after second interview was over that I didn't get it.

Key takeaway is, time is way more limited in these interviews, you get ~20 minutes to explain and code the optimal solution. Good thing is, I was able to solve every problem so far, so we're past "wtf do i even do here man" stage, so that's some progress, but need to work on time and not panicking.

We're just not there yet gang, the grind must go on, maybe in next 6 months :)

Big update - Current state of things

2026-04-09T10:30:00.000Z

Finally, after spending a lot of time updating this website, and even more time bikeshedding about colors and spacing, it's finally ready. I have also decided to write more, I'll explain why in a bit.

Migrating to a new domain

So, on one fine day, I was chitchatting with gemini about why my old domain txds.me was not ranking properly in the Google's search results, even after I specifically told claude to "make sure my site is SEO optimized". It kind of did the job since I currently rank 5th if I search for txds on Google and that's nice for me being a nobody, and to be fair, txds isn't even really related to me in any way. It was just toxdes without vowels to get a shorter domain for my personal space on the internet.

Now why toxdes? well, I started using internet really late, so all the cool usernames that made sense were already taken everywhere, so I had to work with whatever was available at the time, and I have stuck with it ever since. Gemini also convinced me to use toxdes.com because nothing significant exists for this word. I also tried my firstname+lastname combo, but turns out my name is way too unfairly common than it should be, so here we are.

By the way, I also checked historical whois data, and found out that txds.me was registered at least 8 times in the past, and toxdes.com wasn't registered even once. It's a really nice tool.

The migration is pretty much complete, and moving forward I'll be exclusively using toxdes.com. I currently use Cloudflare to manage DNS records, and this website is also statically hosted on Cloudflare pages. I also host some of my historic personal projects on github pages and vercel under subdomains. Vercel's dashboard has a functionality to add *.toxdes.com domain, and setup redirects for*.txds.me to redirect to the newly added domain, so those were easy. I migrated from netlify to vercel for one old project, it was just easier to manage that way. And for the github pages site and the main txds.me domain, I am using Cloudflare's redirect rules.

Adding likes to blog posts

I've been learning about system design since forever, and I thought this might be a good idea to burn some tokens add a little bit of "server-side" state to this website.

We live in exciting times nowadays where realizing an idea is just few prompts away, I quickly ended up vibe-coding counter as a service. The goal was simple, adding "likes" to my posts. Within 2-4 prompts, I was able to get a multi-tenant counter backend server as a single binary which exposed some HTTP endpoints and synced state to the postgres database.

I also added a small in-memory LRU cache to do async updates to the postgres database, mainly because redis felt like an overkill. Perfect little solution for a perfectly little problem. I know it can be abused easily, and cannot really scale well, I'll hopefully improve it and make it a little bit more reliable as the time goes by, but for what it's worth, it's good enough for now.

Why write more

I always felt like I had nothing to share, and I wasn't a good enough engineer to share non-trivial computer science things, and in the age of LLMs, writing blogs felt actually pointless.

Recently, I had a great chat with someone in the tech recruiting space who smuggles decent engineers to startups. When they asked why I had only 2 blogs in the last three years, I was like what's the point in writing about trivial stuff. The good takeaway from the chat was writing a tech blog was never about storming the frontier of advancement in computer science, which feels strange now as I type it out, but it was exactly what I used to think - everything I ever knew about programming and computers always felt like explaining how to add two numbers 6 + 7.

After the chat and then some pondering, I had a change of heart. I have decided to write more. I think I'll start writing whatever trivial things I know, or will learn next, because what's trivial to me may not be trivial to everyone.

I think I'll start by writing about failing my Amazon's SDE-2 interviews.

Edits

(2026-06-16) - wording of Why write more

Introduction to View Transitions

2026-01-13T10:30:00.000Z

I've been on a bit of a minimalism kick lately. I've stopped reaching for React for every project, realizing that for a blog like this, raw HTML and CSS is usually enough. In fact, this entire website - content, styles, scripts included - is lighter than the gzipped react-dom package alone.

But there was one thing I missed from the React world: motion.

Static sites often feel "dead." You click a link, the screen goes blank, and the new content appears. I wanted it to feel alive, preserving context as the user navigates, but without bringing megabytes of javascript to hydrate a virtual DOM just to animate a div.

Enter the View Transitions API

Specifically, Cross-Document View Transitions. This API allows the browser to snapshot the old state and the new state, then morph between them. It's native, hardware-accelerated, and requires zero client-side routing, truly magical.

The Chrome team's intro covers the mechanics well, but here is how I'm using it to make this static site feel a little bit alive.

The setup is deceptively simple. You just tell the browser to look out for navigations by adding the css:

@view-transition {
  navigation: auto;
}

When user navigates from the "Home" page to the "All Posts" page, I didn't want a hard cut. I wanted the recent posts to physically travel to their new positions in the full list.

This is made possible with Shared Element Transitions. The concept is simple: if you give two elements on different pages the same view-transition-name, the browser matches them up and handles the geometry.

<!-- On both the Home page and the Blog List page --> 
<li style="view-transition-name: post-item-${slug}">
  <!-- The entire item morphs -->
</li>

Things are a bit more interesting when you click into a specific article. I wanted the title and date to translate from the item and settle into the header of the post.

To make this work, we need to be more granular. Instead of transitioning the whole item, let's assign specific names to the text nodes inside the card.

<!-- In the List Item -->
<li>
  <span style="view-transition-name: post-date-${slug}">2026-01</span>
  <span style="view-transition-name: post-title-${slug}">Introduction to View Transitions</span>
</li>

<!-- In the Blog Post Header -->
<article>
  <h1 style="view-transition-name: post-title-${slug}">Introduction to View Transitions</h1>
  <div class="post-meta">
    <i style="view-transition-name: post-date-${slug}">Published Jan. 2026</i>
  </div>
  <!-- rest of the content -->
</article>

Because the names match, the browser performs a smooth "morph" transition, scaling the font size and translating the position automatically. BROWSER DOES ALLAT FOR YOU, isn't that cool?

Hitchhikers guide to using 'Date' in JS

2023-11-24T10:30:00.000Z

The JavaScript Date API is a nice example of how taxing "We don't deprecate, ever" can get. The Date constructor has six completely different behaviors depending on what you pass it. Not variants. Different behaviors.

// Current time
new Date()
// Milliseconds since epoch
new Date(1736533800000)
// String parsing
new Date('2023-11-24')
// Year, month, day
new Date(2023, 10, 24)
// Year, month, day, hour, minute
new Date(2023, 10, 24, 21, 30)
// Year, month, day, hour, minute, second, ms
new Date(2023, 10, 24, 21, 30, 45, 500)

If you give it an ISO date without a time (just YYYY-MM-DD), it assumes UTC midnight. But if you add a time without the Z, some browsers treat it as local, others as UTC. This isn't theoretical. Chrome and Firefox have behaved differently on this exact case.

The Z matters. Always add it if you want UTC.

// parsing date string
new Date('2023-11-24') // ISO date (no time)
new Date('2023-11-24T21:30') // ISO date with time (no timezone)
new Date('2023-11-24T21:30Z') // ISO date with time (UTC)
new Date('2023-11-24T21:30+05:30') // ISO date with timezone offset

When you pass numbers to the constructor, things get strange fast.

new Date(2023, 10, 24)  // November 24, 2023

Wait. November? We passed 10. Why November?

Because months are zero-indexed. January is 0, December is 11. This comes from C's tm struct from 1972. Java copied it. JavaScript copied Java. Now we're stuck with it. Does that mean 24 is also actually 25? Well...no, days are numbered from 1 to 31.

One more thing:

new Date(2023)      // Not year 2023!
new Date(2023, 0)   // This is year 2023

A single number isn't a year. It's milliseconds since January 1, 1970. So new Date(2023) is 2.023 seconds after the epoch, which is January 1, 1970, 00:00:02.023. So, If you want year 2023, you need at least two arguments: year and month.

But wait, there's more:

new Date(99, 0, 1)   // January 1, 1999
new Date(100, 0, 1)  // January 1, 100 AD
new Date(2023, 0, 1) // January 1, 2023

Years 0-99 get treated as 1900+n. This is Y2K panic code. Someone was worried about legacy code passing two-digit years, so they added this special case. Year 99 becomes 1999. Year 100 is literal.

Guess the Output: A Simple Algorithm

Here's how you would do to predict what the Date constructor will do:

Step 1: Count the arguments

0 arguments? Current time.
1 argument and it's a number? Milliseconds since epoch. Not a year.
1 argument and it's a string? Parse as date string. ISO 8601 is safe. Anything else is a gamble.
2+ arguments? year, month (0-indexed), day, hour, minute, second, millisecond in that order. Everything is in local time.

Step 2: For 2+ args, Check for two-digit years

If first argument is between 0-99, add 1900. Year 25 becomes 1925.
If first argument is 100+, it's the literal year.

Step 3: Month wrapping

Month argument is 0-indexed. 0 = January, 11 = December.
Month 12? Wraps to January of next year, same with larger values. So, new Date(2023, 20) is 01 Sep 2026.
Similarly, Month -1? Wraps to December of previous year.

Step 4: Day wrapping

Days range from 1 to <max_for_the_month>.
Any numbers outside of the range, are wrapped to next/previous month. So, new Date(2023, 2, 32) (allegedly 32nd march) becomes 01 April 2023. Same with negative numbers.

Step 5: Timezone

String with Z? UTC.
String with timezone offset like +05:30? Parses offset but doesn't store it.
String without timezone? Pray.
Number constructor (2+ args)? Always local time.

Step 6: Invalid input

String that doesn't parse? Invalid Date object. No error thrown.
NaN in any argument? Invalid Date.
undefined in any argument? Treated as NaN, so Invalid Date.