Your new developer feels like a fraud. It's your onboarding process.

New engineers face a tough learning curve, navigating a new role and a complex codebase. It’s no wonder they feel like imposters. We need to reimagine onboarding to better support them.

Dennis PilarinosApr 24, 2025 Engineering Insights

You’ve just joined a new engineering team, and are eager to start contributing to the codebase.

As you dive in, it feels like some of the important details you need to get your work done are obvious to everyone else but remain slightly out of your grasp. You may start second-guessing yourself. Are you able to solve these types of problems? Is it okay to ask for help? What will other people think?

The more self-doubt creeps in, you start to question your ability to handle the responsibilities of your new role. You worry that any misstep will lead your new team to believe that you’re not as competent as they think, making it even harder to contribute.

If this sounds familiar, it’s because it’s a common problem. More than 48% of developers surveyed by Stack Overflow say that onboarding at their company is a challenge, and that it takes far too long to complete.

But the problem isn’t skills or competence; it’s a sign that there’s something missing from our onboarding processes.

It’s easy to feel like a faker #

When you take a moment to reflect on what it’s like to be a newly hired engineer, it’s easy to understand where imposter syndrome comes from.

From the moment you step into a new organization, complexity exists on several fronts. You’re not only grappling with the parts of a new organization — like who’s who and what they work on — but also with the technical complexity of understanding why the entire system operates the way it does. To complicate matters, the codebase is a compilation of thousands of past discussions and decisions, all of which you weren’t part of and don’t yet know where to find.

Organizational culture can also amplify your feelings of imposter syndrome. Engineering teams are frequently assessed on their velocity, which can leave little room for learning and growth. The pressure to deliver results quickly may make it seem like taking the time to fully understand the codebase is a luxury you cannot afford, even when your ultimate success depends on it.

Imposter syndrome is everyone’s problem #

We’ve all experienced how imposter syndrome can erode your confidence as a new hire, creating a negative feedback loop in your head. As you become increasingly reluctant to challenge the status quo or propose new ideas, your internal perception of not contributing grows. This further erodes your confidence, making you believe that you’re not as talented as the rest of the team.

When it’s left unchecked, imposter syndrome grows to affect how the entire engineering organization operates. Teams where imposter syndrome is prevalent often become risk-averse and narrow in their thinking. New hires learn to defer to more experienced teammates instead of sharing their insights or bringing fresh perspective to the table, which creates a divide between new and old team members that is challenging to bridge.

Checklists are nice, but they don’t fix the issue #

Because there’s no surefire way to predict what questions a new hire might have or where they may get stuck, we need to shift how we design our onboarding processes, especially if we want to combat imposter syndrome more intentionally.

Fundamentally, every developer wants to solve their own problems, and do so without pestering other people in the process. But when we orient our onboarding programs around checklists, we’re optimizing for task completion rather than creating self-sufficiency.

Instead, we should focus on giving new hires greater clarity around what direct actions they can take when they get stuck.

Successful onboarding programs are ones that help new hires feel comfortable with their knowledge gaps by providing the resources to learn on demand.

Here are some ways you can do this with your team.

Connect your code to the context behind it #

Many engineering teams want a “search-first” culture, where the default behavior is to RTFM before asking for help. This is often easier said than done.

Because the context needed to understand your codebase lives across dozens of places like Pull Request comments, Confluence and Notion pages, Jira issues, Slack discussion threads, and other tools, it can take hours, if not more, to stitch together an answer across all these sources. At the same time, centralizing knowledge into a single source of truth while keeping documentation updated at the pace of your development process isn’t always feasible or realistic.

But when the focus shifts from building onboarding checklists to equipping new hires to solve their own problems, you can take more specific steps toward the search-first culture you want:

• Assign jobs to specific tools: While many of the tools we rely on to build software can be used for a wide range of tasks, your team, and your new hires, can benefit from clear guidelines on the purpose of each platform. For example, you may want to specify that Notion is the system of choice for writing and storing engineering specs, while longer-running system documentation lives in Confluence. This level of intention can help a new hire better understand where to look for information.
• Create internal knowledge maps: Map out where different types of information live internally, similar to how you map your system architecture. You can include guidelines on where to search first, and even provide training on using internal resources effectively using these maps as a foundation. Not only should you provide your knowledge maps to a new hire on their first day, but as they onboard, encourage them to update your maps as they go.
• Build a culture of cross-linking: Because your team uses a broad set of tools, you should build links between systems. For example, encourage your team to include links to relevant Jira tickets in their Pull Requests (you can also automate these cross links directly, of course). This not only helps the people who are participating in a discussion today, but it pays it forward for future team members who will need to refer to this web of information later on.

Create a place for asking questions #

Being new and not knowing all the answers is usually expected and accepted by most engineering teams.

But the type and number of questions a new hire has when they’re getting started can make them worry about appearing inexperienced in front of a new team.

To help, consider creating specific places where new hires can get help from their peers and onboarding buddies. Dedicated help channels in Slack and other messaging platforms are a great way to establish a place for questions. You can also consider setting up a rotating schedule of team members who can monitor and respond to questions from new hires in these channels.

Using emojis in these channels can also help create clarity around the urgency of a question. For example, prefacing a question with a red circle vs a green one can signal that an answer is needed as soon as possible.

Or, just try Unblocked #

We built Unblocked with this very use case in mind. As developers ourselves, we not only know imposter syndrome firsthand, but we’ve seen our fair share of failed onboarding programs.

Unlike time-consuming, manual efforts to onboard a new developer, Unblocked works by augmenting your source code with existing knowledge across all the other tools your team uses, which means it can explain detailed concepts with ease. Unblocked also updates as frequently as your team makes changes, so everyone gets the most up-to-date information about your codebase.

With Unblocked, new hires get:

• Answers for nearly every situation: You can ask Unblocked all sorts of questions about your application — about the code, the context behind specific architectural decisions, the status of open issues from your issue tracker, and more.
• A dedicated place for asking questions: Unblocked’s desktop and web apps provide a conversation interface for asking questions, with answers that include code samples, cited sources, and a list of experts at your company who can help with a particular topic.
• Relevant, historical context for open code: Unblocked is available as an IDE extension that surfaces past conversations, discussions, and Pull Requests for files and lines and code. This is especially useful when you’re exploring a new codebase and don’t yet have a clear question to ask.
• Support across your Slack workspace: Unblocked’s Slack App answers questions asked directly in Slack channels. You can also ask Unblocked for a summarization of a channel to understand the history of what conversations and decisions have taken place.

And perhaps most importantly, Unblocked comes with Incognito Mode, where you can ask questions in private. This means your new hires can ask even the most basic of questions as often as they need without feeling exposed.

Teams who use Unblocked find that they’re able to onboard new developers faster and more comprehensively, replacing “30 minute meetings with three-second answers.” They also say that Unblocked is “the best application of AI’s potential in enhancing developer proficiency, making developers themselves more effective — rather than typing for them.”

No more imposters #

Reimagining your onboarding program to enable self-sufficiency positively impacts how new hires feel, which creates significant benefits for them, you, and the whole team.

We all want to ship code that solves problems for real users, and new hires are no different in their motivation. By making it possible for them to fully do the work they were hired to do, we can avoid the unnecessary trap of imposter syndrome.

Unblocked was built to help speed up developer onboarding (among other uses).

It answers developers’ questions quickly and accurately, using your team’s source code and code-related knowledge. Getting answers from Unblocked doesn’t require changes in how or where your team works or extra effort on your part to set up.