Firecode

Software engineers have been adapting to technology changes and paradigm shifts for decades (compare your SWE stack today with what it was 20 years ago). In this regard, we were much more prepared for AI to dramatically change how we build software (i.e., we almost write no code manually anymore). AI can produce very high-quality code, especially if you know how to guide it well. However, I'm worried about one thing: The people getting most value out of LLMs and AI coding agents today are the experienced software engineers who cut their teeth writing code manually for decades and have good intuitions on how to build good software. I wonder what will happen to the next generation of SWEs who never wrote code and their entire experience was prompting AI agents to build stuff, add features, and fix bugs.

Coding interviews are changing faster than most people realize. I recently read a post by Felix Rieseberg, an engineering manager at Anthropic who led engineering on claude[.]ai, cowork and claude code desktop. He has stopped giving coding interviews. His reason claude is now better at them than the candidates. Here's what that means for how engineers get hired 1. The coding interview has lost its signal For years, small coding challenges were a weak but real predictor. If you could define a problem quickly and find a clean solution, you'd probably do well on his team. That's no longer true. In his words, there's no more point in a React challenge than in quizzing people about assembly, because claude is better at both. He also says his most impactful engineers succeed regardless of how they'd score on these tests. If the tool passes your test, the test isn't measuring the candidate. 2. Newcomers notice what veterans stopped seeing When Felix interviewed at Notion, they asked him to design offline mode. He later learned it was a "trick" question. Everyone believed the CEO would never allow the experience it required. It turned out nobody had ever checked. He was new, so he simply asked. A year later it happened the other way around. He'd wanted dashboard TVs for the teams, hit resistance, and gave up. A new hire had the same idea, and Felix told him not to bother. The new hire had already asked, and the TVs arrived the next day. In one year, Felix had become the person who assumes things can't be done. New people spot problems and opportunities that everyone else has stopped noticing. 3. The catch: nobody listens to the new person Newcomers have the fresh view but no influence. In most companies, you need years of credibility before anyone backs your idea, because building things used to be expensive. So juniors were expected to finish tickets faster, not to propose ambitious ideas. That has changed. Building things is now cheap. Two relatively new Anthropic engineers built a prototype of a desktop app for Claude Code in one weekend, and the first public version shipped about 8 days later. They skipped the PRD, the approval meetings, and the wait for design resources. They built the thing and showed it. 4. His playbook for engineers without status First, start from business impact, not your backlog. Figure out what the company actually needs. A useful shortcut is to learn what your manager's manager is trying to achieve. Second, pick one ambitious idea that would significantly move that goal. Third, build a working prototype over a weekend. Fourth, keep it to one idea. His most common criticism of juniors is that they hide three great ideas among twenty bad ones in a single prototype. The prototype should make leadership understand the opportunity and see that you're the one who can run it. Fifth, use your fresh perspective. You still experience the product the way users do, and you haven't yet learned all the reasons something is supposed to be "impossible." 5. What I'd test instead of LeetCode Felix says he hasn't figured out the replacement yet. For now he looks for small prototypes that show taste, empathy and principled thinking. Here's what I'd add: Give candidates a vague problem with no spec and watch which questions they ask before building anything. Give them a 300-line PR written by an agent with three subtle bugs and see if they find them, since most of the job is now reviewing AI output. Give them 60 minutes with any agent they want and watch when they trust it, when they step in, and when they throw work away. Then show them two working solutions and ask which one should ship and why. None of these have an answer key, and that's what makes them useful. 6. Why this is good news for juniors Felix says he's seeing comparatively new engineers overtake people who are probably better coders and have been around much longer. AI closed most of the output gap. It didn't close the judgment gap. A junior who ships one focused, well-reasoned prototype now has more to show than someone who solved 500 LeetCode problems. 7. The uncomfortable part "Hunger beats tenure" is easier when you have free weekends, savings, and no second job. Weekend prototypes favor people who already have time and a financial safety net. And "hunger" can easily become an excuse to push out experienced engineers. The playbook is good. Hiring should still measure judgment, not hours worked. LeetCode tested whether you could write the code. The new interview tests whether you know which code not to write.

Interview questions I'd prep for in 2026 (now that AI writes half the code) 👀 → "Your AI agent broke prod. How do you find what changed ?" → "Walk me through a PR you reviewed. What did you catch ?" → "Explain this code you didn't write." → "When would you NOT use AI for this ?" → "Build a small feature end to end, out loud." The LeetCode-only grind is lowkey cooked What did they ask in your last interview ?

You're in a tech interview. The interviewer asks: "Why should we hire you when Claude Code can already write code?" What's your answer?

Chinese researchers have developed the best shortest-path algorithm in 41 years! Dijkstra’s Algorithm has been the undefeated king of the shortest path for over 40 years. Whether you’re using Google Maps, booking a flight, or routing internet packets, Dijkstra is the engine running in the background. Since 1984, textbooks have taught that its efficiency was hit by a "sorting barrier." To find the shortest path, you have to sort the points by distance. And sorting has a mathematical floor you can’t cross. Until now. A research team from Tsinghua University just published a paper that shatters the 41-year-old record. They proved that Dijkstra is not optimal. By combining the logic of the Bellman-Ford algorithm with a revolutionary "recursive partial ordering" method, they figured out how to find the path without fully sorting the nodes. The results are a massive shift in theoretical computer science: - The first deterministic improvement to the Single-Source Shortest Path (SSSP) problem since 1984. - A new time complexity of $ O(m \log^{2/3} n)$, officially beating the long-standing $ O(m + n \log n)$ limit. - On massive sparse graphs (like the web or global logistics), this means finding the best route significantly faster than previously thought possible. For four decades, the greatest minds in algorithms believed this limit was absolute. Last year, even the legendary Robert Tarjan won an award proving Dijkstra was "optimally efficient" at sorting distances. Tsinghua’s answer? Stop sorting. The world’s most settled problem is suddenly wide open again. If we can break a 40-year-old law in basic graph theory, what other "impossible" speed limits are waiting to be crushed?

The higher the salary bracket you are interviewing for the more chill the interview becomes