DEV Community: sneha grian

I Built ProofMap Because Recruiters Don’t Trust Resumes Anymore

sneha grian — Fri, 06 Mar 2026 22:51:48 +0000

The developer job market right now is… chaotic.

Hundreds of applicants.

Everyone listing the same stack.

Python
React
Node.js
Docker
AWS
Microservices
CI/CD

Scroll through enough resumes and they start looking identical.

And honestly, I kept wondering something.

How do hiring managers actually filter developers anymore?

Like seriously.

If everyone lists the same technologies…
how do you figure out who actually built something with them?

That question stuck with me for a while.

And that curiosity eventually turned into a project I call ProofMap.

👉 https://proofmap.snehagrian.dev
👉 https://github.com/snehagrian/proofmap

But the idea didn’t appear randomly.

The Moment That Made Me Think About This

During one of my recruiter conversations, something interesting came up.

The recruiter explained something that made a lot of sense.

They said in today’s hiring environment, resumes alone are not always enough.

Not because resumes are useless.

But because so many candidates apply, and filtering them becomes extremely difficult.

And there’s another complication.

A lot of engineers who work in companies can’t publicly share the projects they worked on.

If you’ve worked in corporate environments you already know why.

Most production work is protected by:

• company IP
• licensing restrictions
• internal systems
• NDAs

So even if someone worked on something complex, they might not be able to show it publicly.

Which creates an interesting situation.

The recruiter explained that when hiring managers want an extra signal, they often check something else.

GitHub.

Not as a replacement for experience.

But as a way to see:

• how someone builds things
• how they structure projects
• whether they experiment with technologies
• whether their listed skills show up in real work

Basically:

Do the skills on the resume actually appear somewhere in their work?

That thought stayed with me.

The Curiosity That Started This Project

After that conversation I kept thinking about something.

What if there was a way to automatically answer this question:

Do my GitHub projects actually support my resume?
Which skills are proven?
Which ones are missing proof?
How can I improve that?

Not manually.

Automatically.

So I started building something that connects two things developers already have.

Resume Skills
+
GitHub Repositories

That project became ProofMap.

What ProofMap Actually Does

ProofMap analyzes your GitHub repositories and tries to answer one simple question.

How much of your resume is actually supported by your GitHub projects?

The first thing it generates is something called a Skill Readiness Score.

Example output:

This basically means:

Around half of the skills listed in the resume appear in GitHub projects.

The rest might not have visible proof yet.

Step 1 — Detect Skills That Exist in Your Code

The system scans GitHub repositories and extracts signals like:

• programming languages
• dependency files
• frameworks
• repository structure
• project patterns

Then it builds a list of skills detected in your repositories.

Example:

Skills Present

React
Node.js
REST APIs
JavaScript
TypeScript
MySQL
Python

These are labeled Skills Present (Proven).

Meaning the technologies actually appear in your projects.

Step 2 — Detect Skills That Are Missing

Next, the system compares:

Resume Skills
vs
GitHub Evidence

Then it highlights the skills that don’t appear in repositories yet.

Example:

Skills Not Present

AWS
Jenkins
CI/CD
React Native

This doesn’t mean the developer doesn’t know these skills.

It simply means:

GitHub doesn’t currently show proof for them.

And that’s where things get interesting.

Step 3 — Click a Missing Skill → Generate an AI Roadmap

If you click a missing skill, the platform generates AI-powered project ideas.

For example, selecting Jenkins might generate suggestions like:

Continuous Integration Pipeline
Multi-Branch Pipeline Project
Jenkins Plugin Development

It also suggests what your GitHub project should include:

• pipeline configuration
• automated testing
• deployment workflows

Now you’re not just learning randomly.

You’re building projects that prove the skill.

Step 4 — Sometimes You Don’t Need a New Project

One thing I wanted the system to do was avoid suggesting random tutorial projects.

Sometimes the best way to learn something new is to upgrade an existing project.

So the AI analyzes your repositories and suggests things like:

Add Docker containerization to your Node.js API.

Implement CI/CD pipeline automation for your current repository.

Instead of starting from scratch, you improve what you already built.

Step 5 — If the Skill Doesn’t Fit Your Existing Projects

