Zach's Quips

After submitting 480 job applications in the spring of 2026 while searching for my next role, I was shocked at how one-sided the economics of the job market feel for software engineers. Only 136 of those 480 applications received a response of any sort, and only 11 resulted in an interview. Many of the responses seemed extremely expedient, with the denial sometimes landing in my inbox before the confirmation email. This much friction in a marketplace can't be productive, as it likely means qualified candidates aren't making it through the filters, and employers are likely overpaying new hires due to an inaccurate view of the talent pool.

If you had told me 4 years ago that Markdown would be the data format of the future I wouldn't have believed you, but it seems that it has become the preferred format for flat file knowledge storage for LLMs. I can't argue with the accessibility aspect, and it's arguably lighter than many alternatives, but I'm shocked by how little tooling has evolved around it in terms of LLM mutations. I often see sessions using sed and grep to pull knowledge from the files, and mutating things like inline tables often results in over-writes and formatting errors. I'm wondering why this gap exists and what tools are going to fill it...

It occurs to me that the cost of "custom software" may have fallen far enough that a medium-size business could find it efficient to build a software suite that matches its operations exactly, rather than trying to bend those operations to fit off-the-shelf tools. Will the "job shops" of ten years from now be maintaining modular systems for their clients' custom-built operations platforms? (And will it all still be built on React 😵!?)

The brief 72-hour stint with Fable 5 before the pull-back has created a sort of productivity chasm. I don't want to push forward with current models because I know the results will be inferior to what I could produce with Fable. It's project paralysis of a new kind — for me, at least.

Interviewing for a new role, especially a director/VP-level role, is an interesting experiment in reading between the lines. Once you ask enough questions, you start to uncover the true friction points in the business, the lore that led to the position being opened, and suddenly single lines from the job description make a lot more sense. "Diverse team" probably means the staff is made up of contractors in other countries. "Communication is a priority" likely means communication within the org is suffering at the moment. "Moving fast" is less about velocity and more about poor planning and the need for "heroics."

Tech hiring is far too concerned with the tools a professional is proficient with, and spends far too little time discovering how good they are at problem-solving. You would not hire a roofer based on the brand of hammer they use; you hire them based on how well they can lay a roof. Engineering roles should be filled with people who can think through and solve problems regardless of the domain and tools. We should stop relying on code challenges that really test how well you know a language and can implement "solved" solutions from memory, and should instead be asking engineers to solve complex and nuanced problems in abstract contexts.

The more time I spend with business founders, the more evident it becomes that "good" business is not always about operational efficiency, marketing, or even quality. There are just some businesses that operate in the fringe where supply and demand are out of balance, and they thrive despite what appear to be deliberate acts of self-sabotage.

In preparation for the AI Without the Hype workshop, I spent a lot of time thinking about what the future might look like for my children, and even for my employees. I feel confident in my ability to adapt to the changes that are coming, but it seems more and more evident that the number of people needed for a given role in the white-collar space will likely be drastically reduced. Have we just taken the "stand out" cultural movement and turned it up to 11?