We are a small software company and in going through a technical evaluation recently, it was brought to our attention that we lacked an "onboarding" process for new developers. "Onboarding" is exec-speak for a process for getting new hires up to speed. We do have a process which is:

  1. Get the new hire setup on their machine including access to domain, source control, issue tracking etc. While the installation of software onto their machine is done before they arrive, some time is needed to answer questions like "Where is your SCM?" and "How do I log into it?". For example, while the source client is already installed, new developers aren't going to know what program we use or perhaps even be familiar with that client. They know SCM in general or they wouldn't be there but not necessarily our client. The same is true with our issue tracker.
  2. Spend an hour or so going over what the company does, how our solutions solve problems for our clients and general system architecture.
  3. Introduce them to other developers.
  4. Let them spend the rest of the day reviewing the architecture and source for one of our products. That means pulling down the code, compiling and running it and/or looking at database diagrams.
  5. The next day, give them some specific project on which to work along with introducing them to the stakeholders and other team members on the same product.

My main questions are:

  • If this process is insufficient, what is it missing?
  • Is there a recommended onboarding process for developers? It would help to know how do other software companies do their onboarding (or how to go find out they do it).

Lastly, and I realize this may be considered a separate question, how should that process be documented?


9 Answers 9


I think you need more than the day or so you're spending on this. Telling people stuff outside of a context in which they'll use that knowledge only goes so far.

Our process (smaller enclave in a large company) goes like this:

