Career Development · The guide

Proof of Work vs. Credentials: What Actually Gets You Hired for New Roles

Why verifiable work beats certificates when hiring for new AI-era roles, what counts as real proof, how MitHub verifies case studies and how to present yours.

Mauricio Esparza By ·Published ·10 min read
mithub.club
Short answer

For new roles like GTM engineering or AI automation, verifiable work usually beats credentials because no certificate can show that you solved a real problem. A credential says you studied; proof of work shows a situation, what you built, the result and evidence someone else can check. Credentials can open a door, but proof is what reduces the hiring risk.

For new roles such as GTM engineering, revenue engineering or AI automation, verifiable work beats credentials because nothing on a certificate proves you solved a real problem. A credential says you studied a topic. Proof of work shows a situation, what you built, the result and evidence someone else can check. Credentials can still open a door, but proof is what lowers the risk for the person hiring you, and risk is what hiring decisions are really about.

This guide explains why that shift is happening, what the research does and does not say, what actually counts as proof, how MitHub verifies case studies, and how to present your own proof so it gets taken seriously.

In short

  • New roles have no established degree, so employers look for evidence of the work itself.
  • Employers say they value skills, but many have not changed how they hire. That gap rewards people whose proof is easy to check.
  • Proof has levels. A claim is weak; a verified, paid result is strong. MitHub calls this the proof ladder.
  • A strong proof artifact has four parts: situation, path, result, evidence.
  • At MitHub a case study is published only after payment, delivery, audit, approval, client satisfaction and client consent.

Why credentials lose power in new roles

A credential is a proxy. It tells an employer that you probably have some knowledge, because a school or a platform checked you at some point. Proxies work reasonably well when a job is stable and the path into it is standardized: an accountant, a nurse, a civil engineer.

They work badly when the job is new. Nobody graduated in "GTM engineering" ten years ago. The tools change every few months. The work combines data, automation, AI and a commercial understanding of how a company makes money, which is exactly what we describe in what GTM engineering is. A course certificate in one tool says very little about whether you can connect that tool to a sales process and move a number.

So hiring managers for these roles face a problem: the usual proxy is missing or weak. They fall back on the most direct signal available, which is evidence that you already did a version of the work.

What the research actually says

It is easy to overstate this. "Degrees are dead" is not what the data shows. The more accurate picture has three parts.

1. Employers rely on work experience more than degrees

In the World Economic Forum's Future of Jobs Report 2025, employers were asked how they assess skills when hiring. Work experience was the most common method, with 81% of businesses expecting to keep relying on it over 2025–2030. Skills assessments came second at 48%, and a university degree requirement came third at 43%. The report notes that, compared with the previous edition, employers are leaning more on work experience and testing than on traditional credentials.

Work experience is, in the end, a form of proof of work. The question for anyone entering a new field is how to produce that evidence before someone gives you the job title.

2. Skills-based approaches expand who can be considered

LinkedIn's Economic Graph Research Institute has modeled what happens when employers look at skills instead of prior job titles. In its March 2025 research note, a skills-based approach expanded global talent pools by 6.1x on average, and by 8.2x for AI roles. Its earlier Skills-First report reached a similar conclusion with different data.

Read that carefully: this is a model of how many people could qualify, not a measure of who actually got hired. It shows that skills are a wider door than titles. It does not show that employers walk through it.

3. Announcing skills-based hiring is not the same as doing it

This is the part most articles skip. The Burning Glass Institute and Harvard Business School studied companies that dropped degree requirements and found that sustained changes in hiring were rare. As HR Dive reported, the researchers estimated the shift affected fewer than 1 in 700 hires in 2023. About 45% of the companies that announced changes showed no meaningful difference in who they hired, while about 37% were classified as leaders that actually followed through.

Why would a company remove a degree filter and still hire the same people? One likely reason: removing a filter does not tell you what to look for instead. If a hiring manager cannot quickly evaluate a candidate without a degree, they default to the familiar profile.

