Consider all the different types of software you use in everyday life: Facebook to see what your friends are up to, Google Chrome to browse the internet, Skype to contact friends and family, and Spotify to listen to music. Despite serving wildly different purposes, what do all these pieces of software have in common? The answer is that they are all written by a technical team working together to build the best program possible.

If you want to help build best-in-class software for everyone to use, one of the most critical things to master is how to become a productive member of a technical team. When starting a career as a web developer, you will be thrown into a team of other developers, both junior and senior, and expected to be able to add value from day one.

Developing software as part of a team has a huge upside for junior developers. Other members of your team have an interest in providing you mentorship and helping you become an even better developer. Through constant feedback on your code, you can expect to consistently improve and learn something new every single day. Working on a team, however, requires a different skill set than you would need working by yourself.

Becoming a productive team member is something you can only learn by actually placing yourself inside a real group project, going through the trial-and-error process, while being in a supportive environment. This means you’ll need to code together on a project with other people, who are as invested as you are in seeing the project be a success.

Working in the right group environment will help you become a happy and productive team member that other developers want to work with. In addition to this, it will also teach you 7 key skills that are critical to getting hired as a web developer.

Skill 1: Learn to Initiate GitHub Pull Requests & Code Reviews

When working by yourself, you alone are responsible for the quality of the code. That means if you take sloppy short-cuts or write poor quality code you will be the only person that has to pay the price. When working as part of a technical team, it is the whole team’s responsibility to make sure that only high-quality, well tested, and bug-free code is accepted into the project.

The best teams require code reviews before code changes are accepted into a project, to ensure the quality of the code is up to their high standards. Code reviews happen when another team member, who was not involved in writing the code, reviews the proposed code additions and changes line-by-line, and looks for things that could potentially cause unexpected problems.

Because code reviews happen frequently, GitHub comes with advanced features empowering teams to easily perform code reviews.

Requesting a code review prior to new code being accepted into the main branch is known as issuing a pull request, and the best technical teams don’t allow any code to enter their project without going through this pull request process.

In this process, you present your proposed code changes and allow other developers to look through those changes.

Below is a GitHub pull request example from one of our Firehose Project students. The lines of code that are removed are displayed in red, and the lines of code that are added are displayed in green.

You can see how a mentor used the inline code commenting feature on particular lines of code, to help a student organize his code better

Whether you’re looking to contribute to open source projects or work on a technical team you’ll be expected to have the following skills:

• Create new pull requests and propose your code changes to the team.
• Make notes on other people’s code about things you think they might’ve overlooked in their code.
• Respond to people’s concerns about your code, either through code changes or comments on the GitHub platform.

As a developer, your job isn’t just to implement features, but to write code that implements features that lives up to your team’s high standards. This means that responding to feedback on your code is critical for you to be an effective developer. By responding to feedback on GitHub you will continue to grow, and become a stronger developer.

Skill 2: Learn to Break Large Problems into Smaller Ones

Each team member works as a multiplier on the amount of code the team can produce. In order to reap the rewards of having many people contributing to the same project, large tasks need to be broken into small tasks that can be worked on in parallel.

For example, if you are working on building a BlackJack game by yourself it would be your task to do the following:

• Build a BlackJack Game

Yet if you have a team of people building the same BlackJack game, the same project could be broken into smaller chunks that each member could execute on in parallel.

• Build a landing page for the web application
• Store emails that for users who have opted-in into a MailChimp account
• Build a representation of a deck of cards in the code
• Support users logging-in and logging-out
• Make the page look awesome on Mobile

By breaking large tasks into small pieces the team will be able to make many small steps towards the eventual goal of the completed application.

Most projects, even in the professional world, never will be fully completed since there are always additional features you can add to any existing application. It’s not uncommon for a product backlog, a list of features that are desired but aren’t built yet, to take an estimate of a year or more to complete!

Because technical teams often have so much work, software is built by having constant steps in the right direction, and breaking large features into smaller ones plays a huge role in getting to the finish line, one step at a time.

Skill 3: Implement Test-Driven Development for Future Success

Having a robust test suite is more important when working on a team rather than if you’re a cowboy coder or coding all by yourself. This is because projects can amass a lot of code, think 10,000 lines or more, and can quickly get very complicated. With that much code, someone who hasn’t worked directly with a particular section of the application before cannot be expected to know every nuance of how the application works.

By writing tests when you build the feature you prevent other team members (or your future self) from inadvertently breaking the application in ways you cannot predict as you’re building the software.

Having the entire test suite take more than 10–20 minutes to run a complex project is pretty normal. Professional web developers often use “Continuous Integration” tools to help them run their test suits. Those Continuous Integration tools automatically run your tests for each pull request and help prevent members from accepting broken tests into the code.

Skill 4: Navigate Merge Conflicts and Improve Communication

Merge conflicts happen when two team members attempt to make contradictory, or conflicting, changes. Good communication as a team can help prevent avoidable conflicts, but sometimes they just happen as a result of building software as part of a technical team.

Here’s a scenario that could potentially cause a merge conflict:

