Why you should publish your projects

Before offering you a job, an employer will assess your level of proficiency in each target skill. Usually, they’ll give you a test task involving work that analysts do on a regular basis. However, this won’t give a complete picture of all of your skills, so employers often also look at your portfolio.

The projects you complete for TripleTen can help demonstrate to potential employers that you have the skills they’re looking for.

Putting projects on your resume isn’t obligatory, but it can win you some extra points.

Rules for uploading projects

1. Store your projects in a repository.

We recommend saving and keeping your TripleTen projects in a single cloud repository — a place for storing and maintaining data that is usually saved as a file and can be shared online. The most popular repositories are GitHub, GitLab, and Bitbucket. Cloud repositories allow you to adjust the repository’s visibility, which means you can restrict or grant access to your repository.

Keep in mind that you can (and should!) create different repositories for any other projects you might have, for example, a pet project you worked on outside of the TripleTen program.

2. Do not publish any TripleTen course material to your repository. This includes theory, quizzes, and datasets.

TripleTen material is created by a great team of authors, editors, and experts from leading Russian companies, and we can’t ask them to work for free.

You can, however, upload your completed project notebook. As you complete more projects, this repository will serve as your professional portfolio.

3. Make sure your project contains only what you’ve done.

The main purpose of a repository is to demonstrate what you’re capable of. Try not to publish extensive descriptions of your projects or datasets, short descriptions are enough for a potential employer to understand what your projects are about.

You should also mention the objective of your research and where you got the data from, and make sure to delete all review comments. Indicate the results of the execution of code in cells (calls of info(), head(), and other methods, graph-building, etc.). This will demonstrate what you’ve learned at TripleTen.

4. Publish projects and their descriptions in separate folders.

Folder names should reflect the purposes or names of projects so that it’s easy to distinguish between them. Give your Jupyter notebooks meaningful names.

If you name your projects something like super-duper-cool-project.ipynb, your potential employer won’t understand what they’re about.

Remember that to download your Jupyter notebooks from the platform, just open the File menu and navigate to the project page, click Download as, and select Notebook.

Creating and configuring projects on GitHub

First, you’ll need to register on github.com. To create a repository, login, click + in the top-right corner, and select New repository from the menu.

Name your repository using only lowercase letters, numbers, and hyphens. If you want, you can describe your repository in the Description field. Then, choose a visibility setting: private or public. By making a repository private, you restrict access to it. You can also select Initialize this repository with a README, and a README.md file will automatically be generated.

To make your repository accessible to a recruitment manager or HR team, you need to grant them access. Navigate to the main page of the repository and click Settings → Collaborators. Enter the username or the email of the person you’re granting access to in the Search by username, full name or email address field, then click Add collaborator.

After creating a repository on GitHub, you’ll continue working with it locally using Git GUI clients such as GitHub Desktop, SourceTree, or GitKraken. However, true data analysts and scientists work solely with the command-line interface (CLI).

To get more familiar with Git, check out this interactive guide. Should you have issues with the CLI, download GitHub Desktop. There are all kinds of tutorials and guides on using GitHub Desktop. You can check out this guide and take a look at tutorials on YouTube.

How to publish a project

How to organize a repository

• Create a separate folder for each project.
• Each folder should contain two files: a README.md file and a project file with the extension .ipynb.
• The README.md file should briefly describe your project: the goals and objective, the dataset, and the libraries used.
• The .ipynb file should contain a notebook with the finished project. All the cells in the notebook should be filled in. If there’s any cell output, it should be saved.
• There should be no review comments in your project file.
• There must be a README.md file containing the repository structure in the root of the repository. The structure should include projects, brief descriptions of them, and an indication of what each folder contains.

Your repository should look something like this:

And your project folder should look like this:

Here’s an example of how you can organize your repository: https://github.com/Yandex-TripleTen/TripleTen_en_data_example_repo

Markdown

As you might have noticed, description files have the extension .md. These are files that are written in a lightweight markup language called Markdown. Its syntax looks like this:

COPYmarkdown
1# Heading level 1
2
3## Heading level 2
4
5### Heading level 3
6
7#### Heading level 4
8
9**This text will be bold**
10_This text will be italic_
11**Combine them if you like**
12
13- The first item of a simple list
14- The second item of a simple list
15  - The subitem of a simple list
16
17> This is a blockquote
18
191. An ordered list starts like this
202. And continues
21   1. Subitem
22   2. And another
23
24| Markdown | tables | look like | this    |
25| -------- | ------ | --------- | ------- |
26| easy     | peasy  | lemon     | squeazy |
27
28````python
29print("Here's a snippet of code in Python")
30(just make sure to close the box with your ticks on a new line)```

1
2Here's how all of that looks once rendered:
3
4# Heading level 1
5
6## Heading level 2
7
8### Heading level 3
9
10#### Heading level 4
11
12**This text will be bold**
13_This text will be italic_
14**Combine them if you like**
15
16- The first item of a simple list
17- The second item of a simple list
18  - The subitem of a simple list
19
20> This is a blockquote
21
221. An ordered list starts like this
232. And continues
24   1. Subitem
25   2. And another
26
27| Markdown | tables | look like | this    |
28| -------- | ------ | --------- | ------- |
29| easy     | peasy  | lemon     | squeazy |
30
31```python
32print("Here's a snippet of code in Python")
33(just make sure to close the box with your ticks on a new line)
34```
35
36You can find more info on markdown [here](https://daringfireball.net/projects/markdown/).
37
38If you have issues, practice working with Markdown [here](https://commonmark.org/help/tutorial/10-nestedLists.html).
39
40Remember to use Markdown to write project description files.
41
42## A checklist for making sure your repository is ready to be put on your resume
43
44- All your relevant projects have been uploaded
45- All comments made by reviewers and all other extra information has been removed
46- You’ve created a repository on GitHub/GitLab/Bitbucket
47- You’ve made a local copy of your repository
48- There are individual folders for each project in the local repository
49- There is a project file and a README.md file in each project folder
50- Each README.md file contains a description of the libraries used and a description of your research goals and objectives
51- There’s a `README.md` file containing the repository structure in the root of the repository
52- The `README.md` file contains the path for every project and a short description of it
53- The local repository is uploaded to GitHub/GitLab/Bitbucket
54
55# FAQ
56
57- Is it a good idea to publish a reworked project on Github?
58
59  If you feel your project could have been better and you’re afraid it might create the wrong impression about your level of proficiency, you should definitely replace it with a new one. If you realized you would do some things differently, you can publish a new project and mention in its `README.md` what’s changed since the last version.
60
61- Can I upload a completed test task?
62
63  Yes, you can, but:
64
65  - Your project must contain only work that you yourself have done.
66  - Don’t specify the company that gave you the task.
67  - Don’t copy the full task description to your `README.md`.
68
69- Can I publish work I did at data science competitions?
70
71  As long as it’s not forbidden by the rules of the competition, you’re free to do so. We definitely do not recommend publishing solutions to problems from ongoing competitions. Make sure to leave a link to the relevant competition in the description.
72
73
74export const _frontmatter = {"title":"Uploading a Project to a Repository","metaTitle":"Uploading a Project to a Repository"}