I've worked with a lot of people of varying skill levels, from superstar programmers to not-sure-how-they-got-the-job types. Integrating and working with new people is always a daunting task. For great people it's obviously easier, but we need also to manage junior, inexperienced team members. How we deal with those who struggle is a strong reflection of our personality, and great test of how strong the team will be.
Avoid the write-off
Jill shows up to her first day on Monday. We give her a computer, show the coffee machine, some source code, and then point her at the issue system. She sits there quietly, and then asks, "what's an issue system?" Odd, but okay, we explain it to her, show her some basics. We give her an issue and tell which code she needs to checkout. We come back an hour later and Jill's still struggling to get a basic git command to work. We help her out and then point out a few key Python files. Later in the day we look over her shoulder and see her searching for basic Python syntax.
So goes the first week, or two. What's going on? Does Jill know anything? How did she get hired and put on my team!
There are many reasons why Jill could be struggling. It's best to consider the obvious ones first. It's a new job, that alone is a stressful situation. While some of us switch jobs as often as we switch buses, most people keep their positions for many years. Some are just coming out of school. Taking a new job means a lot of new things in life, not just new work. So let's go easy on Jill and maybe not push so hard at first.
The technology is all different. I've never encountered a company that used the same tools and setup as one of my previous positions. At best I've seen only a one or two tools I used before. We tend to forget how much time we've invested in learning them already. We know that "WirlyCritterz" is the issue system, but how would a new employee? Chances are very little of our system is written down, or the docs are sorely outdated.
We have to avoid letting the stress of all this novelty give us a negative impression of Jill. A few people can jump in and be productive the first day, but my experience shows even great programmers can take weeks to get their footing in a new situation. The more we help the people in this time the better they will view us, and the company. If we don't take the time, we'll have given a very negative impression that can stick with Jill so long as she works with us.
I find it best to completely ignore people's experience at this time. I try to treat every question they have as a valid and insightful question. Sometimes I just don't know their background; I may not have been on the hiring team. Often I'm unaware of what nonsense the recruiter has told them about the company*. Maybe I just need to get used to a new accent. Maybe they I just need to calm their anxiety and think clearly.
*Please, for all recruiters and HR staff, stop lying to candidates about the position and company. It makes it really hard to integrate a new member if the project they start on seems tangent to the one they've been described.
Okay, but what about Tom?
Great, after a few weeks Jill has integrated well and is on the path to being productive. But Tom, who started at the same time, just doesn't seem to be making any progress. He's still struggling with the issue system, seems to screw up git merging all the time, and is producing awful code. He's on the path to disaster.
We have a decision to make at this point. Either we commit to helping Tom, or we fire him right now. If we start ignoring him the problem just gets worse, he gets bitter, and everybody is unhappy. Deciding to fire him now, after just two weeks, is a huge negative reflection of ourselves and the company. I can't imagine the hiring process going so poorly that I'd get a mismatch this bad.
I'm not saying the hiring process can't go completely askew. Total mismatches sometimes happen. But it's generally only after working with somebody closely for a month or so that I can be certain of it.
The difficulty now is figuring out what the problem with Tom really is. As much as possible I'd recommend reducing his workload. Not just his actual workload, but his perceived workload. If we give somebody a list of 100 issues they can feel overwhelmed by that alone. Let's make sure Tom realizes he can safely work on just one issue, and take as long as he needs.
We'll need to give ourselves time to help Tom. When he has questions we need to answer them fully. Being attentive while answering also helps us understand where the communication gap is coming. We can't just throw him some docs either. Let's show him how we'd solve the problem using those docs -- we might discover many issues with the docs themselves this way.
It'll be necessary to review Tom's work as well. Let's not just call it rubbish or tell him to clean it up. We need to give specific constructive feedback on how he can improve the code. Giving the varying quality of programming education, and numerous examples of questionable code online, it should almost be expected that junior programmers write crappy code. If somebody doesn't help them now they'll end up writing crappy code their whole career. Nobody wants that.
Finding out what Tom enjoys is also helpful. Getting upset with Tom for his lack of interest is rarely productive. It would be better to find out what part of the project he feels most comfortable with. As long as we can find something suitable then Tom can become a productive member of the team.
Patience and time
It's a struggle to integrate new employees. We hire people because we're overloaded, thus making it hard to find the time for the new people. Some people require less assistance, and that's great, but others need a lot of help getting on track. We shouldn't be hiring if we're unwilling to spend the time making it work.
It's tempting to assign difficulties on the new hire themselves: a limitation of their ability or their drive. Even if it is, who cares? Not helping the person virtually guarantees failure and then we have to start the hiring cycle again -- something which takes a lot of time. Plus, firing somebody can leave an awful feeling, especially if we're not positive about it.
It's in our best interest be a good mentor and truly help new employees become good team members.
Oldest comments (18)
As someone who has never had a programming job, but is considering the possibility, this post gives me a huge sense of relief. A lot of times, from the outside, it seems like the industry standard is to hit the ground running on Day 1, know what you are doing and what is going on (or fake it with confidence until you do), and make it look easy. Knowing that there are people out there who are willing to help somebody get ramped up and comfortable is a big deal!
You'll learn the hard way that some orgs. do exactly what you are afraid of, and some do things the smart way. If a job stresses the cool tech, the ping pong tables, competitive culture etc., be concerned. Also be concerned if they don't seem to have ANY structure, because those orgs. will bog you down in doing things that nobody else does.
If it's a clear entry level -- or open ended -- job spec, and they clearly hire at all levels or seem to be hiring mostly juniors, then you are likely on the right track.
That said, I don't think anywhere I've worked has expected those coming from bootcamps or fresh out of college to be up and running in hours. It's a known factor, and usually someone is willing to work with you if you show interest in learning.
Yes, you're quite right that it depends a lot on the organization. From my experience it seems that larger companies are better at integrating junior level people. Startups have a problem that they need people up to speed fast. That said, startups often have really great people for mentors, it's just that they might not find much time to do it.
Identifying the companies that are able to help their employees in the ways this article suggests, is an important skill. In that section of the interview where they ask if you've got any questions, arm yourself with a probing set of questions about how they support their employees. Such as:
Some employers don't have the answers and depending on your situation or expectations this isn't necessarily a bad thing. But just be aware of what you're getting into. Not all companies can afford (or believe they can't afford) to support staff as thoroughly as they'd like and not all will willingly admit to this.
A lot of requirements I have seen say "Must fit in our fast-paced environment" , "Must be aggressive and ready to hit the ground running". I love this post because the industry has forgotten that they are hiring human beings. Very hire is different. I personally am willing to learn and grow. I guess my previous boss never cared and was quick to let me go.
Those are warning signs even for experienced developers. But in fairness, they often aren't written by the team, but by some idiot in HR that's trying to make the company sound impressive.
I've worked in "fast paced" companies before and we've had new hires. You can still be a good mentor, but there is an expectation that the new people are extremely self-motivated, and will be expected to basically work overtime catching up. There's nothing wrong with this if the people know what they are getting into.
All of this. Part of what makes someone "senior" is how much time they spend reviewing other people's code, mentoring, etc. The whole cowboy coder thing was a painful stereotype, and never worked in any real organization when it was considered cool, which was a long time ago.
I work at a consulting company now, and one of the best things we've done is institutionalize this process. At a minimum, most people are given someone to guild them through the first week or so as a new hire, whether they are sent directly to a client site or sitting on the bench for a bit. If you want to spend some time outside work, there's user groups for everything, and some night classes in how to fit in at the company, how to be a consultant, etc.
The new one is they're now starting bootcamps during the daytime for all the specialties that have either hired a lot of new folks recently, or have people coming in from other specialties (i.e. developers moving to data projects). This is the crash course in devops, how to use Git, etc. as well as basics of our default way of doing things (some clients have an idea of the tech they want), best practices, etc. You get to meet everyone, and it sets a baseline for all new hires, as well as identifies who is weaker and stronger in what, so we can train accordingly.
As someone who's fostered and helped a lot of junior folks, I wish more places did this to cut down on the shaming people who ramp up slowly or bad work caused by those to ramp up quickly in the wrong direction. As someone who used to be junior, and doesn't change jobs often -- which also leads to being a couple years behind in tech. at times -- I wish orgs would do this for all the reasons mentioned in the original post.
I'm surprised that your company does all that. It sounds great. Actual training during the day for new hires, like on actual company time, and in relevant skills. I'd imagine with job postings like that you don't have a hard time finding people.
I've seen cowboy coding work, but it really requires a few people with some pretty decent skill levels, well, and management skills -- essentially they end up planning internally, so I guess not really true "cowboy coding". It doesn't necessarily mean they can't mentor either, but as a junior person I simply wouldn't recommend joining such a team. Even if you have great people, the pace can be crushing, that overwhelming feeling can be extremely stressful.
I work for a really people-forward company, and they also just don't want consultants showing up on site not knowing the basics of what we're selling as the better solution (we do a lot of legacy upgrades, turning projects agile, etc.). The boot camps are new, but yeah, they do all that. Down side is that it's harder to get "ahead" in that they are picky in hiring to begin with, and then the really hyper-learner and volunteer types just plow through extracurricular activities as opposed to those of us with life commitments.
The flip side is, that "ahead" means more of a management of people/projects/technology leadership stance, and you can do just fine as a higher level worker bee for as long as you'd like without getting the boot.
Anyway, what you describe is a very functional team, and those do work, but agreed they're not great for junior folks. My biggest concern with those sorts of teams is that even when they work well, they often accrue technical debt and make a great product in a short period that is harder to maintain down the line after the innovators do their job and leave. That, or the pace dies at some point if they don't deliver quickly, and you lose people. Again, all bad things if you're a junior.
Good teams for juniors are ones focused on a mix of maintenance and either new products or major new features. You learn what works and doesn't, have people who are knowledgeable to mentor you (as your original piece notes very well) and have time, and get a chance to pick your style and interests.
Love this article. We recently hired someone new, and yes, making the time to help where we can is sometimes difficult, but we have seen him grow a lot in just a couple of weeks thanks to the whole team always willing to assist.
I am not old enough for a job, but I have a friend who constantly ask me questions about the most basic things. He doesn't understand the programming logic and he keeps asking similar questions. He also barely browses the docs himself. The problem is that if I'm nice, he'll come back for more...
Part of the challenge of being a mentor is teaching people how to do things on their own. This often means watching them stumble through simple things on their own, only pointing out a minimal amount to keep them making progress. You don't solve all the problems for the student, you're supposed to help them figure out how to solve it on their own.
Will do, thanks!
Great post. I personally had the chance to have a very helpful colleague when I started out. Everything was so overwhelming, I felt so out of place for a few weeks. He was very patient and explained a lot of things to me and took the time to answer every question I had ( and still does ). Without someone like that, things would have been a LOT more complicated.
Don't be a dickhead.
I feel like my team made a wonderful job at onboarding me. I could use github, not git. React, git, macosX, company tools and test tools, webpack... A+ team. And i was remote and on a different timezone.
Remote mentoring can often be quite a challenge. A lot of the small interactions are missing, and it's hard to just glance at the code and help with small things.
It is not about Tom or Jill, it is about the company/dept involvement and planning. Seems like the recruitment really went askew in this example. I mean, if you cannot afford their failing time, bad git merges and the poor quality time once the guys are onboard, then it means you should have invested more time in filtering them out beforehand. If you can - then be consequent - plan the onboarding process better. Make a small workshop for them, have two persons (one senior and one junior) spend time to patiently pass knowledge to them, try to make Tom and Jill help each other as they learn, accent to the team their first good contribution, even if it has cost humongous amount of help from your side. I have seen many onboardings and have been onboarded a couple of times. From what I can tell it's mostly the organization fault when something goes south.
Recruitment will go wrong sometimes, there's no guaranteed way to prevent that. As companies get larger the chance of getting somebody on the team, with whom's interview you weren't involved, gets higher. Sometimes you just have to make the best of these bad situations.
I'm not saying you shouldn't try to fix the hiring problem, just that if something goes wrong try to fix it as much as possible with onboarding, via mentoring.