• How to prep your GitHub for job seeking
  • Original author: Yopla
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: nettee
  • Proofreader: PingHGao, Chorer

How to prepare your GitHub for your job search

Reasonably or not, tech recruiters tend to infer a lot about you from your GitHub profile. And more and more employers are asking for, or finding, your GitHub account through a simple Google search. Therefore, for job-seeking developers, it makes sense to think of GitHub as an extension of your resume.

With that in mind, I’ve put together a few guidelines based on the “mistakes” in the GitHub accounts of people I’ve interviewed with over the past few weeks.

My main focus is on developers, but many of the points are generic.

I migrated to GitLab because M$sucks. (M$)

Let’s quickly avoid this myth first.

First of all, professional adults don’t say things like this (in public), so please keep this to yourself and don’t write it in a top-shelf readme.md as I once saw an example. Although our company does not use any Microsoft products at present, we do not rule out using a Microsoft product in the future because of technical or financial advantages. We don’t need a developer who can’t evaluate technology with an open mind.

GitLab seems like a good alternative, but since I use GitHub myself and look at one For every 20 GitHub profiles, I’m more familiar with GitHub’s interface. I’m not saying you have to use GitHub, of course, but the tips below can more or less be applied to other platforms. (Though if you’re using Bitbucket, you’ve obviously never posted to us…)

Organize your personal information

First, let’s look at the minimum requirements you need to meet for your profile.

Add your avatar, a brief introduction, and links to your other related sites

Having a full profile gives the impression that you care about your GitHub and are organized. We already have your resume, and we probably have your LinkedIn, but if your GitHub is the worst of the three, it will make the most lasting impression.

Real photographs are better than cartoons, cartoons or symbols.

If you’re looking for a job, it’s important to look neat. Avoid images that you wouldn’t normally send to an employer. This includes nudity, drunkenness, ninjas, hackers, terrorist disguises, or anything that gives the impression that you’re not authentic.

You might want to keep it light and friendly on your GitHub profile, so avoid overly formal photos, but keep it professional. That goal, of course, is “casual Friday” style.

And finally, don’t put up your graduation toga picture. That’s not a good picture. It makes you look inexperienced.

Use @ to link to other warehouses that employers should be aware of. This could be your company, organization, or other warehouse that you are involved in or manage.

Add the URL of your personal website. If you have a website and it looks good, you should put it up. (Hint: If the site looks like shit, maybe you shouldn’t have built it in the first place…)

Links to your other relevant profiles. If you are active on other sites, such as StackOverflow, CodePen, Behance, Dribble, or others, make sure your profile is all connected. But don’t link to orcs, otaku, or role-playing forums that have nothing to do with your professional experience.

Notes on unexpected links

Google has a great ability to generate links, so if you don’t want recruiters to find it, it’s best not to use the same nickname on different sites. We Google it when we do social media checks.

I can’t tell you how many times I’ve searched for a GitHub user name and found a different side of them from the associations I found on Google, from people who are competing with employers on Upwork to people who are illegally breeding dogs and bidding on Instagram.

Choose your top warehouse for the employer

If you’re looking for a job, the top warehouse that appears at the top of your profile shouldn’t be a shortcut to the warehouses you visit most often, but rather a showcase for your most compelling warehouses. Maybe they’re the same warehouse, but usually they’re not.

As a recruiter, I don’t care about your BASH_profile, I want to see the repository you want to highlight for the recruiter. They should be relevant, show the work you’ve done, etc.

⚠️ Top the three warehouses you want the recruiter to see.

Don’t top introductory tutorials

Please note that we look at a lot of resumes. If your warehouse is a tutorial or boot camp, I’ve probably seen it three or 30 times. Projects that are too easy, or 80% from tutorials where you simply fill in blank projects, don’t give me any idea of what you’re capable of, or even make me feel like that’s the best you can do. Having these repositories is not a problem, just don’t highlight them.

If that’s all you have, then it’s probably best not to build any warehouses, and just name them: Tutorials. Don’t make them original and don’t exaggerate them. They are just beginner tutorials and will not impress anyone. As I mentioned earlier, I’ve probably already seen this tutorial.

Put the demo that uses the related technology at the top

… Put them ahead of larger projects with outdated technology.

For example, if you’re in the market for a SPA development position, put a demo of Angular/React/Vue technology ahead of the Laravel + jQuery project you wrote three years ago.

If, like most people, you don’t have a successful open source project, and most of your regular production code is your employer’s asset, you may be sad that you don’t have a compelling project to show for it. But don’t worry, most people don’t have one.

It’s best not to try to show projects that are too grand but unfinished and almost abandoned (who hasn’t had one or… Ten?) Instead, focus on interesting small technical demos in the framework of your choice. If you’re already working in a professional field, there’s probably something you’ve solved that could make an interesting demo. You just need to quickly rewrite it or get your current boss to authorize you to publish it.

