How I’m working with React Intern. Real example

In my previous stories, I explained my experiences and observations related to internships. Specifically, how I find interns and incorporate them into our development process.

When I completed my first two articles in this series — I realized one problem. That articles only have “common rules”. I’m explaining only “right things”. I think everyone knows that type of advice: be good, don’t be bad, be happy, etc.

I love practical tutorials, so in this article I will give some real life examples of what it’s like to work with and train Interns in a ReactJS environment. I will show how I’m working with one of our interns right now. When the idea about this article was born— I started to make notes. I wrote down each move that I was making so that I could talk about the step by step process in more detail.

I hope someone will be able to learn something new from it. Maybe use it at work as well. Feel free to ask questions in the comments section. This is the third article in this series.

To understand the context of this story, you may want to read these articles first:

• First article: https://hackernoon.com/how-i-built-my-startup-team-with-interns-9a395d265cc4
• Second article: https://hackernoon.com/how-i-built-my-startup-team-with-interns-part-2-fd88b7e2560f

These articles will help you to understand my approach more clearly.

This story is about one of our React interns. Let’s call him Arjuna(he is a hero from Mahabharata). Arjuna applied to our job opening a few months ago.

Arjuna has basic React knowledge: JSX, components lifecycle, render props, etc., My goal as a manager is to slowly introduce him to our codebase.

Arjuna statue, from Wikipedia: https://en.wikipedia.org/wiki/Arjuna

1. First tasks

He started to work with us by creating tests for our components. Why?

1. Tests are good. Right now our components have bad coverage so it will be beneficial for us.
2. Creating tests it is a good way to set up the thinking processes of a Developer, by introducing Test Driven Development or Behaviour-Driven Development concepts. (At his current skill level, there is no big difference)

Codebase benefits: we increasing the quality of components code while the intern works on a separated module. This module contains 7–10 components only, so when a new team member joins us and sees the small repository — he won’t be too scared to start coding.

At first, an intern should complete 5–10 easy tasks. It is like a test drive. We set up a collaboration at GitHub and make him comfortable to work together and set up a nice way to code. It might look something like this:

Our current GitHub workflow with Arjuna

While the developer is new and not battle tested before → you need to help him, but not interfere or push a lot. Be gentle. By my experience, asking for code changes at pull requests can slow down interns.

Maybe it’s a good idea to disable your Travis CI/Circle CI and ESlint checkers while intern making his first steps. They are important tools for sure, but warnings can distract and be scary for an intern. And if you work on the same repository, you will need to explain the basics about merging, merge conflicts, rebasing, etc. Better to not code on the same repositories from a few weeks ago. Yep, it’s also important to know how to use CI and ESLint. But It is better not to overcomplicate things in the first few weeks.

Just wait. In a few months, an intern will learn this default workflow. Don’t overcomplicate coding, again, don’t raise the bar of a single contribution. It will relate to code quality at the beginning, but this is a marathon, not a sprint, so…

Side note related to repository access. I don’t give access to the main repository from the beginning.

Interns must fork a project. As I see it, the fork logic and sync with a master branch is hard for them. But it is important to have a separated repository. An intern will have a place to “play” and learn details about pull requests on GitHub. I think this is a good approach. Instead of having a crazy list of commits on master branch(or featured branch)

For this case, I create a few small repositories, where I keep my links for beginners. This is my collection, related to Git+GitHub only: https://github.com/ChickenKyiv/awesome-git-article

Task + links to an article, related to git, will help Arjuna to learn basics quickly and better.

He will learn:

• basic forking process
• basic git commands
• git-flow

It is also important to keep your fork up to date, which is also a good practical exercise with Git CLI.

Testing React components it’s a huge topic. I have a repository with information about tests too(but it’s messy): https://github.com/ChickenKyiv/awesome-jest-articles

2. Repeat and remember

Ok, Arjuna completed ~7–10 first tasks on this repository. Next step will be to complete the same tasks at our other repositories. So, nothing complex again. Just repetition. But this task will help him to set up a great “code vision”.

So after making a few commits(contributions) into different repositories, it decreases Arjuna’s fear level.He will need to complete about 20–35 simple tasks in total(at 3 different repositories).

After this point, Arjuna will:

• have git knowledge
• understand our coding workflow
• work pull requests, merges, code conflicts
• feel comfortable with asking questions
• how to work with Github Issues and will know that he can pick a task from “Issues” tab
• will understand that his code is important for us.

3. Code rewrite For the next step, I plan to assign a task, related to code rewrites. Arjuna will need to take a look at his previous code and improve it.

If we are talking about tests they can have more layers, clarification, display more detailed information. By this task, Arjuna will be forced to go and review his code(3 repositories).

I think it is a good practical task. Redoing your own code is good for mastering code skill too.

4. Giving Arjuna more access, power, independenceAfter completion of the first 40–50 tasks, I plan to enable builds with Babel back and publish modules on npm. At this point, Arjuna will be able to make his own builds (I will add him as npm org maintainer) and ship new releases without my help.

5. Connect our components with create-react-appArjuna will install our separated and published components into the clean CRA(create-react-app) project and actually see how things works. This is a point where all the fun will begin.

There will be tons of things, small changes, that will need to be fixed/changed, so the developer will need to step back, adjust code at components repository → publish changes → and upgrade the main CRA project.

Another good point why to start with tests, related to learning how current codebase works and also importing code in small pieces.

Not just “Hey — let’s build some new components”, but by reviewing the code of other people, Arjuna will learn how to “read code”. it is crucial for working as a team member, not a solo coder.

Thanks for reading. Have a nice day. Clap if you want.

Big thank you for HackerNoon Editors for their help.

If you want your story being published at HackerNoon — submit form: http://contribute.hackernoon.com