Morning of first day: administrivia -- passwords, HR stuff, time-reporting training (needed for compliance tracking), tour of space with introductions to key people. (Not just the key technical people, but also the ones who'll help you if you lock yourself out or set off the alarm, need to submit expenses for reimbursement, IT support, etc.) We would prefer not to lead with paperwork, but it blocks other key tasks, including access to the corporate network, so we have to get it out of the way.

Rest of first day: spent with your mentor, a technical person working on the same team you'll be working on. This is a mix of tools (not just what the SCM commands are but how we use branching, for example), project architecture, and acculturation (how we do things, informal resources like the wiki, who the key gurus in various technical areas are, where to eat lunch...). This is pretty free-form, guided by the style of the mentor and the needs of the new employee.

First week: continued mentoring (mentor should be spending an hour a day on this, minimum), and the new employee is assigned several bugs to fix. The mentor helps navigate through the code (it's a large code base), coding standards, bug process, etc. All bug fixes are code-reviewed (everybody's, not just new people's); the mentor usually does informal reviews of these early bugs before they're sent for official review. Concurrently, continue to review important documentation, start using the wiki, file bugs as they're encountered, etc.

First couple weeks (variable): newcomer is assigned meatier tasks alongside bug-fixing and begins contributing more directly to development. This varies based on the experience of the newcomer and the current phase of the development cycle for that project.

First month: new employee meets with his manager to do goal-setting and discuss expectations. (Our performance-review process involves formal goals that are evaluated at set times; this will be the first set for this employee.)

  • 7
    To be fair, I'm not spending just a day on this. Your process includes an important element we are missing which is a dedicated mentor.
    – Thomas
    Jun 4, 2012 at 16:21
  • 9
    @Thomas, oh, sorry, I misunderstood. We have found the mentor to be really important. Not only does the mentor do the things I've described, but he also acts as a first point of contact for a confused newbie for everything from "this code is incomprehsible, help!" to "where do I get a longer network cable?" to "what's that guy's name again?". (Though on that last, we also maintain a wiki page with everybody's pictures and names. It helps us older employees too.) Jun 4, 2012 at 16:47
  • 1
    My experiences were very similar when I started in my current company. For the first week I'd meet all product leaders, second week the product managers and 3rd week I'd get several group conversations. During the spare time I've been given some standard documents to read and had to talk to every developer individually on what their knowledge was. The amount of actual software development that I've done within the first month is small, but taught me a lot on how this company works. It's important the employee fits within the company. If he doesn't it wont even matter how skilled he is.
    – Migz
    Dec 2, 2016 at 10:52
  • @MonicaCellio: While on top of the mentor being a dedicated person to help out, it can be useful to have a single point of contact if, over the day or the first weeks where you show them the documentation to get started, the newbie finds that it's out of date (i.e. "Oh right, that process's been updated,", or "Oh, that's a legacy tool - you shouldn't need it for initial setup, but it'll be good to know when dealing with <X>", etc.). Mar 28, 2022 at 4:55

Get the new hire setup on their machine including access to domain, source control, issue tracking etc.

Setup should be done before they arrive. Development practices should be automated as much as possible, and the manual steps should be documented. If you regularly have to execute multi-step procedures to perform routine developer actions (check out, check in, test, release, etc.) then your process is insufficiently automated and you are wasting money.

Spend an hour or so going over what the company does, how our solutions solve problems for our clients ...

Good, it's very important for people to understand how their work drives revenue for the company.

... and general system architecture.

Let them spend the rest of the day reviewing the architecture and source for one of our products.

Reading code or documents with no specific goal is a waste of time. Instead of attempting to eat the elephant, they should check out the code, build it, and run unit tests, with the help of another developer if necessary. If much help is required, you should clean up your build process.

The next day, give them some specific project on which to work along with introducing them to the stakeholders and other team members on the same product.

Good. Ideally they would be paired with another developer on that product.

  • 3
    Setup is done before they arrive. However, that they have the SCM on their machine doesn't mean they know how to use it or log into it. Same with the issue tracker.
    – Thomas
    Jun 4, 2012 at 6:17
  • they should check out the code, build it, and run unit tests, with the help of another developer if necessary That is what I mean by "review the architecture and source". They have to know how to get into source control before they can review the source of course.
    – Thomas
    Jun 4, 2012 at 6:18
  • Can you expand your comment about automation of routine developer actions? We do have automated builds which pull source, build, and deploy to a test server. However, this is different than automating a developer process like checking out a file.
    – Thomas
    Jun 4, 2012 at 6:21
  • @Thomas: You should automate to the point that there is a single step between developer decisions. You can't do better than that. Jun 4, 2012 at 15:38

One of the key element every new employee should have is be familiar with your product, not just the source code and architecture, but also from the user point of view.

My first day on my current job was mostly using the product I was going to work on, like any of our users. In former Jobs, I sometimes worked with developpers asking "Our product can do THAT ?!". This helps understanding the code better and provides feedback from a "newbie user", which can sometimes help find bugs that you don't see when you test while already knowing the product.

  • 6
    I often think all devlopers should spend 1 day every six months using their product. We'd have a lot less crappy software that the users despise.
    – HLGEM
    Aug 14, 2012 at 13:29

I don't think there is a hard rule to this. Obviously the machine should be set up for the job with all the software installed, passwords set up, and most of all. Email.

Give the guy a point of contact with all parts of the business that will concern him. HR, Lead Developer etc.

You could always add a wiki to your network. Ask the new guys to fill in the wiki with the bits that other newbies would require when starting the job. This makes the task self documenting.

You must allow for around 3-6 months for the new guy to bed in (take root) and the new guy must be fed and watered at regular intervals (never just leave him sitting in the corner, looking like a spare part).

Don't give the poor chap handbooks, they are crap and just get filled in a draw.

Allow for time, give the chap some basic self contained tasks at the start that are not required to be integrated into the main project, or can be easily attached to the main project(s) through component design.

Allow the new guy to freely look over the code base for at least 2 weeks, to get acquainted. Just make sure that he is a new guy and not a competitor. :)

  • mmm...handbooks. Yeah, I think officially there is an employee handbook but it fits into the category of paperwork for the developer to read offline. We do have a wiki with quite a lot of information but it would helpful if you could outline some of the bits of information that it should have for new developers. E.g., company holidays, coding standards, network diagram etc.
    – Thomas
    Jun 6, 2012 at 1:37
  • Let the new guy do the Diagrams, etc it will aid in the absorption of new material. Holidays and the like should be covered by the contractual agreement, along with disciplinary procedures and holiday booking procedures, sickness etc. Jun 6, 2012 at 1:43
  • 1
    Coding standards...that should be done by one of your lead programmers, this will depend on what language your using. I would only advise that you use the coding standard as used by the creator of the language. You can usually get this material online. Jun 6, 2012 at 1:46
  • We do have our coding standards on our Wiki and those were created from recommendations by language vendor (Microsoft) and other high level developers.
    – Thomas
    Jun 6, 2012 at 1:48
  • Okay, Database stuff, connections etc, a diagram showing how you split your code up front-end, back-end, database. Names of servers, and what they do. Passwords for Database, coding procedures for the DB stored procs (if you got them). Source Control, procedures for check-on, check-out, merging. Any code that you got that isn't self documented, how to integrate and perform integration testing, unit testing. Roll out procedures of new code (Development, testing, live etc.). Jun 6, 2012 at 1:51

Is this process insufficient?

Yes - Let me explain why.

Get the new hire setup on their machine...

A good first step.

Spend an hour or so going over what the company does...

Yep. Probably a good idea.

Introduce them to other developers.

Another good idea. To avoid any "first-day" awkwardness, try to do this as early as possible.

Let them spend the rest of the day reviewing the architecture and source for one of our products. That means pulling down the code, compiling and running it and/or looking at database diagrams.

Hmm... Time could be better spent elsewhere. See below.

The next day, give them some specific project on which to work along with introducing them to the stakeholders and other team members on the same product.

OK. This is the most crucial step. Here's why:

  • Good programmers love to solve problems; but in order to solve a company's software problem, a programmer must understand the requirements and some back story before he/she can get started.
  • Even if you're not a pair programming shop, and even if the new hire is a senior developer, I highly recommend pairing the new hire with another developer for at least half a day. Why? Because that developer will have more smallish questions than you could've possibly anticipated and imagined.
    • This new hire, if he/she is any good, should have two qualities (among many others): Self-sufficiency and curiosity.
    • There will be plenty of time for the new hire to demonstrate his/her self-sufficiency.
    • But for now, you should feed his/her curiosity about your business, your culture, and your process.
    • Many of the new hire's questions will likely be of the "low-hanging fruit" variety, and by themselves won't take very long to answer.
    • So my advice is: Don't put the new hire on an island too early, pair them with another developer at the beginning, and start them off on the right foot.

