As I reflect on my first year as a software engineer, I realize there are many questions I wish I had asked at the start of my career. I have narrowed down this infinite list into a set of ten questions I think anyone currently on or newly joining an engineering team will find useful.
In this context, I am using "application" to describe a self-contained unit of functionality. As a new engineer, my main code contributions were initially to existing codebases. It wasn't until I gained more experience and started building out whole solutions from scratch that I had realized the importance of determining who was responsible for the application. This question gets to the root of responsibility: who is responsible for monitoring applications and who is responsible for handling any incident that may occur? Who is responsible for maintaining the application? Who is responsible for responding to an alert about the system being down at 2 in the morning?
Knowing how to deploy your code is just as important as writing code. Deploying code is the process of moving code from one environment to another. Typically, programmers write and test code in a development environment, and the code eventually makes its way to a production environment where real users actually interact with it! Firstly, knowing how to deploy your code is important so that you can actually make changes that eventually reach real users. Secondly, asking this question is important because it will clarify the actual deployment process which could range from something like running a single command to performing a manual process that is long and arduous.
This question is somewhat related to the previous question in the sense that it lies in the same domain, but the main difference is that it captures the steps you may need to go through before you are able to deploy your code to the production environment. For example, is there a board of people who need to approve code changes before deploying to production? The question encourages the team to consider the steps they take when they want to deploy code to production and whether those steps are clear to someone on-boarding. As a Junior Engineer, asking this question helped me to understand if there was a standard process or if the process varied depending on the application. This question will engage the team to really define the process. This is also inherently important for any developer to get clarity on because all developers hope that their code reaches user. One day, you may be responsible for managing releases for services or applications, which is sometimes not a trivial task.
Continuous Integration (CI) is a practice where developers consistently merge their code into a central repository where automated builds are created and automated tests are typically run. CI is important because it helps mitigate bugs and merge conflicts early on. The idea is, when code from a separate branch is frequently integrated into a master branch, it has fewer chances of breaking what exists in the master branch. This question can be fairly straightforward with a yes or no answer.
This is a great question you could ask prior to joining an engineering team in general! You get two major pieces of information out of this question:
When will you get to see your code in the field. One of the more fulfilling aspects of writing code is knowing that it will actually be used, and seeing it in action!
How quickly does your code need to be turned around. The more infrequent the releases, the more important each release and the more important it is that your code be working by that time.
This is also a great question to ask prior to joining an engineering team because it will give you perspective on how you, as an engineer, will be going about your work and provide clarity on who you may collaborate with. The more closely you work with stakeholders and customers, the stronger your interpersonal skills will become which will help you in doing your job and growing your career.
The question will help clarify how tasks are assigned to engineers. Does it come in the form of tickets? If so, who assigns those tickets? Can this process be negotiated? Does it vary by quarter? The more you know how work is assigned, the better you’ll be able to manage your time and ensure that work is distributed fairly.
This question is great to ask in interviews or on the first day of a new engineering job so that you can have an understanding of how much say you can have on the engineering solutions you build. Some people are content to fulfill the specifications of other people. Some love to take a more involved approach. Figuring out the standards of the business will help you decide if their expectations match your preferences.
This question will really encourage the engineering team to distill their practices into a coherent and easy-to-follow process which is good for the on-boarding engineer and the team in general!
Is there a formal process? Is it open-ended? This will help you understand the standards and process of designing new solutions in your new team.
In summary, these are ten questions I wish I knew to ask before I started my first software engineering job. I also believe each team should be able to answer these questions definitively and could even provide them to new engineers who are on-boarding!
- Who looks after applications?
- What is the team's deployment process like?
- What does the path to production look like for a service or application?
- Does the team practice continuous integration?
- How often does the team release to production?
- How closely do engineers work with business stakeholders or customers?
- How does work come into the team?
- How involved are engineers with deciding what to build?
- How do you spin up a new service?
- How are architectural decisions made?
What are some other questions you would ask your team? 🙂