The weekly letter from Systems Thinking Lab: systems thinking insights for junior engineers, framed through the seven building blocks.
Felix Rieseberg is an engineering manager at Anthropic. This month he wrote that he has stopped giving candidates the coding interview. His reason is short: AI can now handle the small coding challenges the interview was built from, so those challenges no longer tell him who will do well on his team.
His post, "Hunger beats tenure", is advice for junior engineers. The line from it I keep coming back to is this one: "I'm seeing engineers who are comparatively new fly past people who are probably better coders and have been around much longer." It is one manager's observation, and he offers it as hopeful news. I read it as that, not as a rule. Then comes the part I find most honest. He says he has not yet found the replacement for the interview. For now he looks through resumes and portfolios for small prototypes that show taste, empathy and principled thinking.
I commented on the Hacker News thread, because I think the interview was measuring something specific, and that something did not go away. Here is what I wrote, lightly tidied:
The heart of the coding interview is to get signal on a candidate's ability to solve a problem without all of the inputs given to them, and see how they explain their thought process as they do it.
Because of AI, what it means to "not have all of the inputs" has changed as anyone can cut and paste a Leetcode problem to a chatbot and solve it.
I think we are going to iterate a bit to figure out a better signal than the typical coding interview. For junior engineers, I think coding questions will move towards MBA style problems when someone is given more of an open ended question with a codebase and you see what the candidate does without context to reduce the problem.
The word that matters there is reduce. A LeetCode problem arrives already reduced: the inputs are named, the goal is stated, and only the code is left. A real ticket arrives as a sentence from a person, sitting on top of a codebase you did not write. Somebody has to decide what the problem actually is, what can be ignored, and what has to be true when it is done. Then they have to explain those choices to someone else. An agent cannot do that part for you, because it does not know which parts of your situation matter.
That is a judgment test, and you do not need an interviewer to practice it. Take any ticket you have this week, or any feature in a side project, and do two things before the agent writes a line.
First, write the plan. A few sentences: what is being asked, what you are leaving out, and how you will know it works. Hand the plan to the agent, and build from that.
Second, name the blocks before you name a technology. The seven building blocks are the small set of parts that almost every software system is made from: a service that answers requests, a worker that does jobs in the background, a queue that holds work waiting its turn, and four other places to keep data. Ask which of those your ticket touches and what moves between them. Only then ask whether the answer is Postgres or Redis or something else. Doing it in that order shows you whether you understood the problem, and it gives you words to explain the reduction to a teammate.
Here is the practice version. The free five-day course walks through the first habit, writing the plan before the agent builds, one email a day.
https://systemthinkinglab.ai/five-day/
Reducing the problem was what the interview was always trying to see. So is the next thing you build.
Kay