Blog — Bojan Delić

Preparing for the Interview

Mon, 16 Feb 2026 00:00:00 +0000

I got laid off recently. The product line was shut down, which is one of those things that just happens. The silver lining was a transition period of a couple of months to keep the lights on and handle knowledge transfer. That bought me time to job search without the pressure of an empty bank account ticking down.

Figuring Out What I Wanted#

Before opening any job board, I sat down and decided what I was actually looking for. Over the years I’ve held both technical and managerial positions (the full history is on my resume). This time I wanted to go back to a purely technical IC role. Partially because that’s the kind of work I enjoy the most, but also because I believe the most effective engineering leaders keep their hands in the code and have a deep understanding of the problems being solved. So, I was looking for Principal/Staff Engineer roles, or even Senior Engineer, since titles often do not reflect actual work being done.

I’ve been fully remote since Covid and had no intention of changing that. Since I was already location-independent, looking at international remote positions was the obvious move.

Beyond that, I had a short list of criteria: strong engineering culture, a product company rather than an outsourcing shop, systems operating at meaningful scale, healthy finances, and no situation where a single large customer dictates the roadmap. That last one is easy to underestimate until you’ve lived it.

Brushing Up#

I hadn’t interviewed in a long time. Some of the companies I found interesting used TypeScript, which I’d never worked with. My background is Python and Go, so this was new territory. I picked up TypeScript by building a small hobby project, leaning on the official docs and AI to accelerate the learning curve. Both of those deserve their own posts. Picking up a new language is the easy part. The time-consuming bit is figuring out the ecosystem and best practices.

LeetCode? No Thanks#

I made a deliberate choice to skip LeetCode preparation entirely.

These kinds of interviews feel obsolete to me. They’re a skill you practice, much like cramming for a math exam in college. You get good at the format, not necessarily at the job. The day-to-day utility of inverting a binary tree on a whiteboard was already questionable before LLMs, and it’s even harder to justify now.

More importantly, I wanted to work somewhere that shares this view and reflects it in their interview process. If a company’s primary signal for engineering ability is algorithmic puzzles, we probably disagree on enough other things that it wouldn’t be a great fit anyway.

I’m fine with live coding as a sanity check, making sure a candidate can actually write code and reason about a problem in real time. That’s different from expecting someone to produce an optimal dynamic programming solution in 20 minutes.

System Design#

System design was where I needed the most structured preparation. I’d never had a formal system design interview before. Working on production systems for over a decade teaches you a lot of what’s relevant, but knowing the material and presenting it well within an hour-long interview are different skills.

I needed to practice the format: how to scope a problem, what to focus on first, how to navigate trade-offs out loud. I also wanted to run through common problem types, because coming up with a solid solution under time pressure is harder when you’ve never thought about the problem before. Take something like designing a timeline feed, the problem Twitter made famous. I’m confident I’d get there eventually, but “eventually” doesn’t fit in a 45-minute slot. Seeing the problem space beforehand means you spend the interview demonstrating judgment instead of fumbling toward a first draft.

I also had specific gaps I wanted to fill. Real-time systems, for instance. I understood the principles but hadn’t worked with the concrete technologies. I looked at some free resources but ultimately paid for a HelloInterview subscription, which turned out to be worth it for the structure alone.

In total, I spent about two weeks preparing. Not full-time. A couple of hours a day. A friend and I ran mock system design sessions using Excalidraw, which ended up being the same tool I used in the actual interviews.

Beyond interview prep, I genuinely learned patterns I hadn’t encountered before. Time well invested. The knowledge doesn’t expire after the interview. It’s there for whenever a real-world problem calls for it.

The Initial Calls#

Every process started with one or more calls with a recruiter or hiring manager. A walk through my experience, what the team looks like, why they’re hiring, how they work. These weren’t formalities. They felt like real gates, and they were also where I learned the most about the company: team size, financial health, level of maturity. Salary expectations usually came up here too. Some companies asked for a number, some offered a range upfront. I appreciated the latter.

Live Coding#

This was the part I was most nervous about. Not because I can’t code, but because I can’t even type properly when someone is watching over my shoulder. Two of the interviews had live coding in TypeScript, a language I wasn’t fluent in, which didn’t help. That turned out to be less of a problem than I expected. The interviewers were great about it and didn’t fixate on syntax, helping me out on small things that would have taken ten seconds to search.