That is the opportunity. The talent who wins in skills-based hiring is not the one who simply lacks a degree. It is the one who makes their capability easy to verify.

Why proof of work lowers hiring risk

Think about the hire from the company's side. Every hire is a bet with three questions behind it:

  1. Can this person do the work?
  2. Can they do it in a context like ours?
  3. Will the work produce a result we care about?

A credential partially answers question one. It says nothing about two and three. A good proof artifact answers all three: it shows the work, the context it happened in and the result it produced.

This matters even more in the AI economy. When AI can execute a growing share of repetitive tasks (the premise of the new game), the value moves toward people who can decide what to build, direct AI and systems, and own the outcome. MitHub describes that shift with its capability ladder: Doer → Director → Designer → Owner (see director vs. doer). A certificate can show you learned to do something. Only proof can show you designed a system or owned a result.

What counts as proof (and what does not)

Not everything you can show is proof. Here is the distinction MitHub uses.

Looks like proofWhy it is weakReal proof
"Certified in Tool X"Shows you finished a course, not that you applied itA working workflow built in Tool X, with what it did
A screenshot of a dashboardNo context, no source, cannot be checkedThe dashboard, its data source and the decision it changed
"Increased sales by 40%"No baseline, no timeframe, no attributionBaseline, period, what you changed, how it was measured
A list of tools on a CVFamiliarity is not capabilityOne system described end to end
A testimonial with no detailPleasant, not specificA reference who can describe the problem and your role

A useful test: could a skeptical stranger check this without talking to you? If not, it is a claim, not proof.

The MitHub proof ladder

Proof has levels. Knowing where your evidence sits tells you what to build next.

  1. Claim. "I know n8n." Nothing to inspect.
  2. Artifact. A workflow, a table, a script or a document that exists and can be opened.
  3. Applied artifact. The artifact solved a defined problem, even a practice one, and you can explain the situation and the decisions you made.
  4. Result. The artifact changed a number in a real context: time saved, leads enriched, response time reduced, meetings booked.
  5. Verified result. Someone other than you confirms the result: the client, a manager or an auditor.
  6. Repeated result. You produced verified results more than once, in different contexts. This is where people start treating you as an owner of outcomes, not an executor of tasks.

Most people applying for new roles stop at level 1 or 2. Moving even one level up makes you stand out. If you have no experience yet, start at level 3 with practice projects; our guide on how to build a portfolio without experience shows how.

The anatomy of a strong proof artifact

The sixth chapter of the Revenue Reverse Engineering faculty, your case study, structures proof in four parts. Use the same structure whether the project is paid or practice.

Situation

What was the context and the problem? Be specific about the business, not only the tool. "A multi-location business had leads waiting hours for a first contact" is a situation. "I wanted to learn Clay" is not.

Path

What did you decide and build, and why? This is where you show judgment. Following the method from follow the money, a strong path starts at the payment and traces backwards to where revenue was leaking before anything gets built.

Result

What changed, measured against a baseline, over a stated period? If the result is small, say so. A modest, honest result beats an inflated one that falls apart in the first interview question.

Evidence

What can someone else inspect? Workflow exports, before-and-after data, a recording of the system running, a reference, a client approval. Remove anything confidential; anonymize client names unless you have permission.

Here is how that framing sounds with a real MitHub reference point: MitHub's pioneers have built AI voice campaigns that ran across 28 live branches of a multi-location lending business, including a 10-branch pilot with 13,159 AI calls. Notice what that sentence does: it names the scale, the context and a countable output, without naming a client or inventing an outcome.

How MitHub verifies case studies

A portfolio full of unverified claims teaches employers to distrust portfolios. That is why MitHub does not publish a case study because someone says it happened. A case study is published on MitHub only after this sequence is complete:

  1. The company paid. The work had real economic value to someone.
  2. The talent delivered. The work was completed, not just started.
  3. MitHub audited the work. The work and its evidence were reviewed.
  4. It was approved.
  5. The company was satisfied.
  6. The client agreed to publish.

