My biggest roadblocks come from my own certainty that I wrote correct code. That leads me to look in the wrong places for the bug. I have repeatedly looked right at bugs and not seen them because I felt sure that code works as expected.
Yes. I don't see the point, though. If I can run full neovim inside VSCode what does VSCode add?
> I guarantee if he spent as much time configuring vscode as he did configuring vim he could establish equivalent environments.
Yes, almost. For example you can make VSCode run terminals in tabs like the editor windows. VSCode supports a lot of customizing. But it still runs on Electron with a rather heavy node process on the other end -- a lot heavier than vim or neovim.
I used VSCode for over six months but ended up going back to vim. Nothing specifically wrong with VSCode, I recommend it to people who don't know how to use vim/neovim, or don't want to use those tools. But for those of us who know how to use vim/neovim VSCode feels slow and bloated with features I don't want. Personally I prefer not to use Microsoft products when I can help it, but now with VSCode (and GitHub) increasingly pushy about AI that I don't want I can do without VSCode.
My first reaction: This tool looks at the wrong metrics, or a small subset of possibly relevant metrics. Nothing about git activity correlates to "who can code" (as opposed to who can produce code), much less all of the skills not apparent in git repository that make a developer valuable -- 10X or "cracked" as you put it.
You call tech hiring "broken." Have you considered that trying to reduce programmer skill and value to a simple formula or metric contributes to that? Perhaps the swipe left or right mentality of "tech recruiting," adapted from the also broken dating domain has something to do with it. Recruiters and hiring managers unqualified to talk to and evaluate candidates hiding behind CYA tools -- broken.
Tech hiring does indeed look broken for people who only have their git history to sell themselves.
No employer or customer I have ever worked for would give access to their private repos for data collection. A candidate who did give such access likely broke their NDA and maybe the law. I have no public git repos, consistent with many of the professional programmers and freelancers I know. I only work in private repos owned by a company that has the resources to enforce their IP. Curious how you can assert in comments that your tool analyzes private repos.
Activity is just a small part of how we assess their skills. Its more about the projects you've built- how complex they are, their architecture, frameworks etc.
Also we only look at your personal private repos, not organizations. A company would always store their codebase in an organization, which we don't access. And even in the case of personal repos, none of the code is stored or used in any way except to analyze complexity and get other metadata like languages, tech stack etc.
The whole point is that candidates often tailor their resumes to fit keywords from job descriptions, and we cut through all the bs to show what they've actually done, not what they say they can.
> Activity is just a small part of how we assess their skills.
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.
Firstly, to give you some more insight about our algorithm, commits are actually bonus points- they're not even a part of actual scoring. I'll make some changes to our landing page to communicate this better, thanks for your feedback!
Secondly, we’re currently focusing on startups looking to hire cracked coders, like college students or recent grads. The situations you mentioned are for senior engineers- people who have worked at companies for a while now. Not something we're too focused on right now, since senior devs would require different metrics and be more experience-based.
Yes, I have. Sometimes it works, sometimes not, like all team organization strategies. Comparing team organization styles proves close to impossible, too many variables and confounding factors.
Projects fail mainly because of interpersonal conflicts and poor/incomplete requirements. Experienced smart people who understand the domain and have authority to make decisions can succeed with any team organization.
The problem Brooks describes around communication has to do with multiplying the number of paths as the team grows. The "surgical team" approach includes a member in charge of documentation at all stages, to give everyone access to the same context.
A small team may "vibe code" something they call a CRM in a week, but unlikely it will work and stand up to requirements changes. Only someone who doesn't understand the business domain would claim they can coax a solution out of an LLM in a few days.
