dtg

Emacs as an Agentic Coding Environment

2026-10-15T14:51:00Z

After evaluating and using agentic coding tools for the better part of the year, and now finally integrating them into my development workflow, the most salient question inevitably came to mind: how do I make this work in Emacs?

Background: My Emacs Journey

I am an Emacs lifer. Other than Notepad or TextEdit, I can't recall using another editor before it, and it was the editor I wrote my first line of code in. Since picking up Emacs, I've seen numerous editors and IDEs over the years, but none of them stuck with me or interested me as much as Emacs.

I can't place the exact date, but my journey with Emacs started back in the late aughts. Unsurprisingly, my first encounter with it coincided with my first experience using Linux. Back then—I think it was in 2008 or 2009—the netbook craze was in full swing, so I bought an Asus EEE PC on a lark, then quickly discovered how underpowered it was running the preinstalled OEM version of Windows 7. I decided to give Linux a try and installed Xubuntu, which was suitable for my low-spec netbook.

My main machine at the time was a 1st gen Intel Macbook Pro, which I bought in 2006. I was using it primarily for digital audio projects, and though I wasn't yet into programming, my interest in audio technology brought me within close proximity to it. Later, influenced by a fellow audio technology enthusiast, programmer, and friend, I eventually started using SuperCollider, which opened up an entirely new world to me.

After installing Xubuntu on my netbook, my first order of business was to install SuperCollider and continue my audio experiments there. However, SuperCollider, being primarily a MacOS focused project, did not ship their SCIDE integrated development environment to Linux. The only two options were Vim and—you guessed it—Emacs. For better or for worse (some might say worse… and they might have a point 😅), I chose Emacs.

The rest, as they say, is history.

Using Claude Code and Codex CLIs with Vterm

Back to the topic at hand. My first attempt at integrating Claude and ChatGPT found me running Claude Code and Codex (respectively) using vterm, a modern terminal emulator for Emacs. On second thought… allow me one more, brief diversion into Emacs terminals before we get into vterm.

A Brief Technical Note on Emacs Terminals

Proper terminal emulation has long been considered the missing link for Emacs users wanting to do everything from within Emacs, as most of the available options are pretty limited.

For example, the built-in term is written in Emacs Lisp, which runs in a single thread. It creates a shell sub-process that in turn allocates a pseudo terminal for receiving and interpreting shell commands. Emacs handles user input, which it then parses and sends as a string to the sub-process.

From there, an event handler function called a process filter handles output generated by the sub-process. Roughly, the process filter:

processes each byte, one at a time, transforming each byte into an Emacs text object,
applies faces for color and styling,
updates the cursor position, handles scrolling, etc.,
then renders the output to the buffer.

This is slow when compared to a purpose-built terminal emulator app, which can take advantage of multiple operating system threads and are designed to stream large volumes of text quickly. Terminal emulator apps also implement a much larger subset of terminal escape codes than term, so they are much better suited to running rich TUI applications like Claude Code or Codex.

Enter Vterm

Emacs vterm, which is itself based on libvterm, addresses a lot of these issues. In short, it gets around the limitations of Elisp terminals by delegating emulation to an efficient C library, which Emacs loads as a dynamic module. Vterm fully controls parsing of terminal escape codes and maintains the state of the terminal, tracking whether the virtual terminal screen needs to be updated and periodically writing updates in batches to the Emacs buffer.

It's about as smooth of a terminal emulation experience as you're likely to get from within Emacs.

Configuration

To install vterm, I first needed to install a number of dependencies described in the README From there, adding the dependency via use-package is as simple as the following bit of elisp:

(use-package vterm
  :ensure t)

From there, it is just a matter of firing up a terminal and running Claude or Codex as one normally would.

Testing

While this generally works well enough, it wasn't long before some annoyances started to appear. For example, Claude seems to use the /tui fullscreen setting by default, and while this works great in a dedicated terminal emulator app, it causes problems in Emacs:

vterm scrollback doesn't work. while this isn't a problem for native terminals, this doesn't really work with vterm due to Claude Code's alternate screen buffer design.
claude's scrollback is limited to 2000 lines.

The alternative that I landed on was to just use the /tui default setting, which at least allows me to scroll back—although, even there, I need to enable vterm-copy-mode if Claude is in the middle of writing something, as vterm will automatically scroll to newly written output. Additionally, to avoid quickly exhausting the scrollback limit, I needed to update my config accordingly:

