As a software engineer, you need to ask these 20 questions first when joining a new team

Different software development teams have different styles of doing things. Even within an enterprise, there are many differences between teams. As a software engineer, working with new partners and developing new software is usually an exciting thing, and they should also consider many issues. Recently, software engineer Thomas Stringer analyzed from multiple perspectives of technology, collaboration, external, and products.

Technology

1. How to build software locally?

This is the first thing you should learn. After all, for developing and running software, building is the first step!

2. How to test the software locally?

CI pipeline is very useful for correcting test errors. At the same time, it can shorten the internal development cycle, ensure that the test runs smoothly, and check for regressions at the same time. The pipeline should not be the first sign of creation or failure of the test.

3. How to set up the development environment?

The team documentation should have clear requirements for this. In addition, you should also understand the different tools to be used on the development machine in order to make yourself a producer of the team. It is much better to set up the environment to handle 95% of the requirements at one time than to encounter errors and gradle dependencies after starting the development.

4. Where is the source code?

Normally, in a new team you will work in a pre-existing code base. Therefore, you need to know where the code is and how to get the code on your local machine.

5. Where is the CI/CD pipeline and how does it work?

I hope you can join a team that ensures the quality of delivered products. One of the most common tools is CI/CD pipeline. Find out its location, and briefly understand how it works, check some recent runs, and understand the steps that have been carried out.

6. Where is the product backlog?

You are facing the current state of the software, but it is best to understand its future state first. Take a quick look at the backlog to see some of the priorities for the upcoming product launch.

7. How are pre-production and production testing performed?

Does the new team have an integrated environment? Does the team use canary build and deployment for testing? Does the team introduce chaos engineering? You need to understand how the new team ensures that its production software is maintained to certain standards.

8. What is the form of on-call?

Does this software need on-call? If yes, how to rotate? What is the frequency of accidents? Is there a non-working time requirement for on-call? How can I be notified when I perform an on-call? Usually the on-call rotation does not start immediately when you join a new team, so as time goes by, you can get some answers before executing the on-call.

9. Where are the internal documents?

Where will the new team maintain internal documentation? Is it the latest version?

cooperation

10. What is everyone on the team paying attention to?

Software teams usually have multiple engineers, and it is good practice to understand the concerns of different programmers in the team.

11. What is the weekly rhythm of the team?

Are there daily standup meetings? Is a weekly check-in required? You need to understand what a "typical" week for a new team looks like.

12. Who should I ask the "beginner" question?

After joining a new team, you will usually be assigned an "onboarding partner"-a team senior who knows how things work. This is a very valuable thing, especially if you know almost nothing about the new software and the questions you ask are very rudimentary. This is normal, and it is not shameful to ask beginner questions, even if you are a senior engineer.

13. Who will drive the new features?

Does this product have a product manager? Are there architects and engineers on the team working together? You need to understand the upstream source of the feature request. It would be better if you can take the time to understand the short-term and long-term prospects of the product with this person (or these people).

14. How does the team communicate?

Does the new team use Slack or Teams? Or is most asynchronous communication via email? Engineers usually talk about issues or other types of discussions all day long. As a new member of the team, you need to understand these communication channels.

external

15. How to get customer feedback?

Is this open source software on GitHub? Is GitHubissue the way we get feedback? Or is there a sales team acting as an agent from the customer to the product team? Can we collect common customer pain points from different support teams? In other words, you need to understand how the new team gets user feedback, whether through another platform, an individual, or a team. After all, we write software for users.

16. What support agreements do we have for customers?

Do we have to comply with the SLA? What kind of user scenarios do we support?

17. Where is the public/customer documentation?

This is an important question. No matter how good the software is, customer documentation should be accurate and up-to-date. You need to know where to browse these documents, how to keep them up to date, and who is responsible for it (hopefully the answer is "everyone").

Product Focus

18. What are the high-level pain points of the software?

You need to understand whether the software and the team are dealing with some big problems. Did some architectural issues cause other problems? Are there any exploitable security vulnerabilities? Are there common customer problems that continue to appear and need to be resolved?

19. What are the concerns of stakeholders?

Are certain features of the software that key individuals or other teams want to see? Often, these stakeholders have a significant impact on the short-term and long-term roadmap of the software. Understanding their focus helps to imagine the future course of the software.

20. What is the release cycle of the software?

You also need to understand the frequency and timing of software releases. Does the team continuously deploy multiple times a day? Or is it released twice a year? Knowing the software release schedule can give you a good understanding of the pace of software development.