MEET THE FOUNDER

I failed a coding assessment
because I didn't know
math.gcd()

So I built a platform that evaluates engineers
on how they actually think, not what they've memorized.

THE INCITING INCIDENT

A disaster over a denominator.

I took a coding assessment and because I didn't know how to get the GCD (Greatest Common Denominator, found in math.gcd()) it was a disaster.

The thing is, I've simply never needed to find the GCD or derive the Least Common Multiple for any of the problems I've solved. If I did, I would certainly look it up. And unless I came to rely on that algorithm regularly, I'd bet that even three or four months later I wouldn't have it memorized. I'd have it catalogued in my notes. My answer would come faster. But not from memory.

LCM(a, b) = (a × b) / GCD(a, b)

Is this the kind of thing most engineers just have memorized?

I sat there afterward, turning it over. Not the math. The system. This is how we evaluate technical talent in 2026? A timed puzzle measuring whether you've encountered a specific standard library function? This felt like a relic. A solution that outlived the problem it was meant to solve, still lingering long after its relevance, and most critically its effectiveness, had quietly expired.

What other class of industry professional uses "show me what you can do in a scenario you do not, will not, and would not work in" as the evaluation metric for hire?

WHO I AM

Self taught. Shipped. Still building.

LeChristopher Blackwell

My name is LeChristopher Blackwell. I graduated Hack Reactor in 2016 and kept going. Python and JavaScript. I deepened my craft through YouTube, Coursera, and Udemy across full stack development, machine learning, LLM integrations, data pipelines, warehousing, and penetration testing.

No CS degree. Just a bootcamp, years of building things that work, breaking things that don't, and an unshakeable belief that the best way to learn engineering is to engineer.

I didn't follow a curriculum. I followed problems. Each project pulled me deeper into a new domain. Graph databases. Autonomous trading systems. Multiagent AI coordination. Browser security. Infrastructure as code. Not because a syllabus told me to, but because the thing I was building demanded it.

That's how I learn. That's how most working engineers learn. And no assessment has ever measured it.

THE WORK

None of this showed up
on the assessment.

Every project below was designed, built, and shipped solo. Here's what I was actually building while that test wanted me to recall math.gcd().

S

SPICE ›

Autonomous Crypto Trading Engine

51 strategies across 8 categories. 280+ API endpoints. 4,100+ tests. Monte Carlo validation, Fargate burst compute, realtime WebSocket streams.

PythonFastAPIReactPostgreSQLRedisAWS
P

PROVE ›

AI Powered Skill Evidence Graph

A ReAct agent that ingests codebases and builds skill claims backed by evidence. Neo4j knowledge graph, vector embeddings, semantic matching against job descriptions.

Neo4jClaude APIFastAPITree-sitterD3.js
P

PANEL ›

Multiagent PRD Generator

13 specialized AI debate agents (Architect, Security, Backend, UX, QA, DevOps, ML) argue over your product requirements. Three judge agents score the debate.

AutoGenGPT-4oVue 3FastAPISSE
F

flowhana ›

Performer Marketplace

Full stack SaaS marketplace for Hawaii entertainers. Provider profiles, search, booking, messaging, and Stripe Connect payments.

Next.js 14FastAPIPostgreSQLStripeClerk
B

bloodtrail › + crackpedia ›

Security Research Tools

Active Directory attack path visualization with 63+ Cypher queries. A 734 command pentesting encyclopedia. Built during OSCP preparation. Tools I needed that didn't exist.

Neo4jD3.jsElectronReactPython

This is not a complete list. It's the work of someone who builds constantly. Not for interviews. Not for certifications. Because problems are interesting and software is the medium.

THE THROUGH LINE

From evidence to process.

Look at PROVE. I built an AI agent that crawls your codebases and constructs a knowledge graph of skill claims backed by evidence. Not "I know React" on a resume. Instead: here is the component architecture, here is the state management pattern, here is where the complexity lives. Evidence.

