How the Hiring Agent Selects Top GitHub Projects: 7-Project Evaluation Criteria

The Hiring Agent selects exactly 7 GitHub projects by filtering for repositories where the candidate has made at least 4 commits, then applying an LLM-driven ranking based on commit volume, project popularity, and technical complexity.

The interviewstreet/hiring-agent repository implements a rigorous pipeline to identify a candidate's most impressive work. Understanding the specific criteria for selecting top GitHub projects helps developers optimize their profiles and helps recruiters trust the automated evaluation.

Data Collection and Hard Contribution Thresholds

Fetching Repository Metadata

The process begins in github.py where the fetch_all_github_repos function gathers every public repository for the extracted username. For each repository, the system computes author_commit_count (the number of commits the candidate made) alongside auxiliary metrics including stars, forks, primary language, and topics. The raw data is structured into a JSON list via generate_projects_json (lines 34-57).

The 4-Commit Minimum Rule

Before any ranking occurs, the system enforces a hard contribution threshold: only projects with author_commit_count >= 4 are eligible. This rule is implemented redundantly—first during the filtering step in the Jinja prompt (lines 44-48) and again in the LLM system prompt (lines 55-57) within prompts/templates/github_project_selection.jinja. This double enforcement ensures low-participation projects are never selected.

Selection Criteria Hierarchy

The template defines a strict prioritization order under "Selection Criteria (in order of importance)" (lines 14-22):

1. Highest author commit count (≥ 15 commits indicates substantial involvement)
2. Moderate author commit count (5-14 commits indicates meaningful contribution)
3. Contributions to popular open-source projects (≥ 1,000 stars)
4. Technical complexity, real-world impact, code quality, community engagement, modern tech stack, and originality

This hierarchy ensures that deep personal contributions take precedence over superficial involvement in popular repositories.

LLM-Driven Ranking and Post-Processing

Template-Based Selection

The prepared projects_data JSON is injected into the github_project_selection template, which the LLM processes with a system message explicitly demanding exactly 7 unique projects (lines 78-86 in github.py). The prompt restricts the LLM to the pre-filtered list and reiterates the contribution constraints.

Safeguards and Fallback Logic

After the LLM returns a JSON array, the code in github.py (lines 96-115) performs three critical validations:

• De-duplicates entries to ensure uniqueness
• Verifies exactly 7 unique projects are present
• Falls back to the top 7 entries sorted by author_commit_count if the LLM returns fewer than 7 valid projects

This guarantees the final output always contains seven projects showcasing the candidate's strongest contributions.

Implementation Example

To retrieve the selected projects programmatically:

from hiring_agent.github import fetch_and_display_github_info

# Provide a GitHub profile URL

profile_url = "https://github.com/exampleUser"

# Run the full enrichment pipeline

result = fetch_and_display_github_info(profile_url)

# The "projects" field contains exactly the 7 selected projects

top_projects = result["projects"]

for proj in top_projects:
    print(f"{proj['name']} – {proj['author_commit_count']} commits")

This snippet calls the end-to-end helper which extracts the username, fetches all repositories, generates the JSON payload, and invokes the LLM ranking—returning a structure where the projects key holds the exactly-seven curated repositories.

Summary

• The Hiring Agent requires a minimum of 4 commits by the candidate to consider a repository.
• Selection prioritizes high commit counts (15+) first, then moderate involvement (5-14), then popular projects (1,000+ stars).
• An LLM-driven ranking processes the filtered list through a Jinja template enforcing exactly 7 unique selections.
• Post-processing safeguards deduplicate entries and fall back to commit-count sorting if the LLM output is incomplete.
• Core logic resides in github.py with prompt templates in prompts/templates/github_project_selection.jinja.

Frequently Asked Questions

Why does the Hiring Agent require at least 4 commits?

The 4-commit threshold filters out superficial contributions such as single-file fixes or documentation typos. According to the source code in prompts/templates/github_project_selection.jinja, this minimum ensures the candidate has demonstrated meaningful engagement with the codebase rather than opportunistic participation.

How does the system handle candidates with fewer than 7 eligible repositories?

If the LLM returns fewer than 7 projects, the post-processing logic in github.py (lines 96-115) automatically falls back to selecting the top repositories by author_commit_count from the filtered list. If fewer than 7 repositories meet the 4-commit threshold, only those valid repositories are returned.

Can a repository with fewer than 4 commits be selected if it has high stars?

No. The hard threshold is enforced twice—once in the Jinja prompt filter and again in the LLM system prompt. Even if a project has 1,000+ stars, the candidate must have at least 4 commits for it to be considered, as implemented in github.py and the selection template.

What happens if the LLM selects duplicate projects?

The code explicitly de-duplicates the LLM output before finalizing the results. As defined in the post-processing block of github.py, the system ensures only unique repositories are counted toward the exactly-7 requirement, preventing the same project from being listed twice.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}