(use-package vterm
  :ensure t
  :init
  ;; Increase max scrollback so it isn't quickly exhausted
  ;; for longer sessions.
  (setq vterm-max-scrollback 100000))

There are still yet other annoyances, for example redrawing issues causing line heights to shift and seemingly lose focus on prompt inputs, among others. This seems to happen quite often when resizing the window containing the vterm buffer, and it creates an absolute visual mess.

It seemed like there has to be something else out there.

More Bells and Whistles with Claude Code IDE

By the time I arrived at Claude Code IDE for Emacs, I was using Claude Code for the majority of my agentic coding "needs", and was hoping to find a solution that addressed many of the problems I encountered using the vanilla vterm and claude setup I described earlier. From the README:

Claude Code IDE for Emacs provides native integration with Claude Code CLI through the Model Context Protocol (MCP). […] Transforms Claude into a true Emacs-aware AI assistant that works within your existing workflow and can interact with your entire Emacs ecosystem.

Sounds promising.

Configuration

Installing Claude Code IDE via use-package is also straightforward:

(use-package claude-code-ide
  :ensure t
  :vc (:url "https://github.com/manzaltu/claude-code-ide.el" :rev :newest)
  :bind (("C-c '" . claude-code-ide-menu))
  :config
  (claude-code-ide-emacs-tools-setup))

Note, since the package is not available via MELPA, I have to explicitly set the version control host and point it at the author's Github repository. I've also added a key binding to bring up the IDE menu, which uses Transient. Also, in order to enable MCP integration between Emacs and Claude, I instruct Emacs to evaluate the claude-code-ide-emacs-tools-setup function after the claude-ide-package loads.

Testing

Claude Code IDE definitely improves upon the vanilla vterm setup I described earlier.

The first thing I noticed after starting a new session interactively via claude-code-ide, Emacs opens and displays a vterm buffer running Claude in a side window, and it shows the current file I am visiting, which is a nice touch.

The automatic layout Claude Code IDE chooses is not ideal on my 14" laptop, as it occupies most of the Emacs frame. Adjusting via (enlarge|shrink)-window-horizontally works, but this still seems to intermittently cause the redrawing issues mentioned above.

Also, since I am used to hiding buffers with delete-window, delete-other-window etc, which don't work in this setup, I instead invoke the claude-code-ide-menu function interactively and use the w key to quickly toggle the side window. This is just a minor workflow adjustment, and the transient menu is nice enough that this isn't a major issue for me.

Some of the more interesting bits with this setup is the MCP integration with Emacs, which allows Claude to interact with various Emacs capabilities from within Claude Code. Querying Claude code about those capabilities, it shows the following:

| Tool                       | Use it for                                  |
|----------------------------|---------------------------------------------|
| `imenu-list-symbols`       | Outline of a file: functions, headings      |
| `xref-find-references`     | Where an identifier is used                 |
| `xref-find-apropos`        | Search symbols by pattern                   |
| `treesit-info`             | Tree-sitter syntax tree at a spot in a file |
| `project-info`             | Project root and metadata from project.el   |
| `mcp__ide__getDiagnostics` | flycheck/flymake errors and warnings        |

For example, running project-info at the prompt (notably, it is not a slash command) reports various info regarding the project, including the project root, and the number of files contained within the project. Neat.

Prompting Claude to run xref for a file within an Elixir project I am working in doesn't yield much:

|   Tool                    | Query            | Result                                    |
|---------------------------|------------------|-------------------------------------------|
| `xref-find-references`    | `compare_answer` | No references found                       |
| `xref-find-apropos`       | `batchim`        | One hit: korean.ex:125, `def has_batchim?`|

In my tests, Claude cannot detect whether the Emacs language server is running, so I tell them that eglot is indeed running. Claude suggests that the MCP tool itself is problematic, so I ran xref-find-references for the compare_answer function from within the buffer containing the relevant file, with eglot running, and sure enough it found many references to it in other project files. It seems like this particular MCP tool is not quite there yet, unless I am doing something wrong (which is probable).

That said, I don't think I would use many of these tools via a Claude query anyway. If I am running xref-find-references or imenu-list-symbols, I am most certainly doing that from within the source code buffer as I am bopping around the code.

I do like the idea of using a transient interface to interact with the Claude process, and it is nice to be able to send a prompt from within the minibuffer to get around the usual multiline prompt annoyances (I always forget to use C-j instead of Shift+Return). But a lot of the problems with vterm and claude I described above still exist here, and the split between the transient interface and the claude terminal buffer creates a workflow that feels a bit disjoint.