Each step closes a different gap. Payment separates real work from exercises. Delivery separates finished work from promises. The audit separates evidence from storytelling. Client satisfaction separates output from value. Consent protects the client and keeps the proof ethical.

The order matters too. Proof comes after value was created, never before. That is the same logic MitHub applies to its whole model: learn, build, prove, earn, in that order.

How to present your proof

Having proof is half the job. The other half is making it fast to evaluate. Hiring managers for new roles often do not have a checklist, so give them one.

Lead with the result, then show the path

Open each project with one line: the context, the result and the evidence type. For example: "For a practice project, I rebuilt a lead-routing process for a hypothetical 12-location clinic; the workflow export and a test run are linked." Details come after.

Match your proof to the job's real problem

Read the job description and ask what outcome the company is paying for. If they need faster lead response, your enrichment project matters less than your routing project. Put the most relevant proof first.

Label practice work honestly

"Practice project," "simulated data" and "personal system" are not weaknesses. Hiding them is. Honest labeling is itself a signal of the judgment employers are trying to hire.

Make the evidence inspectable in under five minutes

A short screen recording of the system running, a one-page write-up, and a link to the artifact. If a reviewer has to request access or schedule a call to understand it, most will not.

Show your level on the capability ladder

Say explicitly what you did: executed a task, directed AI to do it, designed the system, or owned the result. Overclaiming ownership is the fastest way to lose credibility in an interview.

Keep one proof page, not ten profiles

One place with your best two or three case studies beats scattered posts. On MitHub, talent profiles live at /talento.

Where credentials still help

Proof of work is not an argument against learning formally. Credentials still help in three situations:

  • Regulated work. Licensed professions require them, full stop.
  • Early filters. Some companies still screen by keywords and certificates before a human looks at proof.
  • Structured foundations. A good program saves you from learning the fundamentals by trial and error.

The mistake is treating the credential as the finish line. Use learning to build capability, then turn capability into proof. That is why MitHub's foundations are free and each chapter of the Revenue Reverse Engineering faculty ends in one proof rather than a badge.

A 30-day plan to move up the proof ladder

For example, if you are starting from a claim-level CV:

  • Week 1: Pick one business problem. Choose a revenue leak you understand, such as slow lead response or dirty CRM data. Write the situation in five sentences.
  • Week 2: Build the smallest working system. One workflow, one enrichment table or one report. Record it running.
  • Week 3: Measure. Define a baseline and a result, even on simulated or public data. Write down what did not work.
  • Week 4: Package and get reviewed. Write the four-part case study, then ask someone experienced to try to break it. Fix what they find.

At the end you will have one level-3 artifact that most applicants do not have. Repeat with a real client, and you move toward verified results.

The bottom line

Credentials describe what you were taught. Proof describes what you can do for someone else. In new roles where no credential fully fits, employers lean on evidence of work, and the research shows that even companies that say they hire for skills often still struggle to evaluate it. Make your capability easy to check: a clear situation, a defensible path, an honest result and evidence a stranger can inspect. That is what turns learning into market value.

Frequently asked questions

Are certificates worthless for AI and GTM roles?

No. A certificate can show you covered the basics and can help you pass a first filter. It just cannot show that you solved a real problem, so it rarely wins the hire on its own for new roles.

What counts as proof of work?

A specific situation, what you built or changed, a measurable result and evidence another person can check, such as a working workflow, a before-and-after metric, a reference or a published case study.

Can a practice project count as proof?

Yes, if it is labeled honestly as a practice project and the reviewer can inspect it. It sits lower on the proof ladder than paid work with a verified result, but it is far stronger than a claim.

How does MitHub verify a case study?

A MitHub case study is published only after the company paid, the talent delivered, MitHub audited the work, it was approved, the company was satisfied and the client agreed to publish.

