Fifteen minutes. That's how much notice I had. Somewhere along the way the recruiter and I got our timing crossed for the interview, and the note came in while I was finishing a Khmer meal with my siblings in Siem Reap. It was around ten at night. I rushed back from the restaurant to the hotel.
The only place to work was a corner at the foot of the bed: a little wooden chair and a station barely big enough for my notebook. The notebook was full of C# I'd scribbled down over the past couple of days. Classes, methods, syntax. Most of it looked a lot like TypeScript, and I felt like I'd tricked myself into thinking that was enough.
Then I froze on a method to update a user's roles. Role-based access control is something I've worked on plenty of times, mostly from the UI side, and I sat in front of a small piece of it and couldn't write it.
nine years out of the room
I've been quiet here since the spring. The summer went to feature work, to learning, and to improving the tools I use to plan, build, and review with AI.
Early in my career, I interviewed every six months or so. It was how I flexed the muscle and kept a read on what was out there.
The last time was June 2017. One interview. I met Chris and Mark in person, and we went over Ember code together in a tiny room. I accepted an offer at Lytics the same day. There was so much to learn there that I never felt the need to look elsewhere, and the habit stopped. I still work with Chris today.
Nine years later, I decided to pick it back up and see where I stand: where my skills have gaps, what the process looks like now, what people are looking for. Interviews go both ways, too. I wanted to understand how other teams were using AI in their engineering work.
I was supposed to be on vacation. Taking the interview anyway was my call.
where were we?
When I step away from work, I write detailed notes first. When I come back, I ask Claude "where were we?" and get a summary of what shipped to production while I was gone. I can pick up at any point with a deep understanding of the work in front of me and what I need to deliver for my team.
I expected the interview to work the same way. I expected the conversation to be about my AI workflow and the toolset I've built around it, because that's what my day actually looks like.
I'd already spent an hour with the hiring manager in a previous interview. Now he was taking me through the coding exercise, with a couple of other engineers on the call. He was trying to set me up for success. I could use any language I wanted. Talk through my thinking, explain how I'd approach the problem, and get something roughly working.
The ask was simple: write a method to update a user's roles.
We were in C# Fiddle. I'd spent a couple of days reviewing C# beforehand. I should have switched to JavaScript and removed the unfamiliar syntax from the problem. I was stubborn and went ahead with C#.
That's part of the AI hallucination, that you could do everything. I'd become so used to being able to build things with AI that I thought I could just write in a language I'd barely practiced when the moment came.
I froze.
In hindsight, the problem was really simple. In the moment I was nervous, and the methods started bleeding into each other. The fiddle swam. My mouth went dry.
I've sat in their seats. I've interviewed my own colleagues. I never knew how loud the silence is from this side.
The interview ended there, and we parted ways. It wasn't a pleasant experience, but I appreciated the candid honesty.
The behavioral and communication rounds went well. At least I thought they did.
The coding round humbled me. Earlier this year I wrote about being humbled by the parts of the job code can't reach. This time it was the code.
the plan knew it, my fingers didn't
I'd already published a plan for RBAC permission enforcement in our UI. Models move so fast. Earlier this year, plan first was the flow: I built the sample plan as a front-end engineer with Claude Code, with the components, the API shape, the test strategy, and the verification checklist all written before any code.
I thought I knew how RBAC works. Clearly not as well as I'd thought. I knew the UI side: the stateless forms, the radios and buttons, the shape of the data. I'd worked through granular permission enforcement in detail for our system's front end, and shipped some updates in Go as well. I hadn't reviewed how to write those methods by hand. I didn't think I'd need to.
When I sat down to write that method from scratch, in a language I'd reviewed for a couple of days, the knowledge wasn't in my fingers. It lived in the plan and in the tooling around it.
I don't know how it would have gone in JavaScript.
What I did instead was question everything. Is that the correct way to write a C# function? Normally I'd do it like this, but is that how C# does it? The fiddle wouldn't compile, so I couldn't just hit play and work backwards from whatever ran. Maybe pseudocode would have been enough.
I hadn't written code by hand since April 2025. Like a lot of SaaS companies swept up by AI, we've had a mandate to use AI to write the code and focus on delivering value and features for customers. Things like how .reduce() works, or the common methods on a hash map, took on less importance. Software engineering was changing.
what my hands stopped doing
I haven't stopped reading code, though. On critical features I'm still the second set of eyes. That's where my experience comes in: stateless component design, TypeScript, React and Ember best practices.
When something breaks, I'm still the one who finds out why. I bisect to the commit that caused it. Then I grill Claude: why didn't the tests catch it, and which guardrail let it through? We add the check that would have caught it. Between Claude and Codex, the writing happens somewhere else now.
It felt strange at first. I stopped nitpicking implicit returns inside .flatMap() for cleaner code. Some days I still open a component in VS Code and I'm shocked that the one Claude wrote is just as good as what I'd have written by hand, and more testable.
The output changed with it. In "Those who like to build", I counted my pull requests by month, 2024 against 2025. June went from 33 to 239, August from 44 to 299. From April through August, each 2025 month ran roughly 2.5x to 7x the same month a year earlier.
the role lines moved
My background is front end. The role was full-stack.
AI blurred that line for me. These days I think about the backend as much as the front end. Does the system support the feature? If it doesn't, what are the gaps? Then I build the gaps so the feature ships.
The questions I ask most are about the people using it. Is it self-service? Can someone with little knowledge of the system understand what's going on? Does the flow make sense? Does this page help them deliver value for their team?
None of those questions were on the screen. A method signature was.
back to fundamentals
The job market is weird right now. I have a decade of experience, from SDET and QA through Java into JavaScript, CSS, and front end, and now across the stack with AI.
I don't think the interview process is behind. It's not quite catching up with the day-to-day process of a software engineer. The job, at least the one I've been doing, rewards knowing what to write and why. This interview checked whether I could write it, cold.
The interview gave me room to choose how to solve the problem. I made it harder for myself.
I was already building better guardrails around code before the interview, making the leap from AI-assisted to agentic. Afterward I leaned in harder. Going back to writing code by hand didn't feel like the place to go. More on that leap next time.
CS fundamentals are a different story. They've always been my weak point. I don't have a formal CS degree, and the training that started my career leaned toward solutions: beautiful, intuitive UIs that also make things easy. That meant asking questions and thinking hard about UX.
Looking back, the interview tested muscles I relied on as a junior, starting fresh in my career, and I'd let them go slack. So I'm going to revisit data structures, algorithms, and to a certain extent design patterns, and work through some LeetCode exercises. Most importantly, I'll interview in a language that spills out of my fingertips onto the keyboard.
Before any of that: no more squeezing an interview in after a long day of adventure. I'll confirm the time and schedule it for when I'm back stateside. The hiring manager was trying to set me up for success. Next time, I'll do the same for myself.
How this was written: I talked through the story with Claude, which drafted it from my notes, then I edited it by hand. The interview, the freeze, and the opinions are mine.