A piece by Louise Deason on nine questions worth turning back on your interviewer — not to impress them, but to know what you're about to walk into. Reading it, I realized that for years of interviewing I'd been sitting on the wrong side of the table.
Two services needed to talk to each other, and the team's first reflex was "just stand up Kafka, do it properly." But we had no Kafka, nobody had ever run it, and Redis was already in the stack. This is the story of choosing Redis Streams in the spirit of YAGNI — and an honest accounting of the costs the marketing docs never mention: everything lives in RAM, eviction wipes whole streams, failover can eat acked writes, and the day I knew we'd have to go back to Kafka.
I walked into an architect interview and got asked to "design a rate limiter." I started reciting algorithm names — and realized the interviewer didn't care which one I picked. Every answer only opened a deeper question: with twenty servers, where does the count live; whose clock do you trust; if Redis dies, do you let requests through or block them; and finally — is rate limiting even the whole story. The algorithm is the ten-minute answer; the rest of it was the interview.
When I started out, caching meant one thing to me: "API slow? Throw Redis at it." Cramming for an architect interview, I finally saw what that "throw it in" really dragged along — invalidation, three distinct ways to crush a database, cache–DB consistency — and that it was really the Dual Write Problem wearing a disguise. Caching is never free; every layer of cache is a line of debt against consistency.
Prepping for an architect interview, I realized leveling up isn't about writing better code — it's about seeing the whole system. Six topics I'd once memorized by rote — microservices, 2PC, Saga, CAP, Outbox, idempotency — turned out to be a single causal thread: each solution births the next problem.
Every time an AI answers, two workers with opposite temperaments take turns at the bench — and nearly every trick for speeding up inference is born from the tension between them. A trip inside the reasoning machine: prefill, decode, KV cache, batching, quantization, and why the day eventually comes to run your own servers.
A piece by Louise Deason on nine questions worth turning back on your interviewer — not to impress them, but to know what you're about to walk into. Reading it, I realized that for years of interviewing I'd been sitting on the wrong side of the table.
Claude Code operates in multi-million-line monorepos using agentic search instead of an index. This post sums up how it works, the harness layers you need to build to scale it, and a concrete roadmap for where to start in a large codebase.
One sentence from Peter Steinberger hit 2.2 million views and had the whole dev crowd arguing for a week. After I read it, I realized I was still stuck in the "chat" era — and the real cost isn't measured in tokens.
I read a guide on building an Obsidian system designed from the opposite end: optimized not for the moment you save, but for the moment you use. By the time I finished it, I understood why my vault of several hundred notes had never given anything back.
I read an old Reddit post — a drunk data engineer being honest about ten years on the job. It was good enough that I had to sit down and rewrite it from my own angle. Not a summary, not a translation — a real reaction, from someone drinking a beer alone and agreeing with about 80% of what he said.
There are hundreds of articles about prompt engineering. Most of them re-explain the same concepts: zero-shot, few-shot, chain-of-thought. This one doesn't try to explain them differently — it says plainly why most of that advice doesn't survive contact with production, and what actually matters when you're not doing a demo but building the real thing.
When Claude Code leaked, everyone paid attention to the drama around the leak. I paid attention to the harness. Reading it closely, I realized I was looking at a real production agentic system run at serious scale — and almost everything I'd built up to that point was missing important pieces.
Andrej Karpathy just posted a gist about a pattern for building a personal knowledge base with an LLM. After reading it I sat still for a while — not because the idea was new, but because he put the right name on a problem I'd been fumbling with without knowing what to call it.
A thread on X from @0x_kaize about 10 habits that stop you from hitting the limit mid-session. Reading it, I realized I'd been wasting tokens in at least three different ways — every single day, without ever noticing.
A Reddit user reverse-engineered Claude Code's minified source, found a caching bug that drained tokens overnight, and patched it in exactly two lines.
I read a fairly heavy-handed piece about AI hype — agreed with parts, disagreed with others. Here's my take, written from the seat of someone building real products with real AI.
Anthropic just published a run of research on how Claude actually works on the inside. Not how it describes itself. How it actually operates.
After a stretch of building an internal chatbot with RAG, I realized I'd misunderstood the core problem from the very start.
I read a post by an engineer over in the US and felt a jolt of recognition — I was walking straight into the exact trap they described.