So, you’ve just been hired as a new software developer. When I started, one of the most common pieces of advice I received was to ask lots of questions. There’s plenty to learn as a new developer, and asking questions is a great way to build your knowledge.
What I heard less often, though, was which questions to ask. The advice was always, “Ask lots of questions,” but rarely, “Here are some useful questions to get you started.”
Now, about four and a half months into my role, I’ve found a few questions that have been especially helpful—and a few I wish I’d asked sooner.
What tools do you use?
The answer depends on where you work, but your company likely provides a core set of tools you’ll use regularly. As you settle into your role, you’ll learn how those tools fit into your team’s day-to-day work.
Your coworkers may also use additional tools they’ve discovered through experience. An editor extension might help them navigate the codebase, or a debugging tool might make it easier to investigate an issue. These additions can be especially useful when they work well with the tools your team already uses.
Ask your coworkers what they find helpful and how they use it. If there’s a task you’re finding slow or repetitive, mention it—they may already have something that makes it easier. You could discover a useful tool you wouldn’t have found on your own.
Who can I ask about ____?
During onboarding, you’ll meet people from across the company. Keeping track of everyone’s name and role can be difficult, especially when you’re also learning your team’s tools, codebase, and processes.
Your teammates and manager are good starting points for questions, but it helps to know who handles other areas of the business. You might have a question about benefits, need help with payroll, or want to understand how another department uses the software you’re building.
Ask your manager or coworkers who to contact about these topics, and keep a simple list of names, roles, and areas of expertise. You don’t need to memorize the entire company directory. Having a few contacts outside your immediate team can help you find answers as new questions come up.
What do you expect of me in the first couple of months?
The answer to this question can vary depending on who you ask, but it gives you a starting point for setting realistic goals.
During your first couple of months, you’ll be learning new tools, working on user stories, and figuring out how to contribute to your team. You’ll also be working within your project’s timeline. Understanding what others expect of you can help you decide where to focus your effort as you get up to speed.
Start with your manager and teammates. They can offer concrete expectations, such as, “We’d like you to take on simpler stories independently” or “We’d like you to contribute to team or client meetings.” These answers give you something specific to work toward, instead of leaving you to guess whether you’re making enough progress.
Then ask yourself the same question. What do you want to learn? What would you like to contribute? Maybe you want to understand a particular part of the codebase or feel more comfortable sharing ideas in meetings. Goals that matter to you can give you more motivation to follow through.
Use both perspectives to set goals that support your team’s needs and your own growth. You’ll have a clearer sense of what to work on and a way to recognize your progress as you settle into the role.
And finally, why?
Asking “why?” can feel awkward at first, especially when a more experienced coworker says, “This is how we do it,” or “This is a better approach.” But understanding the reasoning behind that advice can teach you a lot about your team’s software and development practices.
The goal isn’t to prove anyone wrong. It’s to understand the decision and learn from your coworker’s experience. Asking something like, “What makes this approach work better here?” or “Is there a reason we do it this way?” can help you start that conversation.
I’ve run into this myself. On several occasions, I followed an existing pattern simply because that was how things were already done in the project. I accepted the approach and used it without understanding the reasoning behind it. That left gaps in my understanding of why we use some conventions or tools.
Asking “why?” can help fill in those gaps. You might learn that an approach prevents a problem the team has encountered before or accounts for a limitation you haven’t discovered yet. That context helps you understand how the project fits together and make informed decisions when you encounter similar situations in your own work.
Keep Asking, Keep Learning
These questions aren’t a complete checklist, but they can help you settle into your new job, especially if you’re unsure what to ask. As you get to know your team, the software, and your responsibilities, you’ll find new questions worth exploring.
Asking questions is a good thing, and it’s part of growing as a developer. We all have things to learn, and asking about what we don’t understand is one of the ways we get better.