Credentials are rarely the right first signal when you want to know if an engineer can actually do the job. Verified proof of performance under constraint is.
That realization got sharper for me last month when I read about Go grandmaster Shin Jinseo beating KataGo, one of the strongest Go-playing AIs in existence, while giving it a two-stone handicap. For non-Go players: a two-stone handicap means Shin started the game at a structural disadvantage. Not level ground. Uphill. And he still won. That is not a feel-good humans-vs-machines headline. That is a demonstration of domain depth so severe that a top-tier AI could not compensate for the head start.
Engineers face an equivalent credentialing crisis right now, and most of the industry is still reaching for the wrong solution.
Why Credentials Stopped Clearing the Bar
For about two decades, the hiring signal stack in software engineering was: degree, company brand, years of experience, and maybe a LeetCode score. The assumption underneath all of it was that credentials correlated with real capability. They never correlated perfectly, but they correlated well enough to be operationally useful.
Generative AI broke that assumption at the surface layer. An engineer with access to a capable LLM can now pass most screening interviews, produce plausible-sounding system design answers, and write reasonable code samples for take-home assignments. The screen is not broken in every dimension. It is broken in the dimensions that matter most: distinguishing genuinely senior engineers from well-prompted intermediates.
What does not break is performance under constraint. Shin did not beat KataGo by being lucky or by exploiting a niche bug in the model. He beat it by carrying domain knowledge so deep that a two-stone structural disadvantage did not reduce his margin enough to matter. The handicap was, in a perverse way, the signal. Without it, a win proves less. With it, a win proves almost everything.
What Adversarial Conditions Actually Reveal
There is a common piece of interview advice that goes: show your thinking, not just your answer. Good advice. Incomplete advice. Showing your thinking in a friendly, structured interview where you know you are being evaluated is entirely different from showing your thinking when the system is actively working against you.
Adversarial conditions are the ones where the environment does not accommodate you: production is on fire, the runbook is wrong, the data is dirtier than the schema promised, the stakeholder changed the requirements halfway through the quarter. Senior engineers accumulate proof under exactly these conditions. Most hiring pipelines never ask for it.
Incident records are the closest engineering equivalent to Shin's handicap win. An incident postmortem that you authored, with your name on the timeline, with a root cause that required novel reasoning, is verifiable proof of domain depth. Not proof of typing speed. Not proof of having read the right textbook. Proof that when the environment turned adversarial, you navigated it.
The same applies to design documents. Not the ones rubber-stamped in ten minutes, but the ones where you proposed an approach, someone pushed back with a real objection, and the final design shows evidence of that negotiation. Those documents are a record of your reasoning under constraint.
Shin's handicap win is unusual because Go has a formal system for imposing and recording constraint. Engineering mostly does not. That is the credentialing gap the industry needs to close.
The Portability Problem That Credentials Cannot Solve
Here is the scenario I have watched play out too many times. An engineer spends four years at a well-known company. They do genuinely good work. They are trusted by their team. Then they leave, and the hiring process at the next company treats them almost identically to a candidate who spent four years somewhere less prominent but did mediocre work. The company brand fades faster than the engineer's actual skills do.
This is the portable career problem. A resume line that says "Staff Engineer at [large tech company]" tells a hiring manager almost nothing about what you can do today at a different organization with different constraints, different systems, and different teammates.
Proof-based signals are more portable because they are specific. A public RFC you authored that describes a tradeoff decision, a contribution to an open-source project that involved non-trivial debugging, an incident report where your diagnosis is visible, a benchmark you ran and published with methodology intact: these travel with you. They do not depend on the prestige of your previous employer to carry meaning.
This is why platforms oriented around verified capability rather than resume lines matter. Skills Tech Network is built on exactly this premise: that ranking engineers by demonstrated, verifiable output produces better signal than ranking them by the credential stack. If you have shipped production systems under real constraints, there should be a way to show that without relying on someone else's logo.
Three Proof Signals That Actually Survive Scrutiny
Not all proof is equal. Some of what gets called "proof" is still proxied and easy to inflate. Here is what I would weight, and why.
Verified contribution history with non-trivial diffs. Open-source contributions where you can point to a specific pull request, explain the problem it solved, and describe what alternatives you considered. The diff itself is auditable. A reviewer can ask you to walk through it live. This is close to what it means to play with a handicap: you made the move in public, under real conditions, against a codebase that did not accommodate you.
Incident authorship with causal reasoning. Not every engineer gets to author public postmortems, but many companies will give you a sanitized version to share. The test is whether the document shows that you identified a non-obvious root cause. "Database was slow" is not a root cause. "Index cardinality collapsed after a schema migration changed the selectivity of the leading column" is a root cause. The depth of the causal chain is the signal.
Design decisions with explicit tradeoff documentation. The weakest design docs say: "We chose Kafka because it is scalable." The strong ones say: "We evaluated Kafka against Postgres-based queuing. For our write volume, Kafka's operational overhead was not justified until we crossed roughly 50k events per second sustained. We are at 8k. We shipped with Postgres and left the migration path documented." That is a reasoning artifact. It proves you understood the tradeoff space, not just the winning option.
If you want a framework for building this kind of portfolio deliberately, the Skills Tech Network profile system is worth looking at. It is designed to surface exactly these signals rather than asking you to summarize your experience in a 200-word bio.
Skin in the Game Is the Signal, Not the Win
The part of Shin's story I keep coming back to is not that he won. It is that he agreed to the handicap. Accepting a structural disadvantage before the game starts is a credibility move. It says: I am confident enough in my depth that I will make this harder for myself so the result is harder to dismiss.
Most engineers, when they think about demonstrating expertise, think about showing their best work in ideal conditions. Wrong direction. The engineers who build durable reputations are the ones who create records of their reasoning when conditions were not ideal, when they were wrong first and then corrected, when they proposed something and had to defend it against a sharp objection.
The job market right now rewards engineers who can do what an LLM cannot do on their behalf: produce a verified, auditable history of decision-making under real constraint. AI can generate a plausible system design. It cannot generate a postmortem with your name on it from 2022 where you caught a subtle race condition in a distributed lock implementation. That artifact belongs to you in a way that a generated answer never will.
Shin did not beat KataGo by being broadly capable. He beat it by being specifically, verifiably, testably deeper than the system could compensate for. That is the career architecture worth building.
Build a proof-backed profile
Skills Tech Network ranks technical talent by verified, demonstrated capability, not just resumes. If you have shipped production systems under real constraints and want a profile that shows the reasoning, not just the title, build it here.
The engineers who will still be irreplaceable in five years are the ones who can prove, under constraint, with a record attached, that their depth exceeds what the AI can simulate.