How do you onboard new developers?

Comments

[Pulkit Chaudhary]

At Leado, we try to make the new developer work on a side-feature, but an important one, when they join so that they don't get overwhelmed by the codebase's complexity at the beginning. Gradually, we keep pulling them into the main codebase and start giving them more complex features.

To guide the new dev, we assign one of us as a mentor to the new dev.

Apart from this, accounts are created for them and their system is setup to run production-ready code on day 1. From day 2, they start checking in the code into production.

One of the main things we follow is to encourage the new dev, if fresher/intern, to think for themselves and come up with their own architectures so as to get enhanced learning.

[David J Eddy]

At Sourcetoad we try to have all hardware and software setup, installed, and running. Nothing says 'we dont know what we are doing' like spending weeks trying to get setup (like some places Ive been). Day one the new engineer is assigned a mentor; that mentor is repressible for ensuring the new hire gets settled in properly. For the first two weeks the mentor is the go-to person for the new hire for anything.

Myself, I try to have the hire push something, no matter how small to at least the projects UAT environment. Maybe even production. The sooner they are invested, the sooner they feel included.

We also have the standard documentation resources available from the get go. Information is power.

[Max Stoiber]

This is a meta answer, I guess, but…

Todd Motto's public-apis repository on GitHub is choke-full of awesome (and free!) APIs that one can use. Highly recommended to check out!

[Brian Driscoll]

How is this in any way related to the question?

[Ben Halpern]

Woops, that's my fault. Linked to this thread with the wrong title in an email.

[Su-Shee]

I recently had the single best onboarding EVER on a job.

I got on my first day essentially a "lesson plan" starting with an intro and a little bit of paperwork, followed by - wisely - the barista lessons to use the coffee maker. ;) (no, really.)

The onboarding contained:

• installation of important things
• security procedures + account creation (lots of legal stuff involved there, it's due to the nature of the work more bureaucratic and painstakingly than usal)
• introduction to the collection of inhouse tools and applications
• visit of the data center
• walk around to show me to all departments and introduce me and say hello
• basic "socials" like which channels in the chat are to join for fun
• have lunch with all kinds of people

As I'm in a central department as a technician, I also get passed around through all other departments who introduce me to their work, so I got an awesome overview which was ALSO very well prepared.

My workplace was of course ready, all keys, phones, "stuff" I needed at hand. The first thing I got handed were the company goodies. :)

My team introduced me to "the stack", I checked out the code, installed my favorite tools on my computers and was ready to go.

Also, development environment is very well prepared considering the size and age of the code bases it was really smooth sailing.

So the first three days (!) were super busy but really supremely well organized.

I also saw that for example all tickets necessary for my onboarding were created in time, that everybody got told that I would start and where and so on - so I could see the smoothness of the preparation, too.

Work-wise, I generally ask for a collection of bugs and low hanging fruit which bring me around in the codebase so that I get to see and understand things as fast as possible, combined with introdcutory overviews over architectures and of course the usal folklore and history an old code base has.

And, that should of course go without saying but none the less: People were nice and welcoming and generally gave the impression to be happy to see me.

It boils down for me to "excellent preparation and organization" and "well prepared sharing of knowledge".

[Philippe Ozil]

At Salesforce, we have a mix of different techniques. Along with standard best practices such as documentation, mentoring and code reviews we also have more "corporate" resources.

We have an onboarding program that requires all world wide employees to attend some classes at our HQ. Developers follow a dedicated 2 weeks program. This allows them to become familiar and align themselves with our tooling and Agile methodology (Scrum, Kanban...).

We also have a very valuable tool to onboard developers: Trailhead our e-learning platform.
We use this tool both externally to grow our ecosystem and internally to onboard our staff with some private content.

[Enno Rehling (恩諾)]

When I worked at IMVU, we paired each new employee with a mentor, whose responsibility it was to get the new developer up to speed. They worked off of a checklist of typical tasks to pick from the board on the first day, first week, etc.

We chose to trust new employees (or rather, our hiring process), and one of our goals was that everyone made a change to the live production site on day one. Rapid iteration and Continuous Deployment were important parts of our culture, and we wanted new people to buy into that as soon as possible, and be fearless.

IIRC, new employees counted as only half a developer during sprint planning for their first three months, due to their needing to spin up on a lot of new stuff, and slowing down their mentor. Being a mentor to a new employee was an important step for junior developers transitioning to becoming seniors, and everybody gladly took turns.

Side note: We used the same process for interns and co-op students, but despite our efforts to find good candidates, some of them did not have the same qualities as our hand-picked new hires, and did not have the same long-term perspectives with regards to learning our teams' best practices.

[Ghost]

At my previous job they hired a lot of junior front end devs aka straight out of uni. We found they didn't really know the fundamentals, or at least they weren't confident with them. Over about a month period we essentially gave them a fake project which used the tech they will most likely use on a project so html, sass/css, javascript and git.

We set them a task of building a font page of a site, this allowed us to know where they were, we gave feedback and they were told to improve what they had done. This went on for a 4 week period and it was quite effective, they weren't experts by any means but they were confident and knew how to figure out problems.

It might seem like a long time, but it was worth it in the end we saw these people produce better work in a shorter space of time compared to the other hires that didn't end up going through our process.

I think the most important thing to do when hiring new staff members (junior or expert) is to make them feel confident and comfortable, that way they feel more empowered and have ownership on what they are doing and don't have anxiety of what they are going to have to battle on that day.

Things I have found most effective

• Documentation (you can say code should document itself, but you forget other people aren't at the same level as you)
• Tests
• Maintainable code (if not document why and how to work with it)
• Pair programming
• Don't be judgemental

[Synergist Computing]

Completely agree! We have a very similar process at Synergist. We provide each of our new, junior developers that platform to learn concepts that they may have not learned in university and give them projects to build their skills. We make sure that they understand that they're already talented, but that there is just a level that they have to go up to in order to really hone into what skills they already possess; we definitely don't want to instill fear or anxiety, rather a nurturing environment.

[Ben Halpern]

Yeah, there's a lot of temptation to get people being "productive" as quickly as possible, but delaying productive contributions slightly in order to ensure long-term productivity in the form of good work and maintainable code seems like the way to go.

[Aaron Alexander ⚑]

Ask 5 Ws of Dev Experience:

1. Who are your tools? (tmux/vim? emacs? atom? xsort? concept mapper? toolkits? grunt/gulp? browser plugins? package managers? cli tools? interesting one-liners?)
2. What's your best/daily workflow? (What do you typically feature-branch for?)
3. When are your best times for achieving flow? (8-12? 4-11? nightowl?)
4. Where are your best places to work? (This is more about lighting and social conditions matching.)
5. Why do you not like X (some known existing tech of the company that involves tech debt of some kind or that the dev must conform to)?

[Mike Gasparelli]

I'm currently thinking about this problem. As a 2-dev team, we don't currently have a ton of processes in place.

I'm starting by documenting processes and practices. We have a fairly large environment with many data sources and integrations, so documenting this will be next.

I'm definitely going to pore over this thread to get some more ideas :)

[Co-op Source]

Unfortunately, due to unique geographic and domain circumstances, we rarely hire junior developers. Almost everyone in our engineering dept has more than 20 years of experience. When we hire it tends to be another senior developer who has already been around the (same) block and the work is very familiar. Most of our work revolves around hw/sw that deals with very well known standards so we tend to work w/ that rather than our own in-house constructs.

For the few recent grads we've hired, we give them one of our products and have them enhance it with new features. They ask questions when they get stuck and we tell them "don't suffer in silence!" - just ASK! No shame in asking questions.