Overall, though, it is a net improvement over the previous solution. I also understand that, supposedly, the Eat terminal emulator provides a better experience with Claude Code IDE when compared to vterm, particularly with regard to the line-wrapping woes I experienced with the latter. But I have yet to try it out.

Local Coding Agents with Ollama and Aidermacs

While settling into a reasonable workflow with Claude Code IDE, I also wanted to explore local LLMs for agentic coding. Armed with a new Macbook Pro with 24GB of RAM, I figured it was time to give it a try.

The first solution I explored for a local LLM setup was Aider, an agentic coding application written in Python. It supports both cloud-based backends like Claude, as well as local models hosted via Ollama, or apparently any other model that supports an OpenAI compatible API. And, naturally, there is an Emacs project called Aidermacs, which integrates Aider with Emacs.

Configuration

First, I needed to install Aider, per the docs:

python -m pip install aider-install
aider-install

Then, as per usual, I installed aidermacs via use-package. Since I wanted to use aider with a local Ollama server, I specify a hook function to tell aider where the Ollama API base URL is located:

(use-package aidermacs
  :ensure t
  :bind (("C-c a" . aidermacs-transient-menu))
  :hook
  ((aidermacs-before-run-backend . (lambda ()
                                     (setenv "OLLAMA_API_BASE" "http://localhost:11434")))))

Aidermacs implements a simple shell written in Emacs Lisp using Comint mode. While certainly not as fast as vterm, it is not meant to be a terminal emulator and it doesn't need to be. It feels a lot more Emacs-y a result. Aidermacs also exposes a transient interface, similar to Claude Code IDE, which I found myself using a quite a bit when adding files to the agent's context (this becomes important when dealing with local models and context length limitations; more on that below).

Testing

Ultimately, the headaches of dealing with Aidermacs really had little to do with Aidermacs as such, and more to do with working with highly constrained, under-resourced local model. I had to do a lot of tuning so that it was "usable" for agentic coding (which is to say, barely, at least outside of smaller, tightly constrained tasks).

By default, Ollama's context length term is very small for anything less than 24 GB of GPU addressable RAM; with my 24 GB of unified memory the context is limited to 4k tokens, so the model I was working with, qwen3-coder:30b, would keep showing me an error like this after every prompt:

Empty response received from LLM. Check your provider account?

Tokens: 1.6k sent, 0 received.

Basically the context is exhausted and the model sends back an empty reply. I was able to resolve this issue specifying the num_ctx parameter in the .aider.conf.yaml for the project:

model: ollama_chat/qwen3-coder:30b
  extra_params:
    num_ctx: 32768 # This can be set globally via `OLLAMA_CONTEXT_LENGTH`

Trying again, the fans really started to kick into high gear on my laptop. I noticed the Aidermacs shell prompt just kept spinning, but when inspecting the Ollama server via ollama ps, there was no Qwen3-Coder process running. I checked the activity monitor and it showed resident memory nearly maxed out. Since I neglected to inspect the Ollama logs, it wasn't clear what Ollama was up to, whether it was attempting to read/write swap or something else entirely—but my system started slowing to a crawl so I was desperately trying to kill the Ollama server process. Oops.

On a subsequent attempt, I tried a more reasonable value of 16,384 tokens. The system no longer falls over, though the CPU still works very hard. The results are fine, but nothing to get too excited about.

That said, it does seem OK for very simple things. A unit test here, a short shell script there. The other day I had it write a simple waveform plotter, which worked out reasonably well, even though it used Matplotlib instead of the GNU Plot, despite instructing it to use the latter. 🤦

With respect to Aidermacs as such, an interesting workflow consideration is that Aider tightly integrates with Git and therefore assumes you want to use Git. If the directory you are working in doesn't contain a Git repo, it will ask you to create one. It also automatically commits every change. If a particular commit doesn't really do what it says it does, which seems to be the norm when working with local LLMs, you're gonna be typing the /undo command a lot. While you can disable auto-commits, the Aider documentation recommends against it.

Given my frustrations with the local LLM output and my mild irritation at Aider's opinionated workflow preferences, I put Aidermacs down for a bit and retreated to Claude's warm embrace. And for this next, albeit brief, phase, I stopped experimenting and decided to use a setup that was a bit more familiar.

Terminal Emacs with Ghostty, Tmux and Claude Code

