← Back to Blog

What is Proof of Work Hiring?

Why we test candidates on YOUR actual code, not generic coding puzzles.

📅 February 1, 2024 • ⏱️ 7 min read

You hired a brilliant engineer. Great resume. Aced the LeetCode interview. Strong references.

Then they start. And within weeks, you realize they can solve abstract puzzles but struggle with YOUR codebase.

Generic coding tests prove technical ability. They don't prove fit with YOUR specific environment.

This is why we use proof of work hiring: we give candidates a real problem from YOUR actual codebase and see if they can solve it.

The Problem with Generic Coding Tests

Most companies hire like this:

The Traditional Process:

  • Resume screening
  • Phone screen
  • LeetCode style coding challenge (invert a binary tree, solve the two sum problem)
  • System design interview
  • Hope they can work with your actual code

The result: You hire someone who can solve abstract puzzles but struggles with your legacy code, your tech stack, or your architecture.

Why Generic Tests Fail:

  • They test algorithm knowledge, not real world skills: Your codebase is not full of binary trees and graph traversals
  • They do not test for code quality: Can they write maintainable, production ready code?
  • They do not test architectural thinking: Can they navigate and extend an existing codebase?
  • They do not test debugging skills: Can they find and fix issues in unfamiliar code?
  • They are gameable: People practice LeetCode for months. That does not mean they can build products.

Our Approach: Real Code, Real Problems

We do not give candidates toy problems. We give them YOUR actual code.

Here is How It Works:

  • Step 1: You send us a real problem from your codebase (could be a bug, a feature request, or an optimization task)
  • Step 2: We give candidates access to the relevant code and problem description
  • Step 3: They work on it on their own time (2 to 4 hours, compensated)
  • Step 4: They submit their solution with documentation
  • Step 5: We review: Did they understand your code? Can they extend it? Is their solution production ready?

Key Difference:

Traditional tests ask: Can you solve abstract problems? We ask: Can you work with THIS company's code?

Important: This Is Not a Basic Coding Test

Every candidate in our pool has already passed basic coding assessments.

What We Have Already Verified:

  • They can code: Passed algorithm and data structure tests
  • They understand ML and AI fundamentals: Completed framework specific challenges
  • They can ship: Demonstrated ability to build and deploy models
  • They communicate well: Clear documentation and explanation skills

The proof of work test on YOUR code answers a different question:

This engineer is technically capable. But can they thrive in OUR codebase, with OUR architecture, solving OUR specific problems?

Real Examples of Proof of Work Tests

Example 1: ML Model Optimization

Company: E commerce startup with recommendation engine

Problem: Our recommendation model is slow. Here is the code. Can you identify bottlenecks and suggest optimizations?

What it tests: Can they read ML code, profile performance, and make practical trade offs?

Time: 3 hours

Example 2: RAG System Debugging

Company: B2B SaaS with AI chatbot

Problem: Our RAG system is returning irrelevant results. Here is the retrieval code. Debug and fix it.

What it tests: Can they debug LLM applications, understand vector databases, and improve retrieval quality?

Time: 4 hours

Example 3: Feature Implementation

Company: Computer vision platform

Problem: Add batch processing support to our image classifier. Here is the existing single image code.

What it tests: Can they extend existing code, maintain architectural consistency, and write production ready features?

Time: 3 hours

The Bottom Line

Generic coding tests prove candidates can code. Proof of work on YOUR code proves they can succeed at YOUR company.

Key takeaways:

  • All our candidates already passed basic coding tests. This is about fit with YOUR specific codebase
  • Real code reveals real ability better than any algorithm puzzle
  • You see exactly how they work before making a hiring decision
  • Candidates appreciate real problems over abstract brain teasers

Stop hiring based on LeetCode performance. Hire based on who can actually work in YOUR environment.

We Test Every Candidate on Real Code

That is why we only present candidates who have already proven they can work in your specific environment, not just pass generic tests.

See How We Vet Talent →