Project Info
This project did not submit a demo video on Devpost.
Inspiration
If you're a student recruiting for a tech role, you've likely heard of CodeSignal or Leetcode. These programs are a company's way of evaluating a candidate's technical skill. However, these methods of assessments often fail to capture a completely accurate picture of an individual's coding skills. Performance on a sole online assessment does not accurately depict abilities. In addition, job postings often ask applicants to include a GitHub link with their application in order to glean insight into the applicant's past projects. We sought to operationalize GitHub into metrics available to a recruiter, in addition to already existing programming assessments. CodeSignal and Leetcode give numeric, data-driven evaluations of performance, but examining GitHub projects can paint a more holistic picture of applicant skills.
What it does
From a GitHub link, it assesses candidate strengths in technical fields that are specified by the recruiter. GitGauge then outputs levels of strength in the corresponding technical fields selected for examination. A user can additionally prompt GitGauge in other areas of inquiry about the applicant, and from there more evaluations can generate. One use case might be: If a sophomore in college has participated in hackathons and worked on developing apps from front to end, however lacks much formal education in algorithmic coding (often the content of Leetcode or CodeSignal interviews). This applicant is already at a significant disadvantage as opposed to a student who is able to have higher education and be trained in these particular skills. Here, online assessment not fully encapsulate skills. Not only is this a more accurate evaluation method, but is more speedy for recruiters (as opposed to having to search through a GitHub project page and lengthy blocks of code).
How we built it
API from GitHub retrieve data, extract relevant code with TogetherAI, LLM for chatbox, algorithm to compute value.
Challenges we ran into
Putting the scheme into action was tough. It seemed clear and doable when we looked at broadly, but we lost a bit of sleep over it! Technical challenges: One challenge we ran into was speed of analyzing all the code. Analyzing everything in sequence was too time consuming, but doing them all in parallel was too resource-intensive. We settled on a compromise of processing queries and repositories in batches, a few per inference call. Another challenge was fetching the user's data from GitHub. We couldn't just fetch all the user's repos and cloning big repos took too long. To solve this, we had to learn GraphQL to fetch the preliminary data, and we solved the issue of cloning efficiently using git sparse cloning, only cloning files our LLMs recommended.
Accomplishments we're proud of
One thing we're proud of is how fast we were able to learn all the skills to build the project. Before this, we had next to no experience with FastAPI, GraphQL, Together.ai, Docker, and automating filesystem manipulation. Another thing we're proud of is the real time updates while the backend is doing the processing. To create these, we connected to Firebase and subscribed to a doc with changing update statuses, all in the span of an hour.
What we learned
GraphQL, FastAPI, Together.ai, Docker
What's next
Improve the relevant code finding algorithm. Right now, the algorithm is fed lots of code and it picks out the relevant ones. In the future, we should be able to give the algorithm a file and have it search for the relevant code by itself. Improve the speed. This can be done by parallelizing more of the computations, and refining our prompts.
This repository has no readme, or GitHub could not be reached.
Analysis
View
Metric
- 35
- 34
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- CSSIn code
- FastAPIIn code
- FirebaseIn code
- HTMLIn code
- OpenAIIn code
- PythonIn code
- ReactIn code
- TypeScriptIn code
- DockerClaimed
8 of 9 appear in the indexed code. 1 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
82 KB
Source files
43
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
SonavAgarwal/treehacks-24
92 files · 2.9 MB · @ d4df352
Structure
Interface
28 files · 30%Screens, components and styles rendered to the user.
Application logic
9 files · 10%Domain rules, services and shared utilities.
Data & schema
3 files · 3%Schema definitions, migrations and data access.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- Python62%
- TypeScript25%
- CSS7%
- Markdown3%
- HTML2%
- YAML0%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
frontend/package.json
npm · 18- axios
- firebase
- react
- react-animate-height
- react-code-blocks
- react-dom
- react-hook-form
- react-loader-spinner
- +10 more
backend/requirements.txt
pypi · 7- aiohttp
- fastapi
- firebase_admin
- openai
- python-dotenv
- together
- uvicorn
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.