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 work...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
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.
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.
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.