All three live coding sessions were different, which was interesting in itself.

The Take-Home with a Twist#

I got the task upfront and was told to use whatever resources I wanted to prepare, AI explicitly included. The problem was engaging and deceptively simple on the surface, with plenty of room to expand into. I spent nearly a full day implementing, reimplementing, and refining my solution.

During the actual interview, the coding part lasted maybe ten minutes. I walked through my thinking, which approaches I considered, which one I chose, and why. Partway through the code, they stopped me: they could see I’d thought about it and could code, so we shifted to discussing potential expansions. The interview turned into a verbal system design session. I liked this format the most. It removed the usual edge by giving you time to think beforehand, it was genuinely fun, and I think it gives interviewers a richer signal than watching someone sweat through syntax under a timer.

The Two-Hour Work Simulation#

The task was deliberately vague, a couple of lines describing a problem from the company’s domain. It was up to me to use any resource available (Google, AI, and the interviewers themselves) to fill in the gaps, learn the terminology, and figure out what to build. I asked a lot of questions, and they answered. The point was asking the right ones. Sometimes they’d steer me by asking questions back, not always expecting an answer, but nudging me toward discovering something on my own.

The first fifteen minutes were intense. The problem was unfamiliar and someone was watching me fumble through it. After that initial stretch, I settled in and actually enjoyed it. It felt like a realistic preview of what the first weeks on the job would be like.

The Straightforward Modeling Exercise#

The simplest of the three, modeling a small system that was a subset of the company’s actual product. No AI, no Googling, TypeScript required. I knew enough to solve it, but didn’t have every generics syntax detail memorized. I explained what I was trying to do, and the interviewer helped with the specifics. Since I’d been upfront about TypeScript not being my primary stack, this wasn’t held against me. The coding itself was more of a sanity check, because it was paired with a system design interview the same day, and if both went well, the next step was a paid trial, which carried the most weight in their process.

Interviewing the Company#

Throughout all of this, I was evaluating the companies as much as they were evaluating me. The interview process itself was the clearest signal. What skills did they test for? Did the tasks reflect actual work, or were they performative? How fast did they respond after each round? A company that takes two weeks to schedule a follow-up is telling you something about how they operate.

The type of coding challenge said a lot too. The ones that gave me room to ask questions, explore the problem, and show judgment felt like places where engineers are trusted to think. The ones that locked everything down and measured speed felt like places where output is measured in lines of code.

How It Landed#

I ended up with three offers. The one I accepted was from the first company I applied to, and the only one I had specifically targeted. The other two came through LinkedIn outreach and my professional network.

Those weren’t the only companies I pursued. A few others I’d specifically targeted never went anywhere. Some rejected my CV outright, others weren’t hiring in my timezone. Getting past that initial barrier is harder than it sounds. Having a referral from someone inside the company makes a real difference at that stage, often the difference between a silent rejection and an actual screening call. After that first conversation, though, it stops mattering. You’re on your own.

Looking back, the preparation mattered more than I expected, but not just for the reasons I assumed going in. The system design practice filled real gaps in my knowledge. The live coding sessions turned out to be the most enjoyable interviews I’ve ever had. And going through different interview formats gave me a surprisingly clear signal about which companies I’d actually want to work at. The ones with thoughtful processes tended to be thoughtful about other things too.

The layoff forced a reset I wouldn’t have chosen on my own, at least at that point in time. But having that transition period, time to decide what I wanted, learn a new language, practice system design without rushing, meant I could be genuinely selective instead of just grateful for the first yes. I knew what I was looking for before I started.

Building This Website

Thu, 12 Feb 2026 00:00:00 +0000

My previous personal website was a Hugo site with a stock theme that I set up once and never really touched again. It worked, but it felt like it belonged to someone else. I wanted to rebuild it from scratch with a custom theme and proper modern web practices. Instead of writing all the code myself, I’d use Pi — an AI coding agent for the terminal — and see how far I could get by just describing what I want and steering the implementation.

The Stack#

I already had a Hugo site, so staying with Hugo was a non-decision. It’s fast, it’s a single binary, and the templating is straightforward enough. The goal was a personal site with four sections: blog, projects, resume, and quotes. No JavaScript frameworks. No build tools beyond Hugo itself. Deploys to Cloudflare Pages via GitHub Actions.

