Latest Posts
-
Consistency and Concrete Design
Large codebases reward different instincts than small ones. Sean Goedecke’s posts capture that shift: ship safely by following the grain of the system, and design by working with the concrete details, not abstract principles. Here’s the version of that philosophy I want to keep in front of me.
-
Advent of Code 2025: 12 Days
This was my third year participating in Advent of Code, and I enjoyed it more than ever. The big change this year was that it ran for 12 days instead of 25. I didn’t expect that to matter much, but it really did.
-
Using LLMs for Coding
I’ve been using coding agents a lot this year, both in my job and for personal projects. They are much more useful than I initially expected. I’m not going to recommend a specific one, since the ones I used paid versions for (Claude, Amp with Gemini, ChatGPT Code) all perform very similar.
-
Six Months at a Startup: What I Learned
I’ve spent the past six months working at a startup, and it’s been a completely different experience from working at larger, more established companies. The pace is faster, the decisions are more frequent, and the impact of your work is immediately visible. Here are some of the most important lessons I’ve learned.
-
Tech Interviews
If you’ve looked at LinkedIn in the past couple of months (or years), you will have seen posts from people about tech interviews. This is my contribution to the discussion. I’ll start with an overview of the state of interviewing for software engineering roles and finish with a proposal for a better process. A process that I think gives more insight into how candidates actually solve problems and takes less time for both the candidate and the interviewer.
My recent experience is with senior-level interviews, so that’s what I’m going to focus on here.
State of the Industry
Most tech interviews follow a very similar pattern, modeled after how Google, Meta, Amazon, and other big-tech firms conduct interviews. They include one or more of the following, totaling 5-7 rounds:
Recruiter Screen: A short call with a recruiter to discuss your experience, the role, compensation, and next steps in the process.
Hiring Manager Screen: A longer call, similar to the recruiter call but goes deeper into technical experience and covers some cultural and leadership questions.
Take-home Assignment: These come in two flavors:
-
A timed assignment with one or more tasks covering e.g. basic React or data structures/algorithms.
-
A more open-ended project that gives you flexibility to implement it in your preferred technology.
Tech-Screen: Similar to the timed assignment but timeboxed to an hour. The interviewer observes and answers questions.
System Design: You are asked to design the architecture for a well-known system, like Uber or YouTube. This interview mainly decides if your experience matches the job’s level.
Culture Fit / Leadership Principles: A discussion of your previous experience to see if you’re a cultural fit and how you handle common challenges like disagreements, scope creep, and missed schedules.
Checking References: Not technically an interview round, but something I’ve seen more frequently.
Some of these rounds add more value than others. The recruiter and hiring manager screens, along with the culture fit interviews, help determine if the candidate will be a good addition to the team and company.
Coding Questions
The coding rounds, on the other hand, add less value. They mostly test how well a candidate can memorize and repeat common questions. There is a whole industry of books, websites, and courses dedicated to this. This requires a lot of preparation time, which disadvantages people who don’t have that time due to responsibilities like caring for children or family members, or having a busy job.
Besides the time required to prepare, the coding questions don’t actually test how a candidate works day-to-day. I use Google, MDN, and the React docs daily to remind myself of various APIs, not to mention modern AI tools like Copilot. Most work doesn’t involve algorithms to reverse linked lists, flip trees, or find the shortest path.
System Design
While system design is more useful than coding questions or a pop-quiz about a random API in a popular framework, it is still flawed. It requires the candidate to quickly come up with trade-offs between various solutions for a product they’ve had only a few minutes to think about. Similar to the coding questions, this again depends on how much time the candidate has been able to study common system design questions.
Checking References
A note about checking references: I can see why you’d want to talk to people a candidate has worked with, but this puts them in a weird position. They have to ask a huge favor from (former) co-workers without knowing if the company they’re interviewing with will respect their time. Moreover, the candidate has to disclose their interviewing to their coworker. If they only give former co-workers as references, the question is how relevant those references are if they left that job two, three, or more years ago.
A Better Process?
I don’t think there is a single process that will work for every team or company, but I think there can be several improvements that make the process feel less random, less time-consuming, and more focused on real-world experience.
The recruiter and hiring manager screens, as well as the culture/leadership rounds, add a lot of value. When done by a well-prepared interviewer, these can give a good indication of whether the candidate is a good match for the company and team.
For the coding round, I would have the candidate spend three hours building a project that highlights their skills. Either something they’re passionate about or a pre-scribed project. Something slightly more complex than a to-do app, but not so complex that they need to spend an entire weekend on it. Next, I would spend 45 minutes discussing their implementation and the choices they made. This gives the candidate more flexibility in how and when they want to work on the project and doesn’t require them to take time off work. It also provides something concrete to discuss, instead of a hypothetical product.
-
-
Advent of Code - 2025
This is the second year I’ve participated in Advent of Code, and I cannot recommend this exercise enough. It’s a great way to encounter interesting software engineering puzzles that are very different from my day-to-day work.
For those unfamiliar with Advent of Code, here’s a description from the website:
Advent of Code is an Advent calendar of small programming puzzles for a variety of skill levels that can be solved in any programming language you like.
One thing that stood out to me this year was the number of problems involving grids; whether it was finding the shortest path, moving boxes around, or taking shortcuts on a racetrack.
That said, most of the puzzles this year were pretty straightforward. It helped a lot that last year I learned about Dijkstra’s Algorithm and the effective memoization of recursive function calls.
The most interesting puzzle for me was Day 24. It introduced me to “low-level” logic gates and reminded me that you don’t always need a closed-form solution. Sometimes you can figure out the answer by inspecting the output for a known input and applying some innovative logging.
If you’re interested, here is the Advent of Code GitHub repo I’ve been using for my solutions over the past two years.
-
Setup Dependabot
Dependabot is one of the most underrated features on a GitHub repository. It’s a free service that ensures your dependencies are up to date and warns you about security issues in them. It does this by automatically scanning your dependencies and creating a pull request for you to approve.
How to Set Up
To set up Dependabot in your GitHub repository, follow these steps:
- Navigate to the Insights tab in your GitHub repository.
- Click on the Dependency graph on the left.
- Depending on whether your repo is public or private, you will see a couple of tabs. Open the one for Dependabot, and click on the Enable Dependabot button.
- Finally, click on the Create config file button. This will create a
dependabot.ymlfile in the.githubfolder in your repository.
I like to add a groups node to the config file; the groups node tells Dependabot to group the updates for the dependencies into two PRs instead of creating a separate PR for each update.
version: 2 updates: - package-ecosystem: "npm" # See documentation for possible values directory: "/" # Location of package manifests schedule: interval: "weekly" # Add these groups groups: development-dependencies: dependency-type: "development" production-dependencies: dependency-type: "production"For other options see the official Dependabot docs.
What Does a PR Look Like
Dependabot creates two separate PRs, one for production packages and one for development packages.
In the description of each PR, it outlines which packages are updated, with links to the commits, release notes, and changelog, when available.
After that, the PRs can follow your regular PR approval process of running tests and getting approvals before merging.
-
Cat Picture
Meet Ms. Poes.
-
Blog Platform
As you can probably tell, this blog is hosted on GitHub Pages and rendered using Jekyll. This means you can find the source in its dedicated GitHub repository.
Why didn’t I write my own blogging engine? For a few reasons:
- I have worked on a blogging engine (DasBlog) in the past.
- There are many great existing blogging platforms available and actively maintained.
- Hosting on GitHub Pages is free.
The first two reasons are the most important and reflect my philosophy in software development:
Only work on projects that you find interesting and on which you can have a meaningful impact.
My time is limited, and I have many things I want to do—travel, ski, watch movies, read books. So, I don’t want to work on things in my spare time that feel like work. That’s why I chose my projects deliberately.
I use an unscientific method to prioritize projects, partially based on vibes. I rate every project on the following axes using 1-5 stars (⭐):
- Does it uniquely help me learn something?
- Do I find it interesting?
- Can I contribute something significant to the existing ecosystem?
- Does it help my community, my friends, my partner, my family?
- Does it make me money?
And at least 3 of the axes should have more than 4 stars for me to consider working on a project.
Creating my own custom blogging platform doesn’t meet that bar, it scores low (1, maybe 2 stars) on every category. The only category I could argue for a higher rating is that it could potentially help me learn about React server-side rendering or generating a static website using templates. However, that’s not something I’m currently interested in.