The Zombie in My Room Inspired Me to Build an AI Recruitment Tool

ADAM — Mon, 13 Apr 2026 18:04:25 +0000

My roommate looked like a zombie

Not the scary kind. The kind that walks around with empty eyes, a coffee in hand and hasn't slept more than 4 hours in weeks.

He was an HR professional. And every single night, I'd watch him hunched over his laptop, manually reading through hundreds of CVs. Highlighting. Comparing. Copy-pasting into spreadsheets. Sometimes until 3AM.

One night I finally asked: "Is there no tool for this?"

He laughed the tired kind. "There are, but they're either too expensive, too generic or just glorified keyword matchers. None of them actually read the CV."

That answer haunted me for weeks. Then I started building.

The Problem with "AI" Recruitment Tools

Most ATS (Applicant Tracking Systems) that claim to use AI are doing one thing:
keyword matching.

They scan for words like "Python" or "5 years experience" and rank candidates based on how many boxes they tick. Which sounds fine until you realize:

A great candidate who wrote "half a decade of Python" gets ranked lower than someone who keyword-stuffed their CV
Context is completely ignored. "Used Python once in college" and "Led a 10-person Python backend team" look the same to a keyword matcher
HR still ends up reading every CV anyway, just with a worse list order

My roommate wasn't wrong. The tools were broken.

So I Built TalentFlow

TalentFlow is an end-to-end AI recruitment platform. Not just a CV screener the full flow:
screening, pipeline management, interview scheduling, offer letters with digital signatures and an employee database.

But the heart of it is the AI screening engine. And the key decision I made early:
use a real LLM, not keyword matching.

Instead of looking for words, the AI actually reads the CV. It understands that a "System Administrator" is relevant for a "Network Engineer" role. It knows that "led a team" implies seniority. It can tell the difference between someone who used a tool and someone who built systems with that tool.

The result: a 0–100 score per candidate, with full reasoning that HR can actually read and trust.

How It Works (Without Giving Away the Secret Sauce)

I'm keeping the implementation details close to the chest, but here's the general flow:

1. HR defines criteria
Not job descriptions specific, weighted criteria. Things like:

"Minimum Undergraduate Degree, preferably Computer Science or related field"
"At least 3 years backend experience"
"Has worked in a fintech or startup environment"

2. Upload CVs in bulk
Hundreds at once. The system parses the PDFs, extracts structured data (education, experience, skills, certifications), and deduplicates repeated sections automatically.

3. LLM evaluates each CV against the criteria
This is where the magic happens. The LLM doesn't just look for keywords it assesses relevance contextually. Is this person's background actually relevant to what you need? It explains its reasoning for every criteria point.

4. Deterministic scoring layer
Here's something I'm actually proud of: the final score isn't purely AI-generated. After the LLM extracts and assesses facts, a deterministic scoring engine calculates the actual 0–100 score using clear rules. Education level comparisons, years of experience math, certification
counts these are calculated precisely, not "guessed" by AI.

This separation matters. AI handles what AI is good at (understanding context, reading nuance). Code handles what code is good at (math, consistency, reproducibility).

5. Pipeline, interviews, offers
Candidates move through a visual pipeline. HR can take notes, send interview invitations via email, generate offer letters from PDF templates, collect candidate signatures digitally, and move them to an employee database all without leaving the platform.

The Org System: Built for Real HR Teams

One thing I learned from my roommate: HR is never one person.

So TalentFlow has a full organization system. Teams share a workspace same pipeline, same candidate data, same screening results. Credits (for AI screening) are shared across the org. Invite teammates with a code, and they're in.

When someone leaves the org, their personal credit balance is restored. No data gets mixed up.

What I'd Do Differently

Underestimated PDF parsing complexity.
CVs are a mess. Tables, columns, weird formatting, image-based PDFs. I spent way more time on the parser than I expected. The deduplication logic alone making sure the same experience section doesn't appear twice after parsing took multiple iterations.

Start with multi-tenancy in mind from day one.
I added the organization system later, which meant going back and scoping every single database query. Lesson learned: if your product will ever be used by teams, design for teams from the start.

LLM costs add up fast.
Processing hundreds of CVs in parallel is genuinely fast but it costs money per token. That's why TalentFlow uses a credit system. Users buy credits, each screening costs 1 credit. Transparent, predictable, no surprise bills.

The Thing That Made It Real

A few weeks after I launched a beta, I sent the link to my old roommate.

He replied the next morning:

"I processed 300 CVs last night in 45 minutes. I slept at 11."

That was enough.

Try It

TalentFlow is live at talentflow.debuggo.id.

100 free credits when you sign up. No credit card required.

If you're building something in the HR tech space, or just curious about how LLMs can be applied beyond chatbots I'd love to hear your thoughts in the comments.

Built with LLM + JavaScript. Deployed and maintained by one person.

Questions about the architecture? Drop them below.

REST API vs GraphQL vs gRPC - Which One Should You Actually Use?

ADAM — Mon, 13 Apr 2026 12:02:48 +0000

Every backend developer hits this question eventually.

You're starting a new project and someone in the team says "let's use GraphQL" while another insists "just REST, keep it simple." Meanwhile the senior dev quietly suggests gRPC and half the room goes silent.

Let's break it down.

The Short Answer

REST : simple, universal, works everywhere
GraphQL : flexible, client controls the data
gRPC : fast, strict contract, built for microservices

Now the longer one.

REST API

Uses standard HTTP methods. You've seen this a thousand times:

GET    /users      → fetch all users
POST   /users      → create a user
PUT    /users/1    → update user
DELETE /users/1    → delete user

The problem: over-fetching and under-fetching. You either get too much data or you need 3 requests to get what you need.

Use it when: public APIs, simple CRUD, small teams, fast delivery.

GraphQL

One endpoint. The client asks for exactly what it needs:

query {
  user(id: 1) {
    name
    posts { title }
  }
}

No wasted data. The server returns exactly that shape.

The problem: caching is harder, N+1 queries if you're not careful, overkill for simple apps.

Use it when: multiple clients (web + mobile) needing different data shapes, complex relational data.

gRPC

Built by Google. Uses Protocol Buffers instead of JSON binary format, much faster.

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

Strict contract. Both sides must agree on the schema. Auto-generates client code in
multiple languages.

The problem: not human-readable, limited browser support, high learning curve.

Use it when: microservices talking to each other internally, high-throughput systems, streaming.

Quick Comparison

	REST	GraphQL	gRPC
Protocol	HTTP/1.1	HTTP/1.1	HTTP/2
Format	JSON	JSON	Protobuf
Flexibility	Medium	High	Low
Performance	Good	Good	Excellent
Learning curve	Low	Medium	High
Browser	✅	✅	⚠️

The Real World Answer

Most production systems mix all three:

REST → public-facing APIs, third-party integrations
GraphQL → main client-server communication
gRPC → internal service-to-service

You don't pick one forever. You pick the right tool for the right layer.

Conclusion

Understanding why you choose a technology matters more than choosing the "right" one.

That's what separates junior from senior.

📖 Want the full deep-dive? I wrote a more detailed version with code examples and real-world use cases over on DebugGo.id:
REST API vs GraphQL vs gRPC - Which One Should You Actually Use?

What's your stack using right now? Drop it in the comments.

DEV Community: ADAM