If a missing skill doesn’t match your current repositories, the AI suggests new project ideas.

Example suggestions:

For AWS

Serverless Web Application using AWS Lambda
Data Pipeline using Amazon Redshift
Infrastructure as Code using CloudFormation

For React Native

Mobile Task Manager
Weather Application
Fitness Tracking App

These are designed to become GitHub-ready portfolio projects.

Under the Hood

The system follows a pretty straightforward pipeline.

1. Fetch GitHub repositories
2. Detect technologies used
3. Normalize skills
4. Compare with resume skills
5. Identify missing skills
6. Generate AI improvement plans

The key part is giving the AI context.

It sees:

• the developer’s repositories
• the technologies used
• the missing skills

Which helps generate more relevant suggestions.

Why I Built This

Developer hiring today is very different from a few years ago.

Recruiters and hiring managers look for signals like:

• real projects
• curiosity
• technical initiative
• problem solving

Not just a list of keywords.

ProofMap tries to answer a simple question.

Does your GitHub support the skills on your resume?

And if the answer is not yet…

It helps you fix that.

Final Thought

Resumes show what you claim.

GitHub shows what you build.

ProofMap tries to connect the two.

And honestly…

The whole idea started with curiosity.

How do hiring managers actually filter developers today?

That question turned into a project.

And now I’m curious what others think.

Sliding Window: A Simple Yet Powerful Technique

sneha grian — Sun, 13 Jul 2025 08:45:03 +0000

Sliding window is one of those techniques that once you get it, you’ll start spotting it everywhere. It’s a go-to tool for solving problems involving subarrays, substrings, or continuous sequences and can turn an O(n²) brute-force problem into a sleek O(n) solution. Let’s dive in!

What is Sliding Window?

A sliding window helps you iterate through a series of elements in segments. It takes in each element one by one to check a condition, and removes elements when the condition is no longer met.

How Does It Work?

The window moves from left to right.
Each element is taken into the window to check if it satisfies a specific condition.
We use two pointers, usually named l (left) and r (right).

Step-by-Step Explanation:

1. Initialize the two pointers:
Start with both l and r at the beginning of the array or string.

2. Expand the window:
While the condition is not yet satisfied, move the r pointer forward to increase the window size.

3. Check the condition:
As you include new elements, check if the current window meets the required condition (e.g., sum ≤ target, valid substring, etc.).

4. Shrink the window if needed:
If the condition fails, move the l pointer forward to reduce the window size and try to regain a valid window.

Example:

Imagine a sliding window: l is the left blade, and r is the right blade.

If we keep one side of the window constant (say, l), and move the other side (r), the window expands; this is how the sliding window works:

When the condition is not satisfied, we change the position of l to the next element. This marks the starting of the new window, and we check through elements using both pointers to find a new valid window.

Moving l helps reduce the window size.
Moving r helps determine the window's right boundary.

Why Do We Use Sliding Window?

Sliding windows are usually used to return a group of elements when our required output is a maximum value, sum, or any condition based on grouping.

The sliding window method helps us to:

Find the output by performing operations on a group of elements stored in a window.

Segment the list into all possible groups and check for the required condition.

💡 Key Benefits:

Makes the process easier by reducing time complexity.
We don’t need to check the already-checked groups again.
Efficient in problems where we need to slide over input and check conditions dynamically.

LeetCode Example:

Let’s see how sliding window logic can solve one of the most asked interview question.

Longest Repeating Character Replacement: (Leetcode no.3)

Given a string s and an integer k, find the length of the longest substring where you can replace at most k characters to make all characters the same.

Example

Input: s = "AABABB", k = 2
We want the longest substring where we can replace at most 2 characters to make all characters the same.

Step-by-Step Logic

We apply the rule:

window size - max frequency ≤ k

Where:

window size = r - l + 1
max frequency = most repeated character in current window

If true:
We can replace the remaining characters → Expand window
If false:
Too many replacements needed → Shrink window from the left

Walkthrough:

Best window = "AABAB"
Max freq = 3 (A)
Replacements needed = 5 - 3 = 2
✅ 2 ≤ k → valid window
Result = 5

This is a classic sliding window problem:

📌 Expand → Check Condition → Shrink if needed → Track max