HackerRank agreed with us. Coding skills are no longer the test
Your best thinking is invisible. The platform that built an empire grading developers on code just started grading something else.
🧠 Mindset Shifts · For developers rethinking how they grow
This week’s challenge: take a recent technical decision and write one page explaining not what you built, but why.
Last month I spent two hours on a Slack conversation that changed the direction of a client’s product. The CTO wanted to rebuild their authentication system from scratch. The engineering team had already started estimating the work. They’d even diagnosed the technical problems: session handling was fragile, the token refresh had edge cases on mobile, the original implementation had accumulated years of patches. All of that was true. None of it was the point.
The team had asked “what’s the problem?” multiple times. But every time they asked it, they asked it inside the frame of the auth system itself. The diagnosis was technical, the solution was technical, and the scope grew from there. Nobody had stepped outside the frame to ask a different question: what’s the user actually experiencing, and does fixing that require rebuilding the whole system?
Forty minutes of conversation later, it was clear. The actual user problem was a session management bug that made mobile users log in twice. A fix that would take days, not months. The rebuild was a technically correct solution to a correctly diagnosed set of problems, and it was still the wrong decision, because the problems it solved weren’t the ones that mattered to the business.
I didn’t write a single line of code that day. The most valuable thing I did was a reframe: stepping outside the level where the team was thinking and asking the question from one level up. There’s no commit for that. No PR. No ticket that says “prevented three months of wasted work.” The output was a Slack thread that took two minutes to read. The thinking behind it took two hours, plus twenty years of watching teams solve the wrong problem because nobody stepped outside the frame long enough to check.
That thinking is invisible. And if you’re a developer, most of your best work probably is too.
The gap between what you do and what people see
Think about your last week of work. You shipped features, closed tickets, reviewed pull requests. Those are the visible artifacts: the things your manager sees, your performance review counts, your team tracks in standups.
Now think about everything else you did. The three approaches you evaluated in your head before picking one for that API design. The other two vanished the moment you started coding, along with the reasoning that eliminated them. The pattern you noticed across two unrelated bugs that pointed to a deeper problem in how the service handles retries, but you fixed the bugs individually, and the systemic insight never left your head. The moment in a planning meeting where you asked a question that shifted the entire scope of a feature, and everyone moved on as if the new direction had been obvious from the start.
Every developer I’ve worked with does this kind of thinking constantly. Evaluating trade-offs, noticing patterns, making judgment calls that shape the quality of everything they produce. It happens so naturally that most don’t even register it as work. But it is work. It’s the hardest part of the work, and it’s the part that differentiates a developer who delivers from a developer who delivers the right thing.
The problem is that none of it leaves a trace.
Developer culture has a deep bias toward visible output. Commits, contributions, shipped features, green GitHub profiles. Career advice reinforces it: build more projects, write more posts, contribute to open source. The message is clear: if people can’t see it, it didn’t happen.
So developers get evaluated, promoted, hired, and trusted based on the fraction of their work that’s visible. The reasoning, the judgment, the decisions behind the decisions, the part that actually determines whether the visible output was worth building in the first place, stays inside their heads. They give it away for free, every day, because nobody taught them to make it seen.
Why it stays hidden
Part of this is structural. The tools and rituals of software development are designed to capture outputs, not reasoning. Pull requests show diffs, not the decision process that shaped them. Standups ask what you did yesterday and what you’ll do today, not why you chose that approach over the alternatives. Sprint retrospectives look at what went wrong, not what was prevented by good judgment that nobody noticed.
There’s also a cultural dimension. Making your thinking visible can feel like showing off, like you’re claiming credit for something that should be implicit. Developers tend to let the code speak for itself, which sounds humble but is actually a form of self-sabotage. The code doesn’t speak for itself. The code shows what you built. It says nothing about what you considered and rejected, what risks you anticipated and mitigated, or why you chose the simpler approach when a more complex one was technically superior. All of that context evaporates the moment the PR is merged.
The result is a career built on a fraction of your actual contribution. Two developers who ship the same feature look identical from the outside: same PR, same outcome, same velocity metric. But one of them spent an hour thinking through edge cases, evaluating approaches, and choosing the design that would be easiest to extend in three months. The other copied a pattern from somewhere else and hoped it would hold. The difference between them is entirely invisible until something breaks, and by then, the developer who thought carefully has already moved on to the next project, with no record of the judgment that made the first one durable.
This invisibility compounds over time. Every year, you accumulate more judgment, more pattern recognition, more ability to see what others miss. And every year, that growing capability remains hidden behind the same visible output: code, tickets, deploys. Your most valuable asset appreciates in the dark, and the people making decisions about your career can only see the surface.
What changes when the thinking becomes visible
A developer once asked me a question that changed how I evaluated everyone after him. We were talking about coding practices, best approaches for structuring modules, the usual technical conversation. Then he said: “What should I do to make my colleagues’ job better?”
That question wasn’t about code quality. It was about how he thought. In one sentence, he told me that he didn’t see his code as a standalone product of his individual work. He saw it as something other people would have to live with, extend, debug at 2am, and build on top of for months after he’d moved to something else. That perspective is rare, and it’s invisible in a pull request. The code might look the same whether the developer was thinking about their colleagues or not. But the question gave me access to his mental model, and that access was worth more than any code review.
After that conversation, I could work with him differently. I could give him architectural responsibility, because I knew he was already thinking about the team’s experience, not just the feature. I could trust his judgment on trade-offs, because his frame extended beyond the immediate task. One question, one sentence of visible thinking, and my entire assessment of his trajectory shifted.
When I started managing teams, I carried that lesson forward. I looked for the developers who made their thinking legible, not just their output. And I started sharing that perspective with others: the developers who show you how they think unlock a kind of trust that no amount of shipped code can build.
This doesn’t require grand gestures. It means small, consistent acts of externalization. A PR description that includes one paragraph explaining what you considered and why you chose this approach. A Slack message that starts with the problem you’re solving before jumping to the solution. A standup answer that names the decision you’re facing, not just the task you’re working on. A brief comment before a code review that frames what the reviewer should pay attention to and why.
Each of these takes thirty seconds. Each one transforms how people perceive your work.
When a developer makes their reasoning visible, three things happen. First, other people start trusting their judgment, because judgment that’s visible can be evaluated and calibrated. The developer who asked about his colleagues’ experience earned architectural ownership from a single question. Second, they get pulled into higher-level conversations, because the people making decisions recognize someone who thinks about problems the way they do. Third, their own thinking sharpens, because the act of articulating a decision forces clarity that staying in your head never does.
That third effect is the one most developers underestimate. Writing down why you made a choice often reveals that your reasoning has gaps you didn’t notice. The decision that felt obvious when it lived in your head turns out to rest on an assumption you haven’t tested. The act of externalizing doesn’t just communicate your thinking: it improves it.
Edition #8 was about learning to read systems: seeing the business behind the code, the dynamics behind the team, the shifts behind the market. That skill is powerful, but only if someone else can see that you have it. Reading is perception. This is its complement: making your perception legible. Together they form the complete skill: the ability to see clearly and to be seen clearly.
The interview that proved the point
I’ve conducted hundreds of technical interviews over my career, including live coding sessions. The conventional understanding is that live coding tests whether the candidate can solve the problem. That’s wrong, or at least incomplete. An experienced technical manager already knows that most competent developers can solve most coding problems given enough time and a calm environment, neither of which exists in an interview.
What live coding actually tests is whether you can see how someone thinks. How they decompose a problem before writing anything. What questions they ask. How they respond when they’re stuck. Whether they can name what they don’t know and reason toward it out loud.
I’ve hired developers who didn’t solve the problem. They got hired because the way they thought about it told me more than the solution would have. They asked questions that revealed they understood the domain. They explained their approach before coding, so I could see the reasoning, not just the syntax. They said “I think this might fail here because...” and that sentence was worth more than a working function, because it showed judgment in real time.
I’ve also passed on developers who solved the problem quickly and silently. They produced the right output, but I learned nothing about how they got there. In a thirty-minute conversation, they gave me a diff and kept their thinking invisible. I had no way to evaluate the one thing I cared about most.
A company that only advances candidates who produce a correct solution in live coding doesn’t understand what the exercise is for. What the exercise actually reveals is the thinking, and a correct solution delivered in silence hides exactly what the interviewer needs to see.
The industry’s evaluation infrastructure is starting to formalize this. HackerRank, the platform that defined coding challenges for a generation, now evaluates what they call “AI fluency”: how developers collaborate with AI tools, the quality of their judgment when reviewing AI-generated code, the reasoning they apply when choosing between approaches. Their assessments increasingly measure thought process and problem-solving signals, because as AI handles more of the raw coding, the developer’s thinking becomes the primary differentiator, and evaluation is finally catching up to that reality.
The artifact library and what it’s been doing
Looking back at the exercises across these editions, I notice a pattern I didn’t plan. Every artifact I asked you to create was an exercise in making invisible thinking visible. Separating judgment from execution. Writing down how you make decisions. Capturing the reasoning behind a build before it fades into “that’s just how we do things.” Describing your vision precisely enough that someone (or something) else could act on it. Reading a system and writing down what you see.
None of those exercises asked you to write code. Every one of them asked you to externalize something that normally stays in your head. That’s what making thinking visible actually looks like in practice: not a single grand gesture, but a growing habit of giving your reasoning a shape it can survive in.
This week’s artifact makes that habit explicit.
Try This
Take a technical decision you made recently. An architecture choice, a tool selection, an approach to a bug, a feature you decided not to build, a refactoring you prioritized over new work. Something where your judgment shaped the outcome.
Write one page: not about what you built, but about why.
What problem were you solving? What was the context that made it a problem worth solving now? What approaches did you consider? What did you reject, and what was your reasoning? What trade-offs did you accept? What would change your mind about the choice you made?
When you’re done, show it to someone on your team. Not for approval, not for feedback on the decision itself. Show it for the experience of making your reasoning visible. Watch what happens. Notice what questions they ask: those questions tell you exactly what was invisible before. Notice whether the conversation that follows is different from the conversations you usually have about your work.
That difference is the gap this edition is about. The gap between what you do and what people see.
One page. One decision. The habit starts there.
The Deeper Cut
One of the hardest habits to build in developers is the practice of externalizing reasoning. In mentoring conversations, I see it constantly: developers who can evaluate code, design systems, and spot problems with real precision, and none of it reaches anyone else because they never developed the reflex to say it out loud. The thinking is sharp. The output is silent. The gap between those two is where careers stall without anyone, including the developer themselves, understanding why.
Paid subscribers get the thinking memo template: a structured format for documenting the reasoning behind technical decisions, designed to make invisible thinking legible without turning every choice into a formal document. It’s the same format I use in client work when a codebase assessment needs to convey not just what I found, but why it matters and what it means for the business.