Sources

  1. Future of Jobs Report 2025 — World Economic Forum (accessed 2026-09-17)
  2. Skills-Based Hiring: The Long Road from Pronouncements to Practice — The Burning Glass Institute and Harvard Business School Project on Managing the Future of Work (accessed 2026-09-17)
  3. Report: Employers don't practice what they preach on skills-based hiring — HR Dive (accessed 2026-09-17)
  4. Skills-Based Hiring: Increasing Access to Opportunity (March 2025) — LinkedIn Economic Graph Research Institute (accessed 2026-09-17)
  5. Skills-First: Reimagining the Labor Market and Breaking Down Barriers — LinkedIn Economic Graph (accessed 2026-09-17)
Proof of WorkSkills-Based HiringCareer DevelopmentCase Studies
Mauricio Esparza
Mauricio EsparzaGTM Systems Lead · Revenue Engineer · Founder of MitHub. Designs and runs revenue systems for multi-location businesses: AI voice campaigns, enrichment, CRM automation and attribution. Founded MitHub to teach the method in the open.

Part of Career Development on MitHub.

Keep going

Career Development

How to Build a Portfolio Without Experience (Revenue and AI Automation Edition)

Build a portfolio with no job history: pick real business problems, build practice systems in revenue and automation work, and document proof others can check.

Read · 6 min →mithub.club
Career Development

Learn, Build, Prove, Earn: The Operating Loop Behind MitHub

How MitHub's loop works: learn a capability, build something real, prove it with verifiable evidence, earn from it, then improve. Why the order matters.

Read · 7 min →mithub.club
AI Careers

The Skills That Make You More Valuable in the AI Economy (and How to Stack Them)

Which skills labor-market data says are rising, why combinations beat single skills, and a MitHub framework to stack AI, business and judgment skills.

Read · 6 min →mithub.club
AI Careers

How to Become More Valuable in the AI Economy

Your market value in the AI economy rises with your ability to create useful outcomes. MitHub's thesis, what labor data shows, and a 90-day plan to act.

Read · 10 min →mithub.club
AI & Automation

Director vs Doer: How AI Changes Knowledge Work

AI is shifting knowledge work from doing tasks to directing them. Learn MitHub's ladder, Doer to Director to Designer to Owner, and how to climb it safely.

Read · 6 min →mithub.club
GTM Engineering

How to Become a GTM Engineer: Skills, Stack and a 90-Day Plan

A practical path to becoming a GTM engineer: the skills that matter, the tools to learn, a 90-day plan and three proof-of-work projects that companies notice.

Read · 7 min →mithub.club

Career Development: all articles

Career Development

Deliberate Practice for Knowledge Workers

What Ericsson actually found, why the evidence is weakest for professions, and how to engineer reps and feedback into automation and revenue work.

Read · 8 min →mithub.club
Career Development

How Skills Increase Income (and Which Ones Do)

The mechanism behind skill and pay: what wage research really shows, the four ways a skill converts into money, and how to test a skill before you learn it.

Read · 8 min →mithub.club
Career Development

How to Build a Portfolio Without Experience (Revenue and AI Automation Edition)

Build a portfolio with no job history: pick real business problems, build practice systems in revenue and automation work, and document proof others can check.

Read · 6 min →mithub.club
Career Development

How to Write a Case Study for Your Portfolio

A sentence-level template for portfolio case studies: the seven blocks, the number contract, the permission ladder, and what to publish when you signed an NDA.

Read · 8 min →mithub.club
Career Development

Learn, Build, Prove, Earn: The Operating Loop Behind MitHub

How MitHub's loop works: learn a capability, build something real, prove it with verifiable evidence, earn from it, then improve. Why the order matters.

Read · 7 min →mithub.club
Career Development

Skill Stacking: How Combined Skills Raise Your Value

Skill stacking combines good-enough skills into a rare combination. Where the idea came from, what hybrid-job data shows, and how to build a stack that pays.

Read · 8 min →mithub.club

Related topics