Sounds like you've got a good first day agenda, but you probably want to find a way to answer some longer term needs. How you answer them is heavily dependent on your company culture. But here's the points to consider.

  1. Revision of the setup process - particularly the technical part - I've noticed most development shops have tools and configurations that change pretty rapidly. I have yet to find a situation where the process was so stable and automated that the guy was instantly up and running. Given that no one loves maintaining a process like this - I recommend some mechanism where the new guy updates the process (scripts, manual procedures, or both) for the next new guy.
  2. Culture stuff - every group and organization has some unspoken culture stuff. This typically takes 3-12 months to fully absorb - mileage varies by both new hire and group. There's no perfect mechanism here, but having some mechanisms that are fairly mutable per person is good - like mentors, informal contact with management, and introductions to any electronic communication mechanisms and etiquette is a good plan.
  3. Feedback - no ever is perfect on the first try - on the first few projects a known and understood feedback mechanism is important - pair programming, code reviews, supervisory reviews, or external testing are all great technical mechanisms. But also feedback as needed on communication and personal style. Even "you're doing a great job! keep it up!" is important to make sure that you say.
  4. Problem domain ramp up - the big difference between the new guy who knows your technology and the been-here-forever guy who knows your technology is the problem domain expertise - having some plan for how people ramp up on this is critical. It may be done in terms of how you assign projects, or how long you wait before exposing the new guy to the customer - but have some background plan for how he gets smarter about your business risks before he has to take on the big risks.

Some of this may be part of your general processes - after all, a code review is good for long-time people too - it's just a good quality control mechanism. So you may or may not have more code reviews for new people - as long as it's a conscious decision, you're off to a good start.

You may also consider reviewing the onboarding process with new people after they are successfully "onboarded" - what worked, what was a waste of time?


Depending how complex your company setup is, it might be more beneficial to spread these activities over a number of days. Onboarding will include more than just the development environment for the software engineer. Even if your company deliver software products, there will be other items such as:

  • company administrative process (eg. emergency procedures for when a fire breaks out)
  • introduction to other departments in the department (eg. design, or hardware, or IT)
  • the other projects being run in the company
  • Did any company with which you worked have a formal onboarding process and if so what was it?
    – Thomas
    Jun 4, 2012 at 14:36
  • @Thomas For my onboard process, I was given a formal presentation by all departmental heads in the company, (about 15 presentations), all my company's product were walked through, company positioning in the market and industry, detail walk through for my department and HR, and my project walk through. It took about 2.5 weeks to complete (not in one block). All the steps were formalised with verification.
    – tehnyit
    Jun 4, 2012 at 14:43
  • 1
    @tehnyit, how much of that knowledge did you use before it rotted? That is, was this well-targetted, or was it more of a fire hose and you had to re-learn some of it later (because, say, it was about projects you didn't work on until then)? Jun 4, 2012 at 15:56
  • @MonicaCellio Most of the knowledge stuck with me. The presenters realised that majority of the details will be lost before it can be used. However the real value is providing an introduction to the department and some contact points into the department. Even if the detail were forgotten, I still have some idea as to who to approach to get more information.
    – tehnyit
    Jun 5, 2012 at 9:22
  • @tehnyit, it sounds like they did a good job. Hearing stuff you'll forget, but will recognize later as "they said something about that", is valuable. Some places do the "fire hose of details you're doomed to forget within the hour", which I've found counter-productive. Jun 5, 2012 at 15:54

Another thing that is missing (and maybe you already do this for everyone so didn't mention it) is code review. I have seen new developers get in horrible fixes because no one looks at their code for months. I have seen new developers put on projects with key deliverables who weren't checked frequently and who quit immediately before the deadline with no notice because they knew they had not produced anything (the reason why we now have code review of all code!). Even if code review is not a standard practice in your shop, you need to review it with new people. You can save them from some major mistakes just because of incomplete product knowledge. You can make sure they are actually writing code.

Of course the reviewers probably thought you had no onboarding at all because you don't document it. A simple sign-off sheet where they check what has been done and sign and date is enough.


If there's a existing training curriculum for the software product/system, have the new hire do that first. There usually isn't, or it's too limited.

A new software developer should then follow step-by-step a regression test plan. There should ALWAYS be a regression test plan.

After performing the regression test plan, reviewing/fixing/adding unit and/or integration test cases within source code is encouraged. This will allow the developer get to know the "API" of the legacy system. I put API in quotes, because there may not be a formal API, but every software product/system has its own set of interfaces.

Then the developer should begin fixing existing bugs.

Finally the developer can start developing new features and/or refactoring.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .