Do you have any short-term trial period to minimize the risk that a junior developer won't fit your company? If not, why? Do you think that test tasks and interviews are enough?
The short answer is yes, trial period is fine, however keep in mind that this is a two way street when it comes to risk aversion for new members. We all have our own way of adapting to new environments, some quicker than others, but not any more or less of a risk. This was a lesson I learned early on, so try to keep in mind that an entry period is just as much a trial for existing members to assist the new member and help them adapt with as little stress and confusion as possible. This is important to understand when you ask, "Do you have any short-term trial period to minimize the risk that a junior developer won't fit your company?" Sometimes the culture of the team/company is great for existing members, but harder for new entries. Patience is the key here and since this is still an investment that needs relatively quick return, so just keep in mind that this is still a person. They are still human. :)
When it comes to risk aversion; it's pretty minimal anyway in the beginning. Even if your version control and agile process is minimal, it will still keep the risk down when you can isolate the new members work. Keep them in their own sandbox at first and see if they can handle the more important grasp of taking a simple, but actual contributed task, and execute within your team standards. No point in giving them busy work when they can actually jump in contribute to the production. Again, it's a new code base for them, so even if they are good at what they do, they still have that learning curve in addition to the task, no matter how simple it may be. This is a good way to begin to measure how they can work independently as well as in a team environment. A good example of this is how some brilliant people can fall short in a public forum simply due to stage fright, but in a one on one setting they are a force to be reckoned with.
Try a risk reward approach as well. Just like how you would handle an agile process. When they do a good job, unlock the next level of restriction. Basically, you'll need to have your existing team put together a reasonable structure for this such as a dev only access, before they can touch beta or live production; Maybe have them stay on new functional updates, but only the control or model portion so you can see if they are paying attention to the overall code base and how the workflow and design patterns work. Keep the new talent inspired to do well and make sure that you acknowledge the mistakes up front just as much as the successes. Early on, you will learn so much about how a new dev reacts to criticism in your environment and quickly determine if their new contributions are going to be natural or like pulling teeth. It really is about keeping your existing teams expectations reasonable and not putting all the weight of a new hire on the new hire.
Hope this helps. Cheers!
@Lisa Tirskikh It sounds like your question is about something else. What is the risk you're attempting to minimize with your trial period? Let's talk about that instead.
Most people are terrible interviewers, meaning they don't know how to interview people.
I do approve of testing the waters with new employees, but you have to set them up so they can be successful. If you rig the test through neglect, lack of clarity, or some other failing on your part, and then consider the test candidate a failure, that's also bad interviewing.
First, pay your candidates as if they were employees. Give them the same task at the same time (yes, duplication), and usually a task for something you've already solved. Be extremely clear in your own mind what you want to find out. Talk to other employees about how the best way to find out the answers to what you really want to know.
When you commit to an interview, you have in your head already decided that the candidate CAN do the job. The purpose of an interview or a test project, is to determine if the candidate can integrate with a team, solve problems in a way that fits your culture, and to have them demonstrate their thought process more than provide the solution you expected.
I have seen a number of managers who claim a bad fit, when actually they're just bad managers.
No company needs to interview a candidate more than once. When you say interviews, that might be okay to have multiple people talk to the candidate in a series in one appointment. Don't make it a series of appointments. That's bad interviewing. Like I said, no one gets an interview unless you're already convinced they COULD do the job. The interview is your opportunity to detect elements that are not obvious in writing, to determine how consistent the candidate is, and to learn about their thought process.
In hiring a couple hundred people over my lifetime, I can accurately assess whether the candidate is a fit within 10 minutes of meeting them. The rest of our chat is just an opportunity for them to screw up and reveal something they can only hide for those first few minutes that would sour my impression.
I've already set them up to fall out before they get to an interview. Can they follow instructions? Are they responsive to communication? What is their style of communicating? Are they flexible? These tests are easily administered without an interview and take very little time. When they earn the interview, it's very structured what I need to know, though I don't follow a list of questions. Do they ask questions? Do they think the way that I do? Do they look for opportunities? How are they motivated (how do they like to be rewarded)? These things tell me more about the person, which is what I care about more than experience or skill.
I want someone who is effective, not someone with a specific background. It's like with politics. I would rather vote for a politician who can get things done, and then persuade them to share my opinions than to find one who shares my opinions but has no ability to get things done. Your employees are better when you choose them for effectiveness too.
When we know that almost 50% of employees are not engaged, and that 12% are actively sabotaging their employers, it makes you stop and consider how much more successful your business would be if you found the right TYPE of people, and not just people who check-off skills on a list. Remember that "experience" is what you get when you don't get what you want. So I don't ask people about their experience. I ask them things that show how they think.
Your tests of developers should be about how they think and approach solving a problem, not whether they can actually solve a specific programming problem. Do they ask for more information that you've purposely omitted? Do they enlist help? Do they ask for permission? Do they explain why they made a choice that wasn't usual? Do they think about multiple ways to solve the problem or just bang through one path? How do they respond to changes in requirements? How do they take criticism? How injured do they feel when something doesn't go as they hoped? Do they ask questions early or do they wait until they've tried things before asking for input? Do they feel finished or are they curious about what else is revealed by the task they worked on?
These are all things you can learn from a carefully structured pilot project and/or interview.
Hi Lisa, in my experience running software development teams I have noticed that the trial period is critical for all parties. Having a good technical test exercise is necessary. Identify if the work culture fits.