OK, I let Claude dictate the process in this brief, Emacs GUI-less interregnum. But I went with a reliable, well-worn solution: cracking open a good, proper terminal emulator in Ghostty, dusting off my tmux config, and running Emacs and Claude in separate tmux windows. Hey, it works—and font rendering and terminal colors in Ghostty look pretty dang good. But still, after about a solid week using this setup, I found myself longing for GUI Emacs. Surely, there's got to be something else I can try, in my never-ending quest for Emacs glory…

Agent-shell and a Unified Emacs Experience

After hearing from a fellow Emacs user and their own experience going through a similar journey, they recommended that I look at agent-shell, so I did precisely that.

From the README, Emacs agent-shell is billed as

A native Emacs shell to interact with LLM agents powered by ACP (Agent Client Protocol).

Rather than relying on a vendor-specific TUI, agent-shell uses ACP; ACP is to agents what LSP (Language Server Protocol) is to programming languages. In other words, it solves the problem of each editor having to implement custom integrations for various agents, as long as the client and the API server used to interact with the agent implement the protocol.

Like Aidermacs, agent-shell uses the familiar comint to implement it's shell functionality, and it also supports a transient interface for interaction, so we're in familiar Emacs territory.

Configuration

For Claude Code, I needed to install an separate, external ACP client to interact with the Claude Code agent. Via npm:

npm install -g @agentclientprotocol/claude-agent-acp

As per usual, I then installed the package via my Emacs init file:

(use-package agent-shell
  :ensure t
  :config
  ;; Uses login-based authentication by default
  (setq agent-shell-anthropic-authentication
        (agent-shell-anthropic-make-authentication :login t)))

Seeing that agent-shell supports multiple different models, I also wanted to test it with my local LLM setup, which is exposed via the OpenCode ACP client, which I install via my package manager:

sudo port install opencode

Some additional configuration is required to make it work with Ollama, by adding the latter as provider to the OpenCode configuration at ~/.config/opencode/opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "ask",
    "bash": "ask",
    "webfetch": "allow"
  },
  "provider": {
    "ollama": "qwen3-coder:30b",
    "npm": "@ai-sdk/openai-compatible",
    "options": {
      "baseURL": "http://localhost:11434"
    },
    "models": {
      "qwen3-coder:30b": {
        "name": "Qwen3-Coder 30b"
      }
    }
  }
}

A dummy API key also needs to be configured, apparently:

{
  "ollama": {
    "type": "api",
    "key": "ollama"
  }
}

With my configuration in place, I am ready to go.

Testing

While I haven't spent too much time with agent-shell, I am already feeling like this is possibly the best solution for me, at least for now. Similar to Aidermacs, the comint-based shell and transient interface gives it a distinctly Emacs feel. Naturally, I spent most of my time with the Claude ACP client, and it worked wonderfully.

In particular, the shell felt comfortable and interactive enough without feeling cluttered. Tool prompts are rendered in the shell as buttons, which can either be clicked (useful for graphical Emacs) or executed via single key bindings. For example, when the agent writes code and proposes a change, it presents an option to view the diff. If I click the v key, I am presented with an easy to read diff that I can accept or reject. And, like Aidermacs, the output isn't prone to weird text rendering issues and line height shifts as seen in vterm.

I also had a bit more luck running local agents this time around when pairing qwen3-coder:30b with the OpenCode provider. While it is still a far cry from Claude Code, I tuned my Ollama configuration well enough by this point that it worked OK for smaller coding tasks. To be clear, this has little to do with agent-shell. And, at least until either my hardware or the technology improves, I think I will continue to get better use out of local LLMs when using them as chat interfaces, e.g. with Ellama, rather than as coding agents.

Still, like Aidermacs, it's nice to know that I can use both local and other LLMs with this solution. If I want to spin up a Claude Code or Codex session alongside a local one, it's as easy as invoking agent-shell interactively (or the agent-shell-help-menu) and starting another session with the desired provider. Unlike Aidermacs, it also doesn't assume I want to use Git for every project.

Conclusion

For a long-time Emacs user such as myself, there are now a lot of options for working with coding agents without leaving the confines of Emacs.

While vterm paired with the Claude Code CLI is a perfectly workable solution, the small annoyances with terminal emulation within Emacs started to grate. Aidermacs seemed like a good alternative, given its comint and transient style interface, but my frustration getting it to work using local LLMs and it's opinionated workflow constraints steered me away.

After a brief return to running Emacs side-by-side with Claude Code via Ghostty and tmux, I found Agent Shell, which, like Aidermacs, can integrate with multiple LLM providers and uses a more Emacs native feel. Unlike Aidermacs, it doesn't impose a Git-centric workflow and the shell itself is a bit more interactive and user friendly.