Say Marco and I are working on the same project, the Firehose Project landing page. Right now the headline of the page says: “Your Software Career Starts Here”.

If I change the headline to be, “Your Software Career Starts Today” and Marco changes the headline to be, “Start Your Software Career Here” at the same time, we end up with a merge conflict. In short, one of us won’t be allowed to send our code changes up to GitHub until we deal with the fact that we tried to change a single line of code in two different and contradicting ways at the same time.

In this example, if Marco and I communicated better about changing the headline, we could have avoided this merge conflict. In many cases, particularly when dealing with complicated projects, conflicts will come up. Learning how to stay calm, communicate with other team members to fully understand their thought process about the change they made, and resolve the conflict to achieve both your goals and the goal your teammate had when they made the change, is a skill you can only learn by coding together as a team.

Skill 5: Utilize Stand-up / Scrum Meetings to Share Knowledge

Since communication between technical team members is critical, most teams will have frequent meetings, known colloquially as “stand-ups”.

During the meeting members of the technical team are asked to quickly update other members of the team with the following details:

• What did you work on since that previous meeting?
• What are you going to work on between now and the next meeting?

By having each member talk for 60–120 seconds about what they’re working on, other team members, who often times know more about potential problem areas of a specific feature can prevent a team member from going down an avoidable rabbit-hole.

Stand-up Meetings are designed to be between 10 and 15 minutes, and everyone on the team is required to stand for the duration of the meeting. Standing during the process of the meeting tends to speed up the meeting, and focuses people on the most important topics.

Skill 6: Use Pair Programming to Provide Constructive Feedback

Sometimes when you work on projects you’ll find yourself working on intensely complicated problems. Other times you’ll find yourself working on more straightforward tasks. When you’re responsible for tasks that you’re struggling to complete, it’s incredibly valuable having another team member to work with.

This collaboration process between you and another teammate, to tackle difficult coding problems, is known as pair programming. During pair programming sessions one member of the team will sit behind the keyboard, write code and “drive” the interaction. The other person will sit behind the person and watch the coding process and provide real-time feedback.

Gaining skills in leading the code that is being written and giving real-time feedback in a productive way is an important skill to master. When starting out it can be intimidating to code in front of other people, knowing they’ll give you feedback as you code. Pointing out potential problems in other people’s code, in a collaborative manner is also a skill that takes time to learn.

Skill 7: Learn to Work in a Constantly Evolving Environment

One of the biggest challenges to get used to when working as part of a technical team is getting comfortable working in an environment where many people are writing complicated code, and not becoming overwhelmed with the process.

When building features as a team, and many lines of code change rapidly every single day, it’s important to stay laser-focused on the task you’ve been assigned. Although code is consistently evolving around you, you need to trust your team and the process.

Since code is continually changing, frequently updating the code you’re working with and making sure you’re working with the latest code is important. This process is known as “pulling down” the code that was contributed by other team members, and getting in the habit of pulling multiple times per day will save you from working on code that isn’t up to date.

So, How Will These Technical Team Skills Help You Get Hired?

Learning how to collaborate, communicate and use the right tools is incredibly important when building projects as a part of a technical team. Having said that, all group project experiences aren’t created equally.

In the real world, working on a team doesn’t always go smoothly and everyone knows that. What is important is how challenges that come up while working as a team are resolved.

Questions about working on a team frequently come up during the technical interview process. Hiring managers are particularly interested in the types of challenges you have faced when working as a team and how you overcome those challenges. Your answers and experiences give them a real-world and valuable view into your problem-solving skills as a developer and a technical team member.

When you’re asked to describe a challenge you’ve overcome working on a team everyone learns something. On the other hand, if you indicate that you’ve never had any problems coding collaboratively, the team who is evaluating you as a candidate will likely believe that you are either very inexperienced or not telling the truth. Either way, you are unlikely to get that job.

Instead, speaking from specific experiences about the importance of clearly communicating with other team members and how to overcome communication problems when they arise will impress the team that is comparing you against other candidates for the position.

If you’re looking to switch careers, it is critical that you have experience working on complex applications as a team. This is because in the real world, even when you’re working with teams of “only” 4–8 other developers, projects get complicated quite quickly.

Hiring managers won’t be impressed if you’ve built simple applications that simply display information from a database on the screen as a team. On the flip side, building a project like a chess game, which is incredibly complicated, and deals with intense logic will be a lot more impressive.

Although on the surface a chess game may not sound very complicated, it has many complicated features. For example:

• How would you validate that a queen can move to a particular location on the board, given where the other pieces are on the board?
• How would you enable the castling move?
• How would you make en passant work?
• How would you update the board for user #2, when user #1 moves the piece without requiring a page refresh.
• How would you check for checkmate/check?

One of our students who worked on a group project got a job at a company in NYC and the 2-hour interview process mostly entailed reviewing her code and pull requests from building the chess app during her group project.

You should make sure to keep the goal of a group project in mind. It’s all about building a complex application; not necessarily to have thousands of users use it. Rather than trying to come up with ideas that would have the highest potential to be used, you should focus your efforts on a learning as much as you can during the group project.