That was the first attempt at solving a problem I couldn't articulate yet: how do you prove what you can do?

But PROVE looked backward. It analyzed finished code. It still missed the most interesting part. The journey. The dead ends. The moment you pivoted from one approach to another. The way you used AI tools. The debugging session that took forty minutes before the breakthrough.

MethodProof is the answer I was circling. Not looking backward at evidence. Looking forward at process. A knowledge graph that builds as you work, mapping every action, every decision, every pivot into a visual timeline that anyone can understand.

PROVE → MethodProof

PROVE asked "what did you build?" MethodProof asks "how did you build it?"

THE SUFFICIENT STATISTIC

This problem runs in my family.

My great grandfather was David Harold Blackwell. Mathematician. Statistician. Game theorist. The first Black scholar inducted into the National Academy of Sciences. The first Black tenured professor at UC Berkeley. Published over 90 papers across six fields of mathematics. Received the National Medal of Science from President Obama.

The theorem.

In 1947, he proved what became the Rao-Blackwell theorem. The core idea is deceptively simple: if you measure the right thing, the answer is always better. Not sometimes. Not usually. Always. Mathematically guaranteed.

The word for "the right thing" in statistics is a sufficient statistic. Most people hear "sufficient" and think "good enough." In mathematics it means something far more powerful: complete. Containing everything in the data that matters to what you're measuring. Nothing wasted. Nothing lost.

"I'm not interested in doing research and I never have been. I'm interested in understanding, which is quite a different thing."

David Harold Blackwell, 1919 – 2010

Understanding. Not performance. Not recall. Not whether you can reproduce an algorithm under pressure. Understanding.

The insufficient statistic.

A coding assessment measures the noise and discards the data.

It throws away the most important information about how an engineer works — the thinking, the navigation, the tool selection, the recovery from failure — and keeps only the least informative signal: did you memorize this function? That is an insufficient statistic. It captures almost none of what it claims to measure.

The full spectrum.

MethodProof is Full Spectrum Engineering Process Intelligence. It captures the sufficient statistic for engineering evaluation — not a slice, not a proxy, but the full spectrum of how you work. How you think through a problem. How you navigate complexity. How you use your tools. How you respond when something breaks.

The entire process, compressed into exactly what matters.

My great grandfather spent his career proving that better measurement gives better answers. I'm building the better measurement.

THE THESIS

The assessment is a relic.

Here's what I believe. The coding assessment was once the best option available. When hiring was local, when engineering meant one language and one paradigm, when there was no way to see someone's actual work. A timed test in a sterile environment was a reasonable proxy.

That time is over.

Engineers today operate across languages, frameworks, cloud providers, AI tools, and abstraction layers that didn't exist five years ago. The job is navigating complexity. Knowing what to look up, when to pivot, how to decompose a problem, when to lean on AI and when to trust your instincts.

None of that shows up on a timed assessment. What shows up is whether you memorized math.gcd().

Perhaps I suffer a predisposition towards bias on the subject. But truly, what other class of industry professional uses "show me what you can do in a scenario you do not, will not, and would not work in" as the KPI evaluation metric for hire?

We don't ask architects to design a building in 45 minutes without reference materials. We don't ask surgeons to operate under artificial constraints that bear no resemblance to the operating room. We don't ask lawyers to argue a case they've never seen with no access to precedent.

But we ask engineers to solve puzzles in an environment stripped of every tool, resource, and workflow that makes them effective. And then we call the result an evaluation.

MethodProof is my answer. Not an incremental improvement to the assessment. A replacement for it. Watch an engineer work in their actual environment, with their actual tools, on a problem that resembles actual work. Capture the process. Map the decisions. Let the graph speak for itself.

THE MISSION

I built this because I had to.

Not because it was a good market opportunity. Not because an investor told me to. Because I sat in that assessment, watched my screen fill with a problem that had nothing to do with my work, and thought: there has to be something better than this.

There is now.

Sign Up Free Back to Home