The whole thing took two evening sessions. Most of my time went into reviewing output and making decisions — the agent did the actual coding.

Custom Theme from Scratch#

The stock theme had to go. The agent built a custom one under themes/minimal/. The CSS landed in six focused files (base.css, layout.css, article.css, sections.css, responsive.css, syntax.css) that Hugo Pipes concatenates and fingerprints into a single output file at build time.

Design tokens live as CSS custom properties in base.css. The entire color scheme, spacing, and typography can be adjusted by tweaking a handful of variables. Light and dark mode is just swapping those properties, with the toggle being the only JavaScript on the site. It reads the OS preference on first visit, allows manual override, and persists the choice in localStorage.

Data-Driven Sections#

Rather than creating individual content pages for projects, resume, and quotes, these sections are driven by YAML files in data/. The projects page reads from data/projects.yaml:

data/projects.yaml

- name: ligno
 url: https://github.com/delicb/ligno
 description: Logging library for Go
 tech: [Go]
 featured: true

- name: slogbuffer
 url: https://github.com/delicb/slogbuffer
 description: Buffer handler for slog
 tech: [Go]

Projects marked featured: true render as larger cards in a responsive grid at the top of the page. Everything else shows up as a compact list below. Promoting or demoting a project is a one-line YAML change.

Resume and quotes work the same way — templates iterate over data files, nothing is hardcoded twice.

Blog Features#

The blog picked up a few features along the way:

Pagination uses Hugo’s built-in .Paginate with 10 posts per page. The list layout went through a revision after the first version placed the date awkwardly in the middle of each row. In the final version, the title and reading time are stacked on the left, with the date pushed to the right.

Reading time uses Hugo’s .ReadingTime variable. It shows up on both single posts and the list page.

Cover images are convention-based. Drop a cover.* file into a post’s page bundle directory and the template picks it up automatically via .Resources.GetMatch "cover.*". No front matter configuration needed.

The include shortcode was the most interesting piece. I wanted to embed code from actual files in a post’s directory, not just inline code blocks. The agent built themes/minimal/layouts/shortcodes/include.html with support for line ranges, line numbers, and line highlighting:

{{< include file="setup.py" lines="11-27" linenos="table" hl="19-20" >}}

The tricky part was line highlighting. The hl parameter takes original file line numbers, but Hugo’s highlight function expects line numbers relative to the displayed block. So if you’re showing lines 11-27 and want to highlight line 19, the shortcode translates that to line 9 internally. This took a few iterations to get right. The agent’s first implementation didn’t account for the offset, and the highlighted lines were wrong. After I pointed it out, it fixed the translation logic and it’s worked since.

Language detection is automatic from the file extension, with an optional lang parameter for overrides.

SEO and Meta#

I asked the agent to fetch the old live site and compare. It came back with a list: no favicons, no Open Graph tags, no RSS feed, no canonical URLs, no sitemap, no structured data.

I pointed the agent at a photo in my Downloads folder and it generated favicons in all standard sizes (16, 32, 180, 192, 512px, plus .ico) using sips and ImageMagick. The same photo became the default Open Graph image.

The <head> partial now includes Open Graph and Twitter Card tags generated from each page’s front matter, with blog posts using their cover image when available. There’s JSON-LD structured data as well. The homepage gets a Person schema with sameAs links to GitHub, LinkedIn, and X, while articles get a BlogPosting schema. Canonical URLs are on every page. RSS is enabled for the blog section with auto-discovery via <link rel="alternate">, and the sitemap is auto-generated by Hugo.

Security and Headers#

Cloudflare Pages supports a _headers file for setting HTTP response headers. The agent created static/_headers with some basic security hardening.