If you’re a beginner, I recommend making some demos that show your understanding of computer science, even if it’s just a visualization of bubble sorting or tree traversal written in React or Vue. Compared to your peers who are watching Udemy tutorials to make a Todo app, you are a genius.

Some inspirational projects:

  • www.cs.usfca.edu/~galles/vis…
  • visualgo.net/en

If you have other interests outside of CS, such as music, you can combine them. Like making a little synthesizer or something.

Remove useless forks

I’ve received a lot of profiles with a bunch of forked warehouses, but nothing contributed. First, it makes it hard to see what you’re really doing. Second, it gives the impression that you can’t use Git (and GitHub) and fork as a bookmark.

Some people use fork’s project to “populate” their profile, as if to impress recruiters or friends. But it’s not impressive, it just makes you look like a jerk. Don’t do it.

⚠️ fork the repository only if you are actually contributing. In other cases, use star or follow.

Clean out the warehouse you star

This may irritate a lot of people, but here’s the thing: Your storehouse of stars causes interested visitors to change their perception of your skill maturity, so what you star affects how others see you.

⚠️ You should check the latest pages of the star label and remove anything that might be misleading.

Beginner and advanced

Roughly speaking, senior job seekers should give stars to warehouses with complex projects and avoid giving stars to too many beginner or tutorial warehouses (unless you’re contributing to the warehouse).

Imagine that you check the profile of a senior React developer and discover that her latest two repositories are Iliakan/javascripts -tutorial-en and kay-is/ react-From-Zero, You may wonder if this candidate has the skills she purports to have, or if she’s still at the entry level.

On the other hand, if you are actually applying for an entry-level position or show that you are learning the skill, it makes sense to give both warehouses a star.

White hat and black hat

I like the security side of things. From a white hat perspective, any developer’s focus on security is a plus, but avoid giving a star to a long list of weird hacking tools unless you’re applying for security-related positions. I once saw a guy’s profile with a long list of wifi crackers and phishing tools, followed by a bunch of shared enumerators, and password brute-force crackers. This is not a good way to present yourself.

And so on…

Organize the warehouse you show

Once you have selected several warehouses for your presentation, make sure they are accessible. Here are the minimum requirements they should have:

Any project should have an interesting README

For whatever reason, always, always add a description to your project. This sounds obvious, but I can’t tell you how many times I’ve seen a project without any readMe, or a default readme generated by a framework tool.

Here are the minimum requirements you should have in your READme:

Project description

You need someone who can easily understand what the project is and why you’re a good programmer in 60 seconds.

Make sure you answer at least the following questions:

  • ** What does it do? ** Summarize in one short sentence, listing its features.
  • ** What is it? ** Clearly indicates what the code will produce. Is it web, desktop, mobile, or library?
  • What technology does ** use? ** List the important frameworks and libraries used for this project. This is useful for recruiters who aren’t necessarily familiar with every framework on the planet to know whether it’s Laravel + Vue or React + Expressjs.
  • ** What is the goal of this project? ** Are you just test-driving a technology, or are you preparing to build a technology that is or will be used?
  • ** What is the project stage? ** Clearly indicate which phase you are in. Is the project finished or in progress? If it is in progress, indicate what is done and pending.
  • Is there something known to be wrong with **, or something not being done correctly? ** List the problems if they exist, as I will be much more forgiving if they are highlighted than if I find them myself.

Tell me what to watch

If you insist on showing a large project, there will likely be a lot of boilerplate code and ancillary content that is completely uninteresting, so don’t hesitate to point out the most interesting parts.

If this is a fork project you are contributing to, make sure you are doing the part. If it is difficult to locate, please do not show the project.

How to run

You must clearly explain how to run the project (or, if it is a library, how to use it).

You must be able to run the demo version of the project with one command, such as NPM Run, Graddle Serve, Docker Run… Or whatever commands your framework uses.

In this day and age, it’s almost impossible to run anything without a bunch of manual dependencies and forerunners.

Here’s what you should strive for:

# serve with hot reload at localhost:8080
npm run dev

# build for production with minification
npm run build

# build for production and view the bundle analyzer report
npm run build --report

# regenerate Element component styles in theme/ from element-variables.css
npm run theme

Copy the code

demo

If you have an instantly accessible demo, put a link directly in the description. If you don’t have a live demo, use screen recording. If all else fails, get at least a few screenshots.

Asciinema.org/ seems like a cool console recording tool, but I haven’t used it.

Unit testing

It’s 2018, and if your project doesn’t have unit tests, you shouldn’t put them out there. This is a bad example of your bad habits. There is no reason not to write unit tests.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.