Nothing on your web site or in your HN post refers to anything other than analyzing git activity. Crunching commits -- artifacts of the software development process rather than the process itself -- seems the core of GitHired.

< Its more about the projects you've built- how complex they are, their architecture, frameworks etc.

While that may have some value it doesn't work for programmers who have all of their work unavailable in company-owned private repositories. 100% of my work, for example, and a large percentage for every professional programmer I know. Even hiring managers and recruiters understand that public repos and personal private repos mainly represent hobby projects and side hustles.

> The whole point is that candidates often tailor their resumes to fit keywords from job descriptions...

True enough, but that happens because of recruiting/screening tooling -- an arms race. Sending out applications, tailored or not, into the automated and so-called "AI" screening/ranking systems describes the least effective way to get a job. Recommendations and reputation work much better, for a reason: a good hiring manager will trust their own experience and instincts, and the opinions of people they trust, more than a dashboard of code commit metrics. Sadly good hiring managers seem even harder to come by than good programmers.

> ...we cut through all the bs to show what they've actually done, not what they say they can.

So a programmer fresh out of boot camp who knows one language and framework will score higher than a more experienced programmer with broader experience? A person who used PostgreSQL for a year gets ranked higher than the programmer with two decades of Oracle and SQL Server?

Programmers don't succeed or fail because of mastery (or lack of mastery) of specific languages and frameworks. Projects and teams succeed, or fail, mainly because of team dynamics, conceptual integrity (as Brooks called it), and management consistency and support. Learning a language or a framework amounts to a necessary but hardly sufficient part of software development, and not even a key part of the process. Domain expertise counts for much more: I would rather hire someone with years of experience in (for example) enterprise logistics and let them learn a programming language rather than the other way around. You can't infer that kind of expertise, or how a person works in a team, or if they can reliably implement requirements, from git repo activity.

I don't blame you for the degradation and frustration of the tech recruiting and job hunting process. Most of the blame falls on the class of managers and executives who don't know anything about managing people or projects, and nothing about software development. Falling back on some sciency-looking numbers at least lets them continue blaming their shortcomings on something else.