/*
 X-Content-Type-Options: nosniff
 X-Frame-Options: DENY
 Referrer-Policy: strict-origin-when-cross-origin
 Permissions-Policy: camera=(), microphone=(), geolocation=()

A security.txt file went into static/.well-known/ following RFC 9116, with contact email and an expiry date that needs annual renewal.

For analytics, I went with Cloudflare Web Analytics over Google Analytics. It’s free, doesn’t require cookies, and since the site is already on Cloudflare, enabling it is just a toggle in the dashboard. No code changes, no tracking scripts.

Deployment#

The CI pipeline is a straightforward GitHub Actions workflow. Checkout, build with hugo --minify, deploy to Cloudflare Pages via Wrangler. Maybe ~50 lines of YAML total.

The Cloudflare API token only needs the Account > Cloudflare Pages > Edit permission. The agent initially suggested using the “Edit Cloudflare Workers” template, which bundles a bunch of unnecessary permissions. When I questioned it while setting up the token, it confirmed the minimal scope was sufficient. Small thing, but this is exactly the kind of detail where having a human in the loop matters.

Contact Form#

The contact page turned out to be the most frustrating feature to ship. The idea was simple: a form that sends me an email, protected from bots. Cloudflare Pages Functions handle the backend, so the form submits to a TypeScript function at /api/contact that forwards the message via Resend’s API. A honeypot field catches dumb bots, and Cloudflare Turnstile handles the rest.

Except Turnstile didn’t work. For hours. The widget rendered fine, tokens were generated, but every single verification request came back with invalid-input-response. I rotated keys, recreated the widget, triple-checked the secret, logged everything. The agent and I went through every possible cause: wrong secret, wrong domain, Bot Fight Mode, token encoding issues. We rewrote the verification logic from scratch, tried inlining it instead of using the middleware, compared headers and payloads. Nothing worked. Eventually, in desperation, we switched to the official @cloudflare/pages-plugin-turnstile package, which handles verification as middleware before the request even hits the function. That worked. We tried reverting to the manual approach to isolate the root cause, and it broke again. So the plugin stayed.

I’m still not entirely sure what was wrong with the manual implementation. The plugin does essentially the same thing, just packaged differently. It might have been a subtle issue with how the form data was being consumed before the token could be verified, or some Cloudflare-internal behavior the plugin accounts for. Either way, it works now, and I’ve accepted that some debugging sessions end with “it works, don’t touch it” rather than a satisfying root cause.

Working with a Coding Agent#

The entire site was built through Pi, a terminal-based coding agent, using Opus 4.6. Pi is turning out to be way more enjoyable than Claude Code. I really dig the minimalism — and the fact that you can ask it to create its own extensions and skills, then use them in future sessions. For this site I had it generate four skills: blog post review, Hugo dev server management, Lighthouse auditing, and new post scaffolding. Now when I say “run a Lighthouse audit” or “create a new blog post,” it already knows the project structure, the right commands, and where everything lives.

Some things landed on the first try — data-driven sections, the deployment pipeline, security headers.

Other things needed iteration. The include shortcode’s line highlighting was wrong on the first pass. The blog list layout needed a redesign after the initial version didn’t look right. The _headers file syntax confused me because /* looks like an unclosed comment, and the agent explained it’s actually a URL wildcard pattern in Cloudflare’s config format. I never used _headers so this is something I learned along the way.

There were also moments where the agent proactively caught things I hadn’t thought about. When it fetched the old site to compare, it identified six missing features I would have shipped without. When I asked about adding a homepage photo, it laid out pros and cons and I decided against it. When it suggested Google Analytics, I asked about alternatives and it pointed me to Cloudflare’s built-in analytics.

The division of labor was simple: I decide, it builds. I’m not reviewing every line of CSS it generates, and honestly I could not even if I wanted to since I never bothered to learn CSS properly. But I am deciding what the site should have, how it should behave, and when something doesn’t look right. The tedious parts — six favicon sizes, JSON-LD schemas, pagination edge cases — would have slowly drained my motivation. The agent knocked them out in seconds.

I don’t think I would have shipped a site with this level of polish in two evenings on my own. Not because any individual feature is complex, but because the number of small tasks adds up fast. Having an agent that can knock out each one in seconds while I focus on the bigger picture made the whole process genuinely enjoyable.

The source is on GitHub if you want to look at the result.

Hello world

Wed, 11 Feb 2026 00:00:00 +0000

hello_world.py

class Greeting:
 def __init__(self, target="World"):
 self.target = target

 def __str__(self):
 return f"Hello, {self.target}!"

class EnthusiasticGreeting(Greeting):
 def __str__(self):
 base = super().__str__()
 return base.upper() + "!!" + " 🎉" * 3

class ShyGreeting(Greeting):
 def __str__(self):
 return f"oh... um... hi, {self.target}... i guess"

def main():
 for cls in [Greeting, EnthusiasticGreeting, ShyGreeting]:
 print(cls())

if __name__ == "__main__":
 main()