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.
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.
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.
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.
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.
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 :)
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.
Oldest comments (20)
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.
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.
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.
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.
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.
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.
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.
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 :)
Ask 5 Ws of Dev Experience:
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.