(Click the public account above, you can follow it quickly)
Bole online/Millet cloud bean porridge
If you have a good article to contribute, please click → here for details
The company you’re interviewing with wants a GitHub link. The headhunter wants a GitHub link. “Have you worked on open source projects?” “Is one of the common questions in IT technology interview.
Since they want GitHub, you should give it to them. This article explains how to present your GitHub project in an interview.
The following tips serve two purposes: Candidates can learn how to write software profiles (it doesn’t have to be on GitHub); Recruiters (programmers) can learn what key points they can use to evaluate the quality of a programmer and software.
Link to a specific item
Include your GitHub link on your resume and with every application.
The link should link directly to an item. Don’t give you the address of the GitHub main page. It’s uninformative and hard to navigate.
You must show only one project. One is enough, no more.
This item will be your “landing page,” the first page recruiters see. They rarely look at other pages (and don’t have to) so the page itself should show everything. If they go to another page, it’s a good sign that they’re interested and want to know more about the project.
We need to write a project page that shows off your skills and makes a good first impression.
The project structure
A five-second look at the architecture of the software will tell you the strengths and weaknesses of the project.
You can always tell when a programmer has no experience and often their project has no structure. The project files are either in one place or both in the root directory.
A good project structure must keep source code, tests, library files, and executables in separate folders.
Naming details such as’ doc ‘or’ docs’ don’t matter. Here’s the GitHub project folder structure:
There is a project profile file
The project profile file can provide:
-
Project objectives
-
Screenshots or video
-
Directions for use
-
Software Download Page
Put screenshots of the software interface in the introduction file
A picture speaks louder than a thousand words.
People don’t install software because they want to see the interface. Provide a screenshot of the software interface.
Play the video in the introduction
A picture is worth a thousand words, so a video is worth a thousand pictures.
Note: GitHub does not allow you to insert videos, you can use a GIF instead.
Web page link or installation file link
If the project is a web application, please provide the web address. Of course, everyone should have access to that address.
If the project is a stand-alone program, please provide the installation file download address. If the installation file doesn’t look professional, users won’t install it. A lot of times, it’s about how you publish.
Integrate GitHub tools
GitHub offers a full suite of free tools for coding, packaging, testing, and other functionality. These tools are essential in professional software development.
It used to be very difficult to implement these features, but now it’s very simple through GitHub. There’s no reason you shouldn’t use them.
This is an example of backgammon implemented by C++. Buttons from left to right represent:
-
Wiring on Linux (Travis CI)
-
Connect to AppVeyor on Windows
-
Unit Tests and Test Coverage analysis
What do you do with the source code?
“Nobody cares about your source code — I was surprised to learn that. I spent a lot of time cleaning up the code, but no one cared. It’s not the code that matters, it’s the product.”
Reading a description of a software feature is 10 times faster than guessing. You can watch a video explaining the basics 100 times faster than you can figure out how to use the software yourself. Reading a design diagram is 1000 times faster than reverse engineering. You can figure it all out by reading the source code, but it takes a lot more work. Reading the source code (decoding the source code) is very time consuming. You should only use it when you’re desperate.
Lesson # 1: No one cares about your code, and no one will read it.
Lesson # 2: Don’t expect people to read your code, and don’t force them to.
What if I don’t have a decent big project?
It’s good. Simple projects are easier to present, easier to explain, and easier for the interviewer to understand. For example, everyone knows how to play chess four.
Even if it looks simple at first glance, each project involves a lot of work: writing a good user interface, adjusting colors, allowing two people to play together, plus suggestions for next moves, plus AI players, and so on.
The rules of the game are simple but it takes a lot of work to make it good software. These are all areas you can explore in depth with the interviewer in a face-to-face interview.
Did you know that in chess of fours the player who moves first always wins? Did you know that if the first player makes no middle move in the first move, the second player can always make a draw?
Will the interviewer really go to GitHub?
In fact, they don’t.
We tested it. This graph is the statistics after we sent out a bunch of resumes. These three clicks are my own. At the time of writing this article I clicked on GitHub without logging in. That’s on me
From my last job search experience, after a dozen phone interviews (one tech per phone) and several in-person interviews (4-7 tech per phone), only one person looked at my Giuhub page.
Verdict: No one cares about GitHub, and no one looks at GitHub. Everyone asks because everyone else is doing it.
Bonus: Since no one is actually going to see it, you can also refuse to attend this GitHub masquerade. You can respond to all GitHub requests with the Hello World Ultimate library. This library contains “Hello World” implemented in one hundred languages.
Cheat sheet
-
Projects have structure
-
Have a project profile file
-
Write a paragraph describing the features of the software
-
Put the software interface screenshots and instructions video
-
Provide the download address of the installation file or the web address of the network application
-
Integrate development tools (CI, unit testing, packaging tools, etc.)
There are other good examples of software engineering, not just at GitHub.
Have you learned anything after reading this article? Please share it with more people
Follow “Linux aficionados” to improve Linux skills
