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.
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.
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".
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.
Experienced PHP and C programmer based in Norway, with a history of game and web development. CTO at Blue Scarab Entertainment, previously at Servebolt.com, IMVU, Smarterphone, and Funcom.
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.
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)
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.
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.
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 :)
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.
Since the only way into our company at this point is via the internship program, we've had our share of "deer in the headlights" college students start work at MousePaw Games, clutching their programming textbooks to their hearts and staring at everything in wide-eyed wonder (and a dose of culture shock). This is largely metaphorical, of course, since we all collaborate over the internet at this point, but the glazed look is almost invariably present during the first video chat.
To help ease the transition, we maintain friendly, detailed documentation for our processes, workflows, and collaborative tools. I also created a tutorial that walks the intern through the process of setting up and getting comfortable with the tools they'll be using.
After that, we give them one or two fairly straightforward assignments. One is to start reading Dreaming in Code by Scott Rosenberg, which is required reading at our company. That book alone helps onboard new developers to the industry at large - by about halfway through, their idealistic view is pretty much toast, and they can start coming to terms with the real challenges of a live project.
Second, we have them look through some part of the code they'll be working in, usually while adding some simple and straightforward improvements. I'm a stickler for good comments and documentation (if anyone couldn't tell from my "Your Project Isn't Done Yet" article), so that eases the transition into the code. Interns are encouraged to ask questions freely on the collaborative platform, and our staff is always willing to help.
At Lunar Logic we do 3 month long, paid internships. Two, soon-to-be, developers work together on a project. The internships projects are non-commercial but always something useful like our open source Rails Girls submissions app. We try to make the working environment as close to a real project as we can. This means that interns work with lead developer (their mentor), testers, designers and also a client - usually someone from the office that will use the app.
The internships have proved to be a great way to invest in new people and build their experience. Given autonomy and authority, interns very quickly become a valuable part of our team. Eventually rocking in commercial projects and also contributing to our culture.
The interesting part is that starting from day 1 interns can make any decision the CEO can make and that's true for anyone in the company. Of course, deciding on complex matters requires knowledge about company interns don't yet have. It’s not uncommon for interns to buy books they need or make pivotal changes on the project they are working on.
The pattern looks similar not only for developers but also for testers, designers and product owners.
A year a ago I have become part of a new team which joined a project which was developed till then only at one site of our company. We moved there for one month. In the first week we got a lot of training in the form of presentations about Spring, Kubernetes, REST, etc. The installation of the required tools was done with the ePages-de/mac-dev-setup project for Mac laptops and some similar scripts for the Ubuntu laptop I used back then. Afterwards we go a lot of guidance in the form of pair programming for things like writing API tests, starting up the development environment and so on. In the next months we received feedback in the form of joint code reviews for big changes and standard code reviews for little ones.
For the one new developer who joined us half a year ago we have developed a little checklist based process. It starts with a general section where things like requesting the required hardware in time are stated. Then there is a big table with all the tools and practices which are required in our daily work. One column is the subject and others are the link to the RevealMD presentations we have derived from the original presentations, a checkbox for the theoretical explanation, and a checkbox for some form of exercise (either a practice or a sub-task from a real user story). In this way we could make sure that basically everything got covered. Another important part of our onboarding strategy is pair programming.
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.
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.
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!
How is this in any way related to the question?
Woops, that's my fault. Linked to this thread with the wrong title in an email.
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:
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".
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.
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.
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
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.
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.
Ask 5 Ws of Dev Experience:
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 :)
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.
Since the only way into our company at this point is via the internship program, we've had our share of "deer in the headlights" college students start work at MousePaw Games, clutching their programming textbooks to their hearts and staring at everything in wide-eyed wonder (and a dose of culture shock). This is largely metaphorical, of course, since we all collaborate over the internet at this point, but the glazed look is almost invariably present during the first video chat.
To help ease the transition, we maintain friendly, detailed documentation for our processes, workflows, and collaborative tools. I also created a tutorial that walks the intern through the process of setting up and getting comfortable with the tools they'll be using.
After that, we give them one or two fairly straightforward assignments. One is to start reading Dreaming in Code by Scott Rosenberg, which is required reading at our company. That book alone helps onboard new developers to the industry at large - by about halfway through, their idealistic view is pretty much toast, and they can start coming to terms with the real challenges of a live project.
Second, we have them look through some part of the code they'll be working in, usually while adding some simple and straightforward improvements. I'm a stickler for good comments and documentation (if anyone couldn't tell from my "Your Project Isn't Done Yet" article), so that eases the transition into the code. Interns are encouraged to ask questions freely on the collaborative platform, and our staff is always willing to help.
So far, it works pretty well for us.
At Lunar Logic we do 3 month long, paid internships. Two, soon-to-be, developers work together on a project. The internships projects are non-commercial but always something useful like our open source Rails Girls submissions app. We try to make the working environment as close to a real project as we can. This means that interns work with lead developer (their mentor), testers, designers and also a client - usually someone from the office that will use the app.
The internships have proved to be a great way to invest in new people and build their experience. Given autonomy and authority, interns very quickly become a valuable part of our team. Eventually rocking in commercial projects and also contributing to our culture.
The interesting part is that starting from day 1 interns can make any decision the CEO can make and that's true for anyone in the company. Of course, deciding on complex matters requires knowledge about company interns don't yet have. It’s not uncommon for interns to buy books they need or make pivotal changes on the project they are working on.
The pattern looks similar not only for developers but also for testers, designers and product owners.
A year a ago I have become part of a new team which joined a project which was developed till then only at one site of our company. We moved there for one month. In the first week we got a lot of training in the form of presentations about Spring, Kubernetes, REST, etc. The installation of the required tools was done with the ePages-de/mac-dev-setup project for Mac laptops and some similar scripts for the Ubuntu laptop I used back then. Afterwards we go a lot of guidance in the form of pair programming for things like writing API tests, starting up the development environment and so on. In the next months we received feedback in the form of joint code reviews for big changes and standard code reviews for little ones.
For the one new developer who joined us half a year ago we have developed a little checklist based process. It starts with a general section where things like requesting the required hardware in time are stated. Then there is a big table with all the tools and practices which are required in our daily work. One column is the subject and others are the link to the RevealMD presentations we have derived from the original presentations, a checkbox for the theoretical explanation, and a checkbox for some form of exercise (either a practice or a sub-task from a real user story). In this way we could make sure that basically everything got covered. Another important part of our onboarding strategy is pair programming.
Right now we doing realy cool project, its trank.com.ua and it's course hunting for developers.
How is this relevant to the question?
Woops, that's my fault. Linked to this thread with the wrong title in an email.