False Starts and New Beginnings

2026-07-10T10:55:00Z

Well, after a good deal of thought, we've decided to relocate to South Korea. My partner and I have been talking about it for years, but we never seriously considered it, until recently.

Like many Americans (or, at least those that have been paying attention), I was partially motivated by the re-election of DJT, and more importantly what that portends for our democratic republic. And while I readily admit to being a pessimist, things do not look great.

But there were more practical concerns. Chief among them: my partner wanted to be closer to family. Also, when we made our decision, I was in the midst of a long unemployment cycle and there was no clear sense of when I would be able to find stable employment, unlike previous cycles. While we were able to cover mortgage payments and other expenses during my partner's busy season, things would get more difficult once her busy season ended.

We talked about what it might be like to cohabitate with eomeoni (my mother-in-law), since finding an apartment on our income was not going to be realistic, at least not for the foreseeable future. Assuming that arrangement would work for everyone, my partner ran through the numbers, and came to the conclusion that life in South Korea would be more affordable. Health insurance is cheaper, exchanges rates are favorable, and the cost of food and transportation are generally more affordable (although how long that will last, who knows…). Plus, if we could sell our house, that would give us a significant financial buffer while I search for employment.

Shortly after my partner's busy season ended, I somehow managed to land an offer for a fully remote Senior Software Engineer position in the US. It was a bit of a downgrade salary-wise compared to my last role, but it was an exciting opportunity, and it seemed to be a great fit. Even so, we decided to move forward with our plans to relocate. Though I was unsure if I could make it work with my new employer, having some income to finance our move in the interim was definitely going to help, so I decided to take the offer. Two months later… well, suffice it to say, it didn't end up working out.

Obviously this came as a disappointment, since I worked very hard to search for my new job, and I was finally starting to get my footing and contribute meaningfully. Plus, the job market for software engineers seems to be getting more competitive by the day, not just in the US but also in South Korea. But, such is life, I guess. Time to start thinking about the next thing.

I only have a vague idea about what that "next thing" is, and I am not entirely sure what's in store for me and my family as we start our new life in South Korea. My feelings on this big life change contain a mixture of apprehension, excitement, sadness, but also—dare I say—optimism.

Top 5 Guitarists of All Time (Or, Just Those I Am Listening to Now)

2026-05-31T21:39:00Z

The other day, a good friend of mine asked me over the group chat who my "Top 5 Favorite Guitarists of All Time" are. Since answering that question is impossible, I am instead going to name the first five guitarists I could think of based on songs I have been listening to recently. So, keeping that recency bias in mind, here they are (in no particular order), some of my favorite guitarists:

George Benson

Most listeners will recognize George Benson from his 1976 smash hit "Breezin'", which helped usher in the smooth jazz era and for a time was a fixture of supermarket background music heard across America (alongside Chuck Mangione's "Feels So Good"). But don't get it twisted—George Benson is a certified guitar hero. I am most familiar with his output on CTI records, because records released on that label were very easy to find on the second-hand market back when I was collecting a lot of vinyl. Here is one such song from his 1976 album, Bad Benson, called "The Changing World" (hip-hop fans may also recognize this one):

Scott Henderson

I first heard Scott Henderson by way of The Chick Corea Elecktric Band, specifically their eponymous debut album. And while credit goes to Carlos Rios for the guitar work on my favorite song on that album, "Cool Weasel Boogie", Henderson contributed some fantastic guitar work on that album as well. That said, the latter is probably more well known for his output with his band, Tribal Tech. Their 1987 track "Mr. Hee" is a standout, with it's mysterious Eastern (albeit somewhat Orientalist—check the album cover) feel, glassy FM keyboards, and phenomenal lead and rhythm guitar work by Henderson.

Chuck Schuldiner / Andy LaRocque

OK, I am kinda cheating on this one because I've listed two guitarists here. But bear with me, because both are integral to the amazing guitar work heard on Death's "Trapped In A Corner", from the 1993 album Individual Thought Patterns. Death was essentially Schuldiner's project, with various players drifting in and out of the rotation over the years. King Diamond's Andy LaRocque makes a guest appearance here, offering a jaw-dropping solo at the track's midpoint, accompanied by Chuck's potent, syncopated riffing. Chuck adds his own blistering solo to close out the proceedings. This really represented the apex of technical death metal and guitar pyrotechnics at the time, and it remains to this day a classic of the genre.

Wes Montgomery

Arguably the best jazz guitarist of all time, Wes Montgomery's influence on both jazz and generations of guitarists is undeniable. In particular, I love his solo on the Gary McFarland penned "13 (Death March)", which appears on the 1968 collaborative album Jimmy & Wes: The Dynamic Duo album, co-starring Hammond B3 virtuoso Jimmy Smith. Wes' guitar solo is a masterful demonstration of musical restraint and melodic phrasing, and his octave vamps are instantly recognizable.

Tony MacAlpine

I listened to a lot of shredders when I was in high school, back when I was (somewhat) seriously pursuing guitar. Naturally, I listened to Yngwie Malmsteen, Steve Vai, Joe Satriani, and Tony MacAlpine. And of course, Eddie Van Halen and Randy Rhoads were both huge influences on my musical education. That said, outside of Eddie & Randy, I don't really listen to those guys that much anymore, but I do find myself going back to Tony MacAlpine regularly. While he can obviously shred like nobody's business, more importantly, he writes good songs with interesting melodies. As far as albums go, I think Maximum Security is probably his most cohesive and consistent effort from his eighties hair metal phase. But if I had to name one song, it would be "Stream Dream", off of 1992's Freedom To Fly. It is such a euphoric, energetic, and wonderful song. Also, it totally reminds me of console games I played growing up in the 90s, imbuing it with a nostalgic quality that brings me a lot of comfort.

Job Search 2026

2026-04-21T13:20:00Z

After roughly 4 months of searching for a software engineering job, I've come away with a few observations, along with some other stray thoughts that seem worth sharing, regarding my personal experience in current job market.

Specialists Over Generalists

As a software generalist, my skills are all over the map. I have worked in startups mostly, in various languages, and in different tech stacks. My polyglot, "jack of all trades, master of none" background seems particularly ill-suited to this very competitive market.

Though I am searching for backend product engineering roles, because I am also looking primarily at companies that require Go programming skills, most of the open Go roles I've seen are focused more on platform engineering. This makes sense, as Go is a language that is particularly well suited to a lot of platform engineering tasks. Typically, these roles require a fair amount of experience with container orchestration technologies, in particular Kubernetes. Since I don't have a ton of professional experience with Kubernetes, I am finding trouble positioning myself with hiring managers for these types of roles.

While I have some experience in web operations and "DevOps" more broadly (CI/CD, automation and the like) and full-stack development, my skills are not current enough or specialized enough to be seriously considered for these types of roles.

Tech Stack Alignment / "What Have You Done for Me Lately"

At the other end of the spectrum, I interviewed for a role to lead a development team writing code for a monolithic Ruby on Rails application. Here, too, I failed to pass muster. Per a former colleague, who was kind enough to refer me to the hiring manager, I learned that one of the main reasons for my rejection was because I didn't have recent experience with Rails, despite the fact that I had shipped successful solutions to production using Ruby on Rails in the past.

On the other hand, for a platform engineer role I applied to, I was able to get a screening call based on adding Temporal and NATS experience on my resume from my most recent role. So it seems like tech stack alignment and recency in that tech stack is particularly important now.

Technical Screens

I encountered most of the usual suspects for technical screens, but also one new format that I hadn't experienced (more on that below). Notably, companies appear to be utilizing pre-interview screening assessments more frequently than in past interview cycles.

LeetCode… Yay

Of course, there are your LeetCode style assessments. These were always annoying, and are now even more so, in part due to rampant AI-assisted cheating and interview fraud making the experience worse for everyone. What this translates to in practice is use of proctored tests. In one such test, I had to turn my camera on, solve a sequence of contrived algorithm problems, and explain my thought process throughout. The test proctor didn't interact with me outside of warning me when time was almost up. Then there are the ones where you have to use Codility or CodeSignal or any of the other enumerable web editors with automated test harnesses and the like. The unifying theme here is no interlocutor to bounce ideas off of or converse with. Not fun.

Pair-Programming? Yay!

One company I interviewed with for a senior engineer role conducted the interview using a structured pair-programming format. I was asked to implement an API endpoint for an inventory system, optimizing for read performance and integrating with a SQL database. I discussed how I would test it, scale it, and how it could be extended for future requirements. In other words, it focused on a real-world engineering problem. Fun, actually!

The "Take-Home"

Then, there are your so-called "take-home" projects. While I often enjoy these for the sake of learning, they tend to be a big time-sink and tend to have a low success rate. The ones that do get through, I end up spending at least double the amount of time stated to solve the problem. As an interview format, it feels too squishy and subject to the whims and biases of the person reading the code to be worthwhile, but I know a lot of people prefer these to the live coding interview format.

Uh...

That leaves the weirdest one: a cognitive aptitude test. Specifically, the Criteria Cognitive Aptitude Test (CCAT), which I guess is a thing some companies are asking candidates to do now? I hate any and all standardized tests, so I opted out of this one, especially since the remainder of the interview process was going to be a gauntlet anyway.

Screen & Roll

While unfortunate, I can see why companies use pre-interview technical screens when trying to vet hundreds of candidates for a single role (did I mention that the job market stinks?). Still, I am finding I have less tolerance for these types of assessments, especially the older I get, and the more automated and impersonal they become. I always go back and forth on whether I should opt out of these entirely, but I will probably continue to do them, contiuning my transformation into a 21st century digital lumpenproletariat.

The Elephant in the Room

Generative AI is the new wrench thrown into the interviewing experience, at least for me. When I have been lucky to get an interview with a real human and (even luckier still) get deep enough into the interview process to learn about how the team uses AI, it seems most teams are still figuring it out.

AI in Technical Interviews

From the standpoint of technical interviews, most companies I have interviewed with thus far did not allow use of AI tools. In fact, most seemed wholly uninterested in evaluating how I personally use these tools. However, there was one company that specifically encouraged the use of coding agents for their take-home challenge.

That particular challenge involved quite a few moving parts, and it was time-boxed to 2 to 3 hours, so it seemed like a good opportunity to get practice with Codex. I used the latter to write the tests and the code, using a TDD-based approach, as well as steering and design documentation to guide implementation, the latter of which I wrote.

I am not really sure what the correct approach here was, but it evidently wasn't mine, as I was told upon rejection that it was not "robust" enough for a senior role. Despite completing the stated objective and implementing tests validating the requirements, the code quality was… unremarkable. Perhaps another coding agent such as Claude Code would have produced higher quality output, but I could nonetheless see their point. Moving on.

AI in Practice

Among the hiring managers and devs for the roles I interviewed with, there was no clear consensus on how to effectively use AI as part of their business or engineering process. However, there were some common themes. For example, all indicated challenges reviewing AI-generated code at scale and defining governance for agentic workflows. Most I talked to seemed to be taking a tactical and measured adoption of its use, which seemed like a good sign that (at least this relatively small sample of) teams are not totally cargo culting AI. One hiring manager described AI succinctly: AI is a "force multiplier".

Where Have All the Junior Engineers Gone?

Speaking of junior engineers, it seems many of these same companies are no longer hiring junior talent and are hiring senior and staff engineers exclusively. It's hard to tell how much of this dislocation is due to AI or due to existing trends (based on experience from my most recent roles, I have seen fewer juniors and less emphasis on mentorship overall). There's a lot to parse in the current AI discourse right now, and how this informs hiring practices of junior talent I am not sure, but it is notable.

"We don't have the time to teach someone who is just starting out", "we need to hit the ground running", "we aren't able to do a lot of hand-holding" …are some of the responses I've heard. The ones that do have junior engineers on their team, unsurprisingly, call out mentorship explicitly in job descriptions.

The Dreaded Job Gap Question

I was laid off in October, and spent two months on garden leave, until my employment officially ended in December. I put on my resume that my most recent role ended in October, which in hindsight was probably a mistake. Almost everyone has asked me what I have been doing since October. In the past, I've only been out of work around 3 months max and have never been asked this, but it seems to be a concern this time around. Perhaps this is reflective of the very risk-averse / buyer's market mentality of the current software job market.

On a similar note, another hiring manager grilled me on why most of my roles have been fewer than 3 years in length. I generally try to give a generic answer like "due to external factors beyond my control"—which is true for all but a few roles, by the way—and redirect the conversation by expressing my desire for a long-term position. But, when probing the circumstances around my departure from one particular company, the hiring manager seemed incredulous that I should be laid off given the seeming importance of my role. Fair enough, I guess. Sometimes you aren't gonna please people.

Miscellaneous

Recruiters

The recruiting experience is still about the same, though it seems like ghosting is noticeably more severe this time around. I generally expect ghosting from recruitment agencies by default, but even a number of in-house recruiters have failed to follow up after having gone through an interview. I suspect this is due mostly to disorganization and trying to juggle multiple (perhaps dozens) of candidates for various roles at a time, but it still isn't a great feeling to be ghosted. And of course this says nothing about LinkedIn recruitment scams and other fake job postings out there.

Hiring Managers

Hiring managers seem to be a lot pickier this time around as well, which aligns nicely with the aforementioned "crappy job market" theme I've been rolling with. For base qualifications, they seem to want the sun and the moon, even for contract roles. If I manage to get an interview with the hiring manager, they are pretty hit-and-miss. Sometimes I knock it out of the park, other times it becomes evident that they have no interest.

Though I usually do quite well on behavioral or "culture fit" interviews, there's at least one question I get asked that I don't have catalogued in my memory bank of STAR method stories. Then I stumble, forget details, go down rabbit holes, only to pause my nervous gesticulating to take note of the hiring manager's vacant stare, as they absent-mindedly tab through their web browser (I caught one yawning, too. Ouch.).

Interview Preparation

Behavioral

Speaking of STAR method stories and GenAI, I have been using the latter to good effect to help me refine the former. Typically, these stories need to be delivered within a minute and with utmost clarity—and I have found LLMs are pretty decent when editing for clarity, especially when the language is interview-ese.

System Design

For system design interviews, I have been re-reading sections of Designing Data-Intensive Applications and have also been using LLM chatbots to help brush up on certain technical topics. For example, I had an interview where a hiring manager hinted that the system design portion of the interview might be to implement a leaderboard or a chat system. Prior to the interview, I used ChatGPT to structure system design interview questions on these topics, then I walked through my solutions, discussed my approach and tradeoffs, and then requested feedback.

Live Coding

For two different backend Go roles, I was asked to do live coding assessments, and I wanted to try and anticipate what kinds of questions each interviewer might ask. One recruiter indicated the interviewer for one role was interested in someone who had a firm grasp of relational databases, in particular someone who knew how to write efficient queries. Another indicated that I would likely be asked a concurrency related problem. Similar to the system design task, I enlisted ChatGPT's help to design a test harness for several different scenarios in each domain, and in each case I asked it to produce a program that I could play around with to test.

For RDBMS stuff, I designed a basic order and shipments system, I then prompted ChatGPT to generate a script for quickly migrating and seeding the database with enough data to demonstrate query efficiency, then had it implement queries for things like keyset pagination, aggregations, choosing appropriate indexes to improve efficiency as the data scaled, as well as common Go / SQL interop patterns.

For the concurrency related interview, I again prompted ChatGPT to generate examples for different types of workflows using goroutines and channels, including fan-in / fan-out pipelines, workloads using write vs read-write mutexes, and so on. I then asked it to wrap examples in a convenient little CLI executable that accepted flag arguments for testing the various scenarios. All of this in a matter of seconds. Neat!

No LeetCode Grind

I didn't grind any LeetCode. While I have done so in years past, I can rarely ever motivate myself to do so, and this time was no exception.

Conclusion

For all the rapid changes in software each new year, it is striking how little the software engineer interview process has changed.

Even the oft-hyped "AI" hasn't really seemed to make much of an impact on the interview process overall, except to perhaps make it slightly more annoying. On the other hand, my own use of LLMs for interview preparation has been somewhat fruitful.

Either way, it seems that employers are mostly doubling down on existing tech interview processes; there are just more of them, they're more difficult, and more time-consuming.

But, for every 10 annoying multi-round gauntlets, there are always a few gems here and there. And, it's generally a good opportunity to improve my skills and clarify my strengths, weaknesses and career goals.

Intro

2026-04-07T16:20:00Z

Hi there. This is my first blog post. Or, to be more accurate, my first published blog post.

The idea of a personal blog has been knocking around in my head for a while, and the code base for this website has been gestating since 2021. As in 2021, the primary impetus for starting a blog is the sudden abundance of time I've been granted due to recent unemployment.

I suppose a bit of an explanation is in order. I was laid off late last year, just prior to concluding a rather large project for a major casino and resort company. While there, I helped build a fairly complex web backend for a real-money online casino. The work was equal parts challenging, frustrating, and illuminating, and I definitely learned a lot. Alas, for reasons beyond my control, said company closed my division in October and I now find myself in that familiar place again.

But, I digress. The real reason I wanted to write today was to introduce myself and this blog. So without further ado:

My name is Dylan and, as you may have inferred from the above, I am a software engineer. As such, I will likely be writing about software engineering, technology and related topics.

But, to be honest with you, it may also serve as a vehicle for me to talk about life and bitch about the current state of the world. Which is to say: I may also write about current events and politics from time to time. So if you "don't do politics", consider yourself warned.

With that said, I hope to write a new post at least once a month. Though I am not holding myself to such a commitment, I think I can manage.

Until next time…