The Engineer's Onboarding: Advice for New Hires
A set of principles to help deliver value from day one, all while laying the foundation for long-term impact in your new role.
So, you’ve just joined a new company as an engineer -- exciting! Amidst all the new opportunities, technologies, and challenges ahead, you've also got a small lump in your throat as you prepare for the inevitable learning curve of the onboarding process.
Most anyone understands the benefits to a successful onboarding: you get a chance to lay the groundwork for long-term success by building strong relationships with your team and gaining a holistic understanding of your new company's systems and culture. That said, for many engineers, onboarding is synonymous with frustration. The pains are numerous – setting up a new dev environment, setting up multiple new accounts, etc; even pushing a simple pull request can consume many annoying hours.
Add to that the fact that many companies measure early success by how quickly you can ship code, you may be tempted to skip essential foundational learning for rapid output. In my view, that approach is short-sighted.
An onboarding period is a terrible thing to waste: the first fateful domino in your tenure at a company. As such, I’ve outlined a set of principles and practical tips for the optimal ramp-up. With the right mindset and preparation, you can establish a solid foundation for long-term impact.
The principles
The larger the company (and codebase), the longer it will take you to be effective in writing code.
While this might seem obvious, it’s rarely acknowledged. New engineers often feel pressured—by themselves or their colleagues—to match the speed of their previous roles within days or weeks. However, the simple truth is that larger codebases require more time for one to build the institutional knowledge necessary for effective development.
Optimize for building context
With principle 1 in mind, one should optimize for building context – this is typically pretty hard since many company’s incentives serve as reward to those who churn out code, and one’s early success often is defined (incorrectly in my opinion) by how quickly you can start producing code. If you find this to be the case, talk with your manager about wanting to prioritize learning/building context; you can even map out the things you plan to learn to demonstrate that you are productively spending your time even if you aren’t producing code quickly. While this proactiveness will pay massive dividends in the long run, it can be seen as counterintuitive early on because you may feel pressured to provide value as quickly as possible.
You still can have massive impact from day 1
The first two principles might seem to imply that you cannot provide value to your company early on - after all, if you can’t develop effectively within your first weeks/months as an engineer at a new job, then what value can you provide? As it turns out, there's plenty:
Take notes on what went well during onboarding and what can be improved Use this to improve the onboarding process for future engineers. This is arguably the highest leverage activity you can do within your first 2 months at a new company.
Improve or create new documentation
The more institutional knowledge an organization can take from the minds of engineers and put into concise documentation, the better the organization will operate over time. Improving the company’s documentation will not only help new engineers onboard, but also assist in ongoing knowledge transfers, etc. Onboarding is often the best time to improve documentation before you are mired with the demands of the work of a fully ramped engineer.Share what worked well from your last job
Were there any tools/processes/systems in place at your old company that could augment what your new company is doing?Leverage your fresh perspective
One of the most valuable resources for any tech company is the fresh set of eyes that come with every new engineering hire - you aren’t saddled with the assumptions/biases that are inevitably present in everyone currently working at the company. To that end, you provide a perspective that can potentially help drive the company towards the optimal solution for its current problems. Don't assume that your perspectives are automatically novel and that no one else has considered what you're seeing. At the very least however, questioning everything will help accelerate your learning.
By taking these principles into consideration as you onboard, you stand to provide immense value to the company up-front which will afford you ample time to build context and learn your codebase/stack.
With these principles in mind, here are some practical tips that will help you accelerate your time-to-productivity as an engineer:
Practical tips
Use the product as much as possible
While this point may seem obvious, it is by far the most overlooked part of the engineering onboarding process. No matter where you operate on the stack, developing an understanding of the product that you are building from the perspective of the user will help you be more effective as an engineer. Adopting this POV is especially critical with B2B products that you may not use day-to-day. Using the product will help you understand how the codebase works at a system level, for understanding how each code module maps to the product is critical to understanding why that code exists.
Pair Program
Pair programming enables engineers to share best practices, improves the odds of reaching the optimal implementation, and helps create code that is more consistent and readable. Pair with every engineer on your team: first, by asking them to shadow you as you implement your first set of tasks and secondly, by shadowing them as a means to learn about the codebase and the set of coding practices your team/company follows.
Shadow on-call engineers
Taking the spirit of pair programming a step further, consider shadowing your on-call engineer as they debug issues or to chat at the end of their shift to go over the most interesting problems they solved. This understudy will help in the following ways:
You learn about all the internal tools used by your team
You gain additional understanding of the data models in your team’s domain
You gain insight into how the customer-facing product maps to the code base
You gain perspective on the code-base from a systems perspective, as many bugs often span multiple layers of the stack or multiple services
You develop better relations with everyone you shadow
Follow requests along the full stack
Whether you are a front-end, back-end, or full-stack engineer, you should follow a request from the client along the entire stack. Doing so will help you understand the overall system design, which in turn will help you navigate the codebase faster. When tracing through the stack, ask yourself the following:
What is the purpose of this layer, and why does it exist? Does it handle auth, validation, serialization, DB reads/writes, etc?
Who owns each layer?
Are there code patterns unique to each layer?
Where is each layer found in the directory structure?
Are there naming conventions to each layer that will help you find new modules/code in the future?
In following requests along the full stack, use this time as a chance to get familiar with your IDE’s debugger if you haven't already. Additionally, try using Cursor—our go-to internal IDE—which is helpful at answering questions about your codebase.
Ask an engineer to walk you through the data models
There are several important sets of knowledge that cannot be discovered through reading code and must be absorbed via talking to someone with historical context of the codebase:
How has the database schema changed over time? Having this set of knowledge gives more context as to why the database exists as it does today
What were the trade-offs made in picking the current db schema? For example, for tracking updates made to table foo, why was a separate foo_updates table made instead of directly updating the foo table itself?
What are the current faults in the current database-schema? If given more time, would the team like to perform any migrations?
Ask why major engineering decision were made
In general, it is rarely enough for a new engineer to just read the company codebase to learn about the system. How so? Because engineering is always about tradeoffs. The current state of the codebase is always a function of how the set of product requirements changed over time, how the engineering team adapted the system to these requirements, and how much time was available for making these changes (a team often foregoes implementing the optimal solution due to time constraints).
Asking experienced engineers about the trade-offs they considered when developing the current system helps you understand why the system is the way it is today; more importantly, those conversations give you insight into where improvements can be made going forward. It also helps you understand how the product itself has evolved overtime as client needs have changed/evolved.
Dedicate time to understanding the dev tooling
By the end of your first month, you should be intimately familiar with your entire tool stack, across alerting/observability (eg. Datadog), user session tracking (ie. Fullstory), analytics (ie. Segments), internal tooling (ie. Retool), database IDE (ie. Datagrip), IDE (if a new one is mandated by the company), etc.
Optimize for breadth over depth by touching as much of the stack as possible
Following principle 2 (optimize for context), in your first few months at a new company, you should try to work on many small tickets that touch as much of your team’s domain as possible. This work will be a forcing function for optimized learning over raw output. Of course, this may not align pragmatically with your team’s roadmap, or there may not be tickets that touch all parts of your team’s code. If so, I recommend telling your manager that this is a priority of yours and ask if they are willing to help optimize for breadth initially.
After you have closed out a few smaller tasks, I recommend asking your manager to help you find a project that touches multiple layers/services/domains that your team owns. Working on a project of this kind will help you to build a more cohesive understanding of the codebase from a systems perspective, as the project will illuminate how different parts of the codebase interact in practice.
Shadow Calls with the Customer
Reach out to CX/Sales/Product – whoever directly interacts with the customer – and ask if you can shadow several calls with them. Doing so will help you build empathy for the customer you are serving and help you understand the customer’s main pain points.
Meet as many people as possible
When joining a new company, aim to build relationships. That goes as advice in and of itself, but also will serve you well in advance of needing to ask people for PR reviews, meeting time, or help. I recommend figuring out which teams are adjacent to yours (both engineering and otherwise), and meeting everyone 1-on-1 within your first month at the company. While that might sound exhausting, especially for the introverts among us , you will begin to build meaningful relationships at the company that will in turn make your work more enjoyable. And as a helpful aside, people are always more willing to help those they already have met personally.
More tactically, ask about the objectives of their role, how they collaborate with other teams, the challenges they face, and any advice they have for navigating the company. This insight will help you understand your place within the broader organization and may even highlight opportunities to improve internal systems and communication.
When we onboard new engineers to the Numeric team, we keep these principles and pieces of advice top of mind. We consider the process successful after two months if the new engineer has developed informed opinions on the codebase, product, team practices, and/or overall strategy—something that’s only possible with the right knowledge and context from the start.
To build that context quickly, we've streamlined our onboarding documentation and local development setup so engineers can have the app running on day one and submit their first pull request by the end of that day. This efficiency lets them focus on onboarding tasks that span many aspects of our product and domain without having to waste time burning brain cells trying to get a dev environment properly setup.
We also integrate context-building activities from the very beginning. New engineers join customer and sales calls during their first few weeks, meet colleagues across every department, shadow on-call engineers, and engage in in-depth discussions with team members about past projects. Combined with other effective practices, this approach enables us to ramp up engineers quickly while ensuring they have the comprehensive context needed for long-term success.
If these practices interest you, we are hiring for more talented, product-oriented, full-stack generalist engineers to join the team. Here is a one-pager that gives more context on who we are, what we are building, and why we are building it. Please reach out if interested: ben@numeric.io