We recently reviewed a set of “git repository portfolios” of full-stack developer boot camp students with thoughts of creating a process for selecting who to interview for paid internships or first jobs.
In doing this, we noticed several things that either moved students to the top of the list or, perhaps unfairly, got students dropped off the bottom.
We had allocated 25 minutes per portfolio for human review beyond what we could learn from automated and AI-based tools. We separately did a post-mortem review to learn about systematic errors in our process.
Since it was a historic cohort, we were able to compare our human reviews with job placement and salaries. No one who rated poorly had gotten a job. Everyone who rated well had gotten a job. About half of the people who were categorized as, “more time would needed to evaluate this properly” had gotten jobs.
This is what we learned about how you can avoid being judged unfairly:
First and foremost, pin the repositories that represent your best work. If you don’t pin them, we will look at the ones that GitHub designates as “popular.” These are unlikely to be your best work. You should give thought to your GitHub home page. If the metrics that GitHub compiles are favorable, display them. If you have deployed code somewhere, include links here. We always looked at such links. We looked at the pinned or popular repositories in order, so put your best ones first since we will run out of time before we can look at all of them.
Second, we have about 4 minutes to look at each repository. Make sure you have an about and a useful readme. Not an empty file. Not a template that you haven’t filled out. Be sure that the readme starts with an explanation of what the system does and has all the specific information about your system before the boilerplate. In several cases, we didn’t scroll past the boilerplate during our review to find the “good stuff.” Make sure that all the links from your readme work. If you have testing, document how to run the tests.
Third, make sure all your deployed examples (still) work. In about a third of the cases, they didn’t. In several cases, they did work, but the page load was so slow that we had given up and thought that they didn’t work. In each of those cases, the index.html file loaded quickly, and some type of “loading” message could have been given. In only one case did a slow-loading system have a loading status indicator; we didn’t give up on that one. In several cases, there were tiny targets that did interesting things that we didn’t find during the review, and hence, we thought the system did much less than it did. If there is something useful to on a click, do the useful thing rather than a pretty, but not useful animation.
Fourth, remove “bad stuff” from your repository. We found passwords, API keys, empty files, editor temp files, directories of standard libraries, etc. If our time is distracted by this, there isn’t time to find the “good stuff.”
Fifth, make “nonpublic” any repository that we shouldn’t waste time on or that would present you in a bad light. These include empty repositories and near-empty repositories, repositories that are from a time long before you became as good as you are now, repositories filled with non-code.
Sixth, show that you know how to use git branches effectively. Avoid “dumb” commit messages. The absence of commit messages is better than dumb commit messages. If you have a repository that shows collaboration with others, consider putting it first, especially if you use git appropriately to support the collaboration.
Seventh, consider putting it first if you have anything that does something useful rather than being a standard class project or a simplified version of common commercial systems. Ideally, it is something that someone (even if it is just yourself) actually uses. Clearly explain this in the readme.
Attention to these seven things won’t make unimpressive things look impressive, but they will prevent impressive things from being passed over.
You may have noticed that this list said nothing about the code quality or whether the install instructions actually worked. It is not that these things are not important, but rather, marking you downward for doing badly on these things does not strike me as unfair.
Our biggest lesson learned was that we should have spent more time looking at the students’ best work. In the future, in addition to asking for their GitHub homepage, we will explicitly ask them to tell us which repository to begin with.
