The unstated counter-argument is that the employer will have to train inexperienced workers who will leave as soos as they become competent and experienced, or pay as much as you would for the experienced person in the first place.
Myself, I'd rather train someone up in my process without them learning bad habits, even if that means they're pairing with me for 30 hours out of 40. That said, I'm an exception.
Once upon a time, some companies hired new workers as QA, trained as QA, and those with the aptitude were moved into programming. I know that IBM still has an internship program that streams people into their system.
That's a good point. The question is, is the return from training up someone worth it? Do they spend more time at the company than someone hired in with more experience? Do they get the company more in income than they cost in training?
The cost is in the near future and fixed, whereas the benefit is in the future. Which is why a company can't answer those questions, and often goes with the safe route and tries to poach or hire a senior person (which, honestly, is just a junior person who has made mistakes and learned on someone else's dime).
However that has its own risks because it's not like interviews are cost free.
I just think there's a tremendous market flaw that someone is going to take advantage of by finding talented entry level folks and hiring them for less and then making money somehow. That or eventually entry level folks will leave the profession of software development.
I disagree with your statement but agree with your point.
I believe that's due to being curious and slightly introverted when young, so these people just have lots and lots of experience. Such people could be manufactured by training them on many different programming disciplines over many years. It's just that for almost any company, investing so much into training is not feasible. That employee might leave once training is over.
You're trying very hard to dismiss experience specific to a company and industry, but I'm not buying it. Someone who has intimate experience with an established code-base and the company will be vastly more proficient than a new employee of similar intellectual capability. It's why companies often try to hire people within similar industries and tech stacks to help reduce this gap.
It's like trying to argue that a mechanic who has only worked on Ford vehicles for 20 years should be able to quickly have the same proficiency as a mechanic who has 20 years of experience on only Porches. Nonsense.
Remember, a company can typically expect to hold onto a developer for maybe 3-5 years, so even half a year of training is a significant portion of their tenure.
I can certainly see where you are coming from. As you stated, it is a chicken and egg problem somewhat.
However, if the person has no background whatsoever that's actually different than someone who has some verifiable experience but just isn't what you would like initially.
Wouldn't it make sense to take in someone who has some experience then train them. Sure they may leave but they may not if you treat them well. An employee leaving in the tech world is always a risk. I notice many companies spend all of their efforts hiring but very little effort is exerted to retain people.
At the end of the day the tech world could stand to give back to the community in some way. If it means taking on a bit more hiring risk, its a small service to the communities they've taken so much from.
Especially unless they want to pay for it. Most experienced people already have all the jobs they need. No one else is going to train your employees for you. You don't want to pay the premium? Hire on potential and award those that do well. I don't know how many of my friends in these kinds of roles had their pay stagnate while the company were hiring e.g. consultant. Eventually they leave and things gets even worse for the company when the new project fails, because now they don't have either old or new infrastructure working properly.
- Some companies hire a smaller amount of experienced people who really know what they're doing, know what they're worth, and compensates them appropriately.
- Other companies hire a larger amount of bright, motivated young people that don't know how to do anything, trains them up quickly, then tries to milk them for 1-3 years until they smarten up enough to leave.
I don't think it's as exploitive as it sounds. The young people get a slingshot early in their career and a good bullet point on their resume, and they're free to leave whenever they want. And most do leave in due time to do bigger and better things.
Not that I disagree with you, but sadly, most companies don't seem to want to train people anymore. They rather push that responsibility to either universities or the applicants themselves.
In fairness, I do think that someone who is very comfortable with a language or framework will be able to do things much faster than someone who isn't. Considering how quickly people change jobs nowadays, I can also see how companies don't want to train people only so they will leave shortly after or even before they're useful.
Obviously this is just based on my own experience in the US.
As an employer, I'd be willing to take a chance on a new employee without experience if he/she could demonstrate some aptitude and some effort to learn independently. I got my first software job with no formal training this way. I spent several months studying Java on my own and did well enough on an interview test to persuade the company to give me a shot at a low salary.
However, I don't think I'd be interesting in bringing somebody up from absolutely nothing. It's just too big a risk and an investment. I think the fundamental problem is that the American public education system just isn't training people in the skills they need to succeed in a modern economy.
>>, many employers would rather hire a couple of inexperienced computer programmer and spend a few months training them [...] In addition, many employers aren’t interested in providing training to engineers or programmers
>That directly contradicts the preceding paragraph,
The "many employers" can be 2 different subsets of employers and/or 2 different tech stack situations. Examples...
Subset (1) FAANG or "tech" companies will train on specific in-house technology stacks for younger new hires. The "inexperienced" was in referencing "young". E.g. Apple hires fresh young college graduates that only did Scheme and Python in school but will train them on Objective-C and Swift so they can work on macOS and iOS. However, Apple typically doesn't hire older experienced COBOL programmers to re-train them in Swift.
Subset (2) companies that don't train new hires (many non-tech companies where IT/dev is a cost center). They usually don't recruit from college campuses and prefer the job candidates to have existing skills that already match the job listing. E.g. a hospital IT's department has a job listing for a Java programmer to help maintain their billing system. The hospital is not interested in a candidate who's skillset is only Turbo Pascal and Macromedia ColdFusion and retraining them on Java.
I'll just throw this out here: for IT you almost don't want your in-house trained people to stay very long because it's pretty important less experienced people to get a variety of different experiences. I would say that people who stick to their first job for a decade or so tend to become under performers and I don't think it's generally because they can't find another job. Breadth of experience is really valuable in this field.
I've often thought it would be amazing if you could do the equivalent of professional football (soccer) lending of players. Lend a developer to another company for a few years with the expectation that they will come back. If they decide to stay then the borrowing company give some compensation. But it would mean having very strict contracts that limit the freedom of workers, so it's almost certainly a no go. I wish there was a way to make it work, though...
While this might sound like a good question on the surface, it does not get to the "root" of the problem. Let me explain ...
Yes, most companies prefer to hire people who already have the skills & experience rather than train "junior". This is not because companies don't want to develop the skills of their employees; it's simple economics. The biggest bottleneck in any company is experienced people. The senior engineers who already understand all the systems, have been to all the product meetings and solved many critical bugs in production.
These people are the "goose that lays the golden egg". Most companies are looking for more of these "golden geese" who can be effective & contribute to the product immediately because the "ROI" on these people is 10x (or more!).
Training someone up from scratch in a key tech and all the companies systems usually has a negative "ROI" for the first 1-6 months and distracts senior people so it's a "lose-lose" in the short-run! Add to the fact that most companies have a "LIFO" pattern with hiring (the most recent hires are usually the people who exist first!), and many hiring managers (HR) are put off by the idea of hiring people who do not already have the required skills.
Consider the following often repeated quote/saying:
CFO: What happens if we train them and they leave?
CEO: What happens if we don’t and they stay?
A lot of people have the mindset that training people costs too much time, money & effort and it distracts the key people in the company away from their focus (building the product).
This is not the fault of the company or the people working there. It's a "systems problem"; most companies simply don't have an effective system for "on-boarding & training" new people.
I've worked for several companies over the past 20 years (including starting my own twice) and have been responsible for hiring & training thousands of people.
Training people in tech skills, company culture & workflow simultaneously is a "hard problem". If you can get a "head start" on at least one of these areas the chance of successfully integrating someone is much higher. HR people know this so they want to "check" as many of the skills boxes as possible up-front. You as the "junior dev" can use this information to your advantage and invest a few hours up-front to demonstrate the necessary skills and make the HR/hiring manager's job much easier!
My advice to any "junior" person reading this:
1. Focus on your own learning/skills for at least an hour every day (preferably first thing in the morning).
2. Share your learning somewhere public e.g: GitHub or a Blog. that way the hiring manager reviewing your "CV" has a clear indication that you are "fast learner" and a "team player" who shares what they learn to help others "level up".
3. Pick the skill/tech/tool that is most valuable in your chosen industry/sector or even target it to a specific company you want to work for. e.g: if you know that AirBnB uses React.js https://stackshare.io/airbnb/airbnb you find and devour all the best tutorials for learning React.
4. Consolidate your learning into a tutorial of your own to show that you have understood the tech/tool.
5. Link to it directly from your CV/LinkedIn.
Seriously, this will take you 20h at most. You could get it done in a week and it will transform your "hireability" from "no thanks" to "when can you start?".
I know this because I have used this strategy to get jobs & contract work in the past to excellent effect. Investing in your skills and sharing your knowledge is the single best time-investment you can make. It's a 1000x ROI! Put in 20h of focussed effort and you will get an extra $200K in the next 2-5 years. Guaranteed.
My advice to any company wanting to solve the "problem" of hiring "junior" people and making them effective as fast as possible is:
1. Commit to becoming a "learning organisation" where everyone in the company shares as much of what they learn as possible.
2. Establish metrics for learning in your company! "What gets measured gets done". If there is no actively tracked & visible metric for each person's learning, people will stagnate and default to using their existing "hammer". https://en.wikipedia.org/wiki/Law_of_the_instrument what you want is people who are proactively learning new skills/tech/tools and then bring those skills into the company to improve effectiveness or build features that your current tech does not allow!
3. Systematically share anything that is not "sensitive" or "secret sauce" in public. Having private wikis with lots of learning is fine for internal use, but what if people could learn your "stack" before they join your company/team?
4. Hire the people who proactively contribute to the learning materials without being prompted. This is the mindset you are looking for: people who want to learn and share what they know regardless of getting paid.
Anyone looking for a proven example of any of this, see: https://github.com/dwyl?q=learn dwyl is a bootstrapped, profitable Open Source software company that shares all of it's learning in public. [disclaimer: I co-founded it!]
Sure, but if you want to hire someone with nonzero industry experience, your options are more limited :) this is what I mean when I say companies will have to lower their standards - inexperienced people into experienced-person positions, people who've been coding since they were 18 instead of people who've been coding since they were 10, people without university degrees instead of with them, and so on.
No amount of demand can create people with two years of experience in less than two years, or people with four-year degrees in less than four years.
That’s totally fair (and there indeed was a time when the typical response to my resume was, "we are not looking for juniors") :-)
But this argument makes sense only from the collective standpoint (as in, the industry in general). Of course developers have to be trained by someone, because otherwise there will be no dissemination of knowledge, no passing down of experience, and no qualified workforce. So of course that should be done.
The question is, whether you (as a programmer on a team looking for new members, or as a company looking for new employers) need to be doing this, or whether it's all right to let someone else do this while you look for already well-trained and experienced professionals.
I understand there are some difficulties with this ideology in terms of technology companies and onboarding, but I have also seen the potential benefits of such an approach without explicitly attempting to engage it.
We have hired entry-level engineers that went from supporting basic production issues to writing low-level parts of the platform within 2-3 years. At no point was I consciously aware of any explicit knowledge transfer occurring, but somehow these individuals are able to pick up a tremendous amount of capability via proximity to the day-to-day process. One day it clicked for me that a pull request I was reviewing for one of these individuals was something that I would expect to see from a highly-skilled developer on the team. Seemingly overnight, we converted a QA/Support engineer who chases down basic null refs into a proper developer, and all it required was exposing them to the full depth of the process every day.
Perhaps the master/apprentice game doesn't make sense in terms of on-boarding. But, I see massive amounts of value in exposing willing employees to increasingly-difficult problems on a daily basis. Make your most junior employee install the same tools and work through the same processes that your most senior employees do. There is no reason you cannot ramp someone from zero to hero in a few years with passive exposure to your business processes.
I find that this model of constant exposure combined with probationary employment strategies provides an excellent blended approach for ramping in new talent that would otherwise be filtered out by your typical big corp HR department. Just because someone doesn't have a computer science degree or got burned by our incredibly shitty legal system doesn't mean they aren't willing to bust their ass and try to prove something to the world. I would like to give as many people a chance as possible at this. Programming is an art and no one policy is going to be the best. The more perspectives we have the better.
I think with a certain definition of training the argument works, but it's not clear if this is actually the definition they had in mind.
If you have the choice between hiring two people for an engineering position, one of whom can write code and one who can't, you'll probably want to pick the one who can rather than training up the one who can't. If your hiring efforts are lackluster, perhaps you can only attract the latter category of people, so you spend a lot on training people to simply do the jobs they're hired for. It's a bit like the Silicon Valley "senior engineers are impossible to find" argument right now. Nobody wants to take the burden of training a junior engineer into a senior engineer if they can hire someone who's already made their mistakes somewhere else. (Not a mindset I particularly agree with, since it implies a failure-intolerant atmosphere, but you get the gist.)
On the flip side, once someone is in a position that they are qualified to do, training for growth and development is a must-have -- 31 hours seems low to me. I definitely spent more than that in learning/development programs at Google, and I don't think that culturally they have an anti-training mindset, but I could be being too generous -- the quote on the site certainly reads exactly like your interpretation.
I don't think this matters in big software nearly as much as in other fields. Every new hire needs to be trained up - even the most experienced are going to require at least a few months before they are useful to the company.
When I started at IBM in 1990 you could get your foot in the door with basic experience, i.e. a college degree could get you an entry level role in a software lab (you’d need a CS degree to get a programming role in such a lab). I worked with people who'd started fresh out of high school and had worked their way up, with IBM providing training in various fields.
By the time I left in 2001, on the job training was very much in the past, and new hires were expected to have all of the skills from day one. So, it's not new, but it’s not how things were until the last twenty years or so (excluding Silicon Valley which always seemed to have higher expectations for lower skilled roles).
I think that being unwilling to train entry level employees might also be a factor? I.e. someone with a CS degree has demonstrated that they probably have the aptitude for programming; however, they may or may not already be good at programming.
Ideally, entry level positions would hire for potential with the expectation that they will be training their employees.
I agree with this. Most companies don't want to spend the time and money training a candidate. This doesn't apply just to new college grads but to more experienced candidates trying to find work where newer technologies are used. Someone who is a very good C programmer will never be hired as a Ruby on Rails developer though they could probably learn RoR in 6 months. This person is stuck finding C jobs or ends up getting forced out of the market. The reason why companies don't want to provide training is because they don't have anyone to provide that training. In the good old days, a senior engineer would take the time to teach a new hire the code base, best practices in a language and the tools involved which'd help the new hire ramp up fast. With the whole 'agile' process, everyone is focused on completing their sprints and training your co-worker gets penalized. Some blame must be placed on experienced engineers who coast along in a Big Co till that company starts going under or starts layoffs. Suddenly they realize that they don't have any skills that the market needs.
Myself, I'd rather train someone up in my process without them learning bad habits, even if that means they're pairing with me for 30 hours out of 40. That said, I'm an exception.
Once upon a time, some companies hired new workers as QA, trained as QA, and those with the aptitude were moved into programming. I know that IBM still has an internship program that streams people into their system.
reply