Ask HN: Why not more hiring of junior devs, then on-the-job-training? - <AUTHOR> Hi, all. Long time, first time. Hoping to tap into the collective HN consciousness to help make sense of this question, as I feel it's something I'm seeing/experiencing at present.
It seems like twice a week or more I read there is an industry shortage of devs, but I never hear about any companies, of any size, looking for junior devs -- or generally competent devs that might have a specific knowledge gap -- to hire and give on-the-job training to. Not even a contract-to-hire situation that leaves the company with very little risk if the developer isn't what they needed.
Is on-the-job training just flat-out dead?
I ask this because I'm 4-years-experienced as a front-end UI/interaction dev, nothing but glowing references, looking for another, similar, position (regular, not senior or lead) and have had...way too many interviews and rejections, and can't understand why companies are such sticklers for interested devs to have Every Single Box in their list of requirements checked when it would take days or a couple weeks to learn XYZ framework/library/whatever to the level of competence that is required for the position.
To further stack up the frustration, it's not uncommon to see the same position listed and re-listed on LinkedIn and Indeed for months: certainly somebody could have been hired and trained to the level needed in that time. (Maybe even me!) <comment> oh-kumudo I think the reason is simple: once the junior dev is trained, they will leave. To be clear, I am not saying that they are obliged to stay in the company that trained them or being ungrateful in any sense, I am simply implying this is a common outcome from such training.

In software industry, the first job switch in 2 years seems pretty common and reasonable, and the dev by that time would be able to strike a better job offer not only for money but also better aligned with their self-interests.

From the companies' perspective, they might find such high attribution rate stays against their own favor, making providing necessary training uneconomical for them, both in time and money.

<comment><USER5> A friend of mine runs a web dev shop and I have seen him train at least six people from zero-to-pro (very smart, fast learners with a math background) and what you described is exactly what happens. Once they become medium/advanced- level proficient they often quit and move on to other, bigger companies.

If there was some formal, or informal understanding that candidates "trained on the job" would stay for a few years, I think companies would be more open to building junior devs.

Does anyone have ideas about how to make this work?

<comment><USER6> The other replies touch on this, but I'm gonna get straight to the point:

Does your friend give them actual, meaningful raises as they grow? Is he actually paying competitively to begin with?

Because I think if you have this pattern that consistently, it's really likely that either you're underpaying to begin with or your raises suck or are not even present.

I love working at small companies. It's by far my preference. But none of the small companies I've ever worked at offered anything like the comp and comp growth that the big corp I currently work at does. In fact, almost all of them offered me near zero compensation growth over time. And in real dollars that effectively means negative growth.

<comment><USER5> That's the weird thing — they (because there are two cofounders) were actually paying very competitive salaries (for the local market). I was impressed to hear what some of them were making. So it's not the money.

I think what's going on is that after a year at any job you start to see the problems with the code base, and it starts to get repetitive. It will be like that both in big-co and small-co, but in a different way. In small-co you can have a much more freedom, but you reach a plateau of the new things you can learn. In big-co there are bigger problems and more challenges, but you're part of a soulless machine that just wants you to do your job and not ask questions.

Not having experience the soul-crushing big-co life, the brough-up-to-speed junior hires don't appreciate the deal they have, and want to explore their options. It's a rational decision, and come to think of it I'd probably do the same. The code is always greener on the other side... Who wants to be like "no I'll stay here and do 3 years of the same things that I'm really good at now and delivering value for my employer."

From the employers's perspective though was it worth it? Time/energy invested to train them vs. maybe 6mo or 1 year of useful coding contributions.

<comment><USER6> > That's the weird thing — they (because there are two cofounders) were > actually paying very competitive salaries (for the local market). I was > impressed to hear what some of them were making. So it's not the money.

This is only half of what I asked. What about the raises? As someone in another thread chain pointed out, the expected raise from job leaping is maybe 15%. How did the raises your friend gave compare to that?

I'm not saying they have to meet it, but if you're sitting there doling out 1-2% raises per year people are gonna leave when they get what they need from you.

Also, small companies (frankly, especially 'web' companies) are not even remotely immune to demanding people just "do their job and not ask questions" or forcing their employees to sit in the same box for 3 years doing the same thing. Often the lack of room for career growth in perpetually small companies almost _demands_ this.

<comment><USER7> In fact in the good big companies, they crave for employee growth. Time and money for training, meaningful career growth, and pay growth, major tech switches without changing jobs.

I find that small companies are often much worse in all these metrics. As a jr employee they'll never rise to chief architect - your friend, the cofounder, has that job. And is never giving it up. Plus thanks to cash crunch, making shortcuts to deliver is common in small companies. Especially since they don't have a reputation to protect. So quality? Well, maybe.

I recently took 9 weeks off from my bigco FAANG, job to help raise my baby. After the company's health plan was on the hook for a million in costs (baby born prematurely, spent 3 months in hospital nicu). At no point was I worried about my job or company. I'm happily back on the team in my job cranking away and being productive.

Now tell me my experience would be better in a 12 person startup/shop. I dare you.

Ps: in terms of impact, well I work on a small thing in a sense so only a few million people directly use my product. Big companies have big impact. Lots of guard rails which is nice to no longer make the same basic mistakes over and over.

<comment><USER8> > the company's health plan was on the hook for a million in costs

As usual, this is the craziest part of the comment to my European mind. Your healthcare system spent somewhere around an entire lifetime of effort for something that, while relatively dramatic, should still be quite routine for a sophisticated medical organization!

<comment><USER9> Which begs the question: what happens if the premature baby is born to a US family that can't afford a decent insurance plan? Does the hospital repo the baby? Is the family bankrupt and the baby's life ruined from the get go just for being born premature? I can't wrap my head around it, and it seems to suck either way.

<comment><USER10> The parents are on the hook to the hospital, to the myriad physicians involved in the in-hospital care, and for non-covered post-discharge costs. Their financial lives may be crushed absent bankruptcy, which carries its own problems regarding loss of assets and mortgage availability for ex.

The infant is also financially liable but likely uncollectable. The baby's life may or may not be ruined depending on where the US goes w/r/t health insurance coverage for pre existing conditions.

<comment><USER11> How is the infant financially liable?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I've built a team from trained-up junior devs, and it was great, I would recommend this route for anyone building a team.

BUT... you have to have people who can train and teach as well as code. There are personality traits that don't align with this. The typical "aspy Dave" stereotype of a rockstar programmer is not good at this.

So you have to align the entire team from day 1 as being a training environment as well as a software excellence environment. It's not easy to do. We lost a few people because of it.

However, the loyalty generated was incredible. We tended not to lose people because they knew they could learn more with us than they could elsewhere. Our retention was fantastic, despite the overwhelming opinion than new trainees leave as soon as they can get better salaries elsewhere.

But then, we hired for people who were hungry to learn and create. Less graduate programmers thinking they knew it all, more college dropouts who loved coding but couldn't stand academia. The best coder I trained on this team (in fact, the best coder I trained ever) was a girl who taught herself coding while getting off heroin in a Glasgow slum. I doubt any "normal" dev shop would have even interviewed her, but she was really good.

Oh, and we were too small to have an HR department. When we grew big enough, they definitely got in the way. I had to more or less fight them off over every position we hired for, because they didn't understand anything about coding, IT or creativity, and would just look for relevant experience in a similar field.

<comment><USER13> _I had to more or less fight them off over every position we hired for, because they didn 't understand anything about coding, IT or creativity, and would just look for relevant experience in a similar field._

I'm a dev coach, which means I can run circles around my client's developers (except usually one or two). However if I ever wanted to get hired as an actual employee at any of my clients I couldn't. I'm a high school drop out with a weird work history. There's no way I could get through HR.

The absurdity of this has not worn off.

<comment><USER14> HR is the "no one ever gets fired for buying IBM" of hiring. Not really good, but minimizes risks for all involved.

<comment><USER13> Minimizes the risk of hiring great people.

</comment></comment></comment></comment><comment><USER15> >I ask this because I'm 4-years-experienced as a front-end UI/interaction dev, nothing but glowing references, looking for another, similar, position (regular, not senior or lead) and have had...way too many interviews and rejections, and can't understand why companies are such sticklers for interested devs to have Every Single Box in their list of requirements checked when it would take days or a couple weeks to learn XYZ framework/library/whatever to the level of competence that is required for the position.

I've found myself in the exact same situation lately. It seems companies are not actually _hiring_ for people to do a job, but simply trolling the market for who they can find. The result is wasting weeks of your life being strung along through their "process", only to be given a form letter rejection.

I quit my job at the time after months of these nonstop recruiter emails enticing me, and wasted 2 months going through this ruse with a couple companies, only to be left with a feeling of total defeat and a Bay Area rent payment eating me alive. To anyone considering doing the same, think twice. It's pretty maddening not even being able to land an in-person interview with 4 years experience.

<comment><USER16> Don't quit your job without your next source of income secured.

<comment><USER15> >Don't quit your job without your next source of income secured.

I guess this is the takeaway from a self preservation standpoint, but the alternative is worse. Spending months of your employer's time completely mentally checked out, taking sick time and vacation for interviews, pretending like you care in meetings, it's all too much. I watched that happen multiple times before I left, and it's really discourteous to the people you work with. It just seems unethical to me to remain somewhere once you've decided to leave.

<comment><USER17> When you quit, you lose leverage. It's not unethical to use personal and vacation days as you see fit.

<comment><USER18> They are your days to use, however you feel like. Hell, you really should be entitled to use your lunch hour if you want, but that might be my blue-collar roots in jobs where I actually clocked out for lunch and had mandated 9am and 3pm breaks showing through...

</comment></comment></comment></comment></comment><comment><USER19> I'm an Engineering Manager at Cloudflare, and we hire juniors.

But... this was not a thing we always did. For a long while the company was much smaller and we had a limited number of roles open and so we focused on fewer hands that could get more done as each team might only be a couple of people (for example the engineers behind Cloudflare DNS could be counted on a single hand) meaning we hired mostly senior whilst a few juniors were hired where the skills matched well.

As we've grown we've reached the place that to offer progression and growth to our senior engineers into engineering leadership or management means that we acknowledge that you may be a great engineer today but you now need to learn and master communication skills.

We are hiring juniors to give our senior engineers growth opportunities as we need engineers who can be mentored, taught, shown how things work, who will ask questions that challenge the seniors to explain why they've done something the way they have and what considerations were applied.

What I love about where we are now is that this encourages us to hire the most curious, smart, and kind individuals who will benefit the most from that communication. We are now well-placed to grant potentially career shaping and life changing opportunities and to give juniors access to some of the great senior engineers we've been attracting. It's a total win-win.

And having seen this play out, and reflecting on the smaller places I've worked which lacked juniors, and the larger places that had a healthy balance of juniors, and being at Cloudflare long enough to have witnessed this change... I'd say that if you are a junior engineer, consider applying to growing mid-size organisations (250-2,500 employees) as those are the ones that are likely to be under similar needs to fill gaps in a way that helps support the growth and development of their existing engineers as well as their new ones.

<comment><USER20> Glad to hear this from Cloudflare

> encourages us to hire the most curious, smart, and kind individuals This is > important. Having hired developers with a range of experiences I've found > that it's often the more junior developers who push new ideas, create > discussion and raise the team morale IF you hire those juniors who are most > enthusiastic and hungry for growth. It's similar for hiring senior roles but > seems even more important when hiring juniors.

</comment></comment><comment><USER21> There's either a cost _or_ benefit of everyone on the team. Programmers generally push the code at a constant velocity in one trajectory between the two.

They'll be somewhere between fixing things and making it better to breaking things and creating new problems that eventually need to be undone and re- solved, pushing the quality down and deadlines back.

People tending towards the second group are a waste of time and money. As a hiring manager, to be completely brutal, unless they can demonstrate they are in or have high potential to be near the first group, I simply do not care.

The contribution value of people in the second group is not zero, it's actually negative. Their bad decisions and buggy creations decrease the quality of the product. It's like putting an saboteur on the payroll and then handing them important responsibilities. The team likely becomes friends with them (friendships at work happen about 10 times for every 1 enemy) and this makes reversing the mistake even harder because after all, we are social creatures at heart.

What's worse, after the inevitable breakup, I then have to re-allocate my quality assets away from pushing the product forward to cleaning up the mess someone just left and things stop getting done in the meantime.

<comment><USER22> I think this is the right answer, though I think there's a mentoring element that has to be considered. Plenty of people will break things if left unsupervised but will learn quickly to contribute if they get the right feedback.

<comment><USER21> That's fine if you have the cash to burn and people to squander. Larger firms probably do (after all some have daily banquets and onsite gyms), but it is just burning cash and squandering time.

If you're on a tight budget like I usually am, I let someone else do that investment. I simply don't have the resources. Early stage startups are the most enjoyable nightmares I've had.

</comment></comment></comment><comment><USER23> This might be an unpopular opinion, but I would expect that each newly hired developer (be it junior, mid-level, senior) can and will take time to do train and improve him/herself. I don't mind this being on job time, as long it is not all day. Most times this is even required when doing a task, because no one knows everything, even with X+ years of experience. If this mindset is not there and a newly hired developer requires actual training (like someone else in the company teaching them), then I think he/she will never make a good developer in the first place, because each new task with some obstacle they have never dealt with, will require them to get training from someone else.

I am a big fan of mentoring, but this is related to understanding the existing platform and getting productive working on it, not about teaching technology XYZ.

This opinion should actually go both ways and companies need to be willing to hire developers, even they don't have the 100% exact skills they need and then allow them to improve them on the job. If you got rejected by companies because they don't understand this, then be glad that you will not work for them.

<comment><USER24> Absolutely agreed. What's implicit here is the risk that somebody just won't work out. I once invested a huge amount of effort trying to train a junior dev and after 3 months he still didn't "get it". Not only was he unproductive but I was basically operating at half capacity for those three months. It was a huge exercise in frustration and something I will never attempt again.

<comment><USER25> I am sure that was very frustrating! Did you end up letting him go? It sounds loke the job wasn't a fit for his skillsets.

I will say that I have hired junior folks and seen them thrive after three months (take on more work with more autonomy) and that leveling up was so great to see. Plus it made them a better developer and more effective foe the company.

That's the flip side.

And it's not like a senior developer is a sure bet to be effective either (though I grant you they are, all things considered, a better bet).

</comment></comment></comment><comment><USER26> One of the reasons that I saw, is that training is very expensive for the company (both in terms of money, opportunity cost, time of other people, etc) which combined with people changing jobs often produces low, or negative ROI. By the time person is trained, they leave, before they start to meaningfully contribute. More experienced folks also change jobs often, but you have higher chance of getting some productive time out of them before they move.

<comment><USER27> In my opinion everyone company likes to only benefit from experiences earned elsewhere but never like to provide folks a place to earn the same in their company. This is very unfortunate, I also see the same issue when someone is trying to even make lateral movement from one expertise to another. (Like backend to front end.) This whole process is a very lazy and unproductive way to hire. I have been thinking about an alternate approach. Where folks spend their own time to learn and build something in the common forum along in a team. Teammates can rate them, code can be available in open repo. That way folks can prove their skill outside their job and job interviews. Like I proved that I can build mobile app once and anyone can recruit me instead of starting from clean slate job interviews every single time.

<comment><USER28> > In my opinion everyone company likes to only benefit from experiences earned > elsewhere but never like to provide folks a place to earn the same in their > company

^ this, can't agree enough.

</comment></comment></comment><comment><USER29> I owe my career to on the job training. My first programming job was at a small shop in New Jersey. Their interview had me write a loop, not even fizzbuzz. They asked if I knew JavaScript, Ruby, css, HTML, or SQL, I said no for all of them. They hired me ("at least you haven't learned bad habits") taught me rails, git and about as much about software development as I learned finishing college. I took the job summer after freshman year and worked every summer till after junior year when I interned at Amazon.

Showing up at Amazon felt like starting over again, I had so much to learn.

I think those experiences formed my attitude, I spend a lot of time learning new things at work, because I've always learned at work.

I think I'm good at my job, I just got promoted to senior engineer, and I attribute it all to my first job being willing teaching me.

<comment><USER30> Me too. I was a know-nothing kid from off the street with a newly minted economics degree. And I learned SQL as a Junior DBA and now I'm a Senior Python developer at a startup in Germany. Tutoring from senior level coworkers and home study is how I got to where I'm at. I try to give back where I can too!

<comment><USER31> Curious - are you in Germany on a visa?

<comment><USER30> I have a residency permit aka a Bleue Karte - which is tied to my employer. I have to maintain a job and it has to pay above 50k euros but it's good for 5 years.

<comment><USER32> I don't think German Blue Cards are tied to a specific employer. As far as I know you only have to let the authority know if you change jobs less than a year after getting the card, and beyond that you just need to make above the money limit and you can work anywhere.

<comment><USER30> I had to when I changed jobs change it into the name of my new employer. But that was probably because I changed jobs before a year.

</comment></comment></comment></comment></comment></comment><comment><USER33> Non-developer here but I might have some insight on general hiring practices: First of all, most companies, startups especially, are really bad at training. Like, really really bad. A majority don't have any kind of formal training programs until they hit 100+ employees, and even then the training you get is usually created by HR and lacks any kind of technical depth. It's hard enough to even wrap your head around the basics of how most tech companies are built as an early employee; trying to turn that complexity into a simple training program for new hires is hard and people rarely have the time or resources to do it well.

That being said, if a company is preparing for growth they need to plan and document for those trainings ahead of time, and they're probably better off hiring fast and teaching quickly on the job. Not documenting how your company works is another kind of technical debt if you think about it, and a lot of startups scramble to make up for it when they find they need to hire quickly but those hires aren't getting up to speed as quickly as they should be. So they overreact and think it's the quality of the developers that's the problem when it's really their own lackluster training resources causing the issue. Also, the company I'm at just constantly maintains listings for front end and back end engineers and data science just to try and keep a constant pipeline coming, but the actual needs and experience levels they're looking for at any one time on those teams do change. IMO you should never apply to a job post that's been up for 1+ month; always target newly published listings and you'll up the chances a recruiter reaches out. The rest is just HR noise.

</comment><comment><USER34> The weirdest part about this is how many companies fail to properly estimate the degree to which per-project on-the-job-training / on-boarding is inevitable _even if you check every language /datastore/framework/tooling box they could possibly ask for_. Checking those boxes can be helpful, but unless there's no value in your software other than that provided by the l/d/f/t, your software has something like domain specific knowledge. Or at least a somewhat niche linear combination of other pieces of such knowledge. And a person who can fill in those blanks on their own -- as seems to be expected for a fair number of positions -- is probably capable of filling in l/d/f/t gaps too.

(OP: email's in the profile if you're interested in making a potential contact; hiring is on the horizon where I'm at.)

<comment><USER35> Onboarding in domain specifics is different.

Language and programming fundaments have to be taught, and companies rarely have any decent processes around it, and it eats a lot of time from other developers. Domain knowledge can be gathered from literally anyone in the company, and also unless you are a senior, you don't need that much of understanding.

Moreover, you can do some tasks without knowing anything – fixing nasty bugs nobody has time for, automating some stuff. During doing that you can get some ideas what it is about. Another point is that person with experience already immersed into other/same domain in the past projects.

<comment><USER34> The term domain knowledge may not be specific enough to convey what I'm talking about; "domain app logic" might be closer to what I'm getting at. It's the domain specific portion of a given system. It (hopefully) represents domain knowledge or is oriented around a process informed by that knowledge, but it's encoded in the software (and docs, if any).

I can see why many companies don't often have a process around teaching programming fundamentals and prefer to hire those who can demonstrate competence in one or more languages. I understand less why companies with a determination to build their team rarely have any kind of methodical approach to introducing developers to their systems and seem to prefer sink-or-swim ad hoc task assignment.

There's a consistency to that approach with the approach of a precise list of specific stack/tooling requirements, of course: it says "we want to rent talent, not develop it." And that approach has its merits, even. But there's an inconsistency, too -- if your primary approach to introducing people to your existing systems is learn-by-flailing, why be concerned about avoiding that with frameworks and languages, too? Especially when, as far as you're concerned, the familiarity that matters is with specific languages and frameworks _as used by your system_.

</comment></comment></comment><comment><USER36> On the job training is very much a thing, but I think the vast majority of companies out there prefer to start doing that while a potential hire is still in college. It's less risky and usually the potentials are more moldable. Internships that move to a full time hire is how we brought in a large percentage of the workforce over at Microsoft, and the same is true where I am now (Atlassian). For those in that position, we supplement their internships with a lot of on the job training.

It becomes harder when someone is in the position you're in - 4 years of experience at companies that aren't big name ones. Most companies aren't sure how good your skills will be, and you come with way more risk than someone still in school. If an intern doesn't work out, after six months you just don't extend them an offer. Their internship becomes a long extended interview. In your situation, if you pass the interview but don't end up working out after 6 months, the process of removing you is much harder. It requires a lot more risk on the company's part, so almost all of the big names exclusively look for college hires.

<comment><USER37> > It becomes harder when someone is in the position you're in - 4 years of > experience at companies that aren't big name ones.

This is very true. Having a few years at well known company on your resume will get you in the door.

Also worth considering is highlighting the clients who used the systems you worked on rather than just the little known company.

</comment></comment><comment><USER38> I have an answer to the paradox of how these can both be true:

(1) companies complain about a shortage of programmers;

(2) angry commenters claim otherwise.

If there were few good programmers and many mediocre ones, this is what you'd expect to see.

<comment><USER39> I especially like when one job opening is broadcast to tens of thousands of qualified applicants. If you have hundreds of applicants that are similar for one position I guess you can spend a massive amount of time looking for "culture fit", leaving your one qualified applicant who has probably multiple job offers now to accept yours out of several.

</comment></comment><comment><USER40> I think it's totally doable, but you need two important things

1) a good exit process 2) a good promotion process

1 brings serious culture issues/questions with it. See horror stories from people who went to grad school in the 80s and 90s where year two cut rates were 50% or worse. I don't know how you deal with this, but it will certainly deeply affect your work environment.

2 is easy on the face, but requires huge buy in. Realistically you're looking at a 2-10x increase in this person's compensation over a very short time frame or you'll lose your training investment as they jump ship.

<comment><USER41> > Realistically you're looking at a 2-10x increase in this person's > compensation over a very short time frame or you'll lose your training > investment as they jump ship.

This is actually a very helpful risk-mitigation strategy. If you hire someone with less experience at a lower salary expecting to train them and it turns out they're terrible, all you have to do is not promote them. Once they realize they won't be promoted here but on paper have some experience that can get them a higher paying job elsewhere, they'll promptly disappear on their own without you having to fire them and all that goes with that.

<comment><USER40> I'd definitely worry if I were relying on this strategy.

1) What about the employees who won't or can't jump ship? These are the ones that are most important to push along in terms of company health.

2) I'm not a huge fan of the implicit 'firing'\- the employee may feel a sense of responsibility to the company and slowly become more and more upset as theyre passed over for promotions.

3) I'd worry about the easy slippery slope towards terrible culture this would allow. A manager thats allowed to keep on sub-par staff because they're cheap might start stringing them along to keep the cheap and mediocre work. "Sure the promotion is coming, we just need to find the money in the budget next quarter...". Its hard to have insight into these issues from a level above the manager, and the manager has huge incentives to do it. So best not to create a structure where it can happen so easily.

<comment><USER41> All of those are solved by just being candid about their actual chances of promotion, and then actually firing them if they don't take take the hint after a certain period of time (or if their performance gets to the point of justifying being fired for cause).

Assuming it's even a problem to just leave them where they are indefinitely. There are a lot of people who make bad managers but fine low level workers.

</comment></comment></comment></comment><comment><USER42> Training isn't dead at all, most companies have co-op/internship programs for exactly this purpose. This greatly reduces the need for hiring junior employees since you already know if they are a good employee, and they are already trained enough to dump them right into a project without all the training for the tools/processes/product that goes on for any hire.

In my experience this means that the vast majority of hiring through standard postings my companies have done are for mid to senior level positions to keep a good variety of experience in the team. For the hiring I've been involved with, it often comes down less to whether the person ticks off all the boxes, but rather whether they can actually do everything that comes with the job. If you are getting rejections for missing one or two things, I'd recommend evaluating how you are coming off in your resume and interview and make sure you are emphasizing that you are able to learn quickly on the job.

</comment><comment><USER43> > when it would take days or a couple weeks to learn XYZ > framework/library/whatever to the level of competence that is required for > the position.

Here is their thought process:

If you believe that is the case, then why not spend a couple weeks learning XYZ, so that the next time you need XYZ you can say you know it?

Either it's not actually that simple, which means that it would take a long time for you to ramp up, or it is that simple, and you lack initiative.

<comment><USER44> I think you're right that it's not that simple. The really valuable knowledge is not the type you get from introductory tutorials, but the type you get from working on production systems.

GitLab concluded that they didn't have the capacity to train developers unfamiliar with their tech: [https://gitlab.com/gitlab-com/www-gitlab- com/merge_requests/...](https://gitlab.com/gitlab-com/www-gitlab- com/merge_requests/2695)

<comment><USER45> GitLab is talking about (not) training python people to do ruby work, which indeed needs months of work.

OP is talking about not knowing framework xyz, I'm assuming like knowing JavaScript but not knowing Vue or knowing Python but not knowing Django or Pyramid.

You can be productive with a framework in days / weeks if you have solid knowledge of the programming language.

</comment></comment></comment><comment><USER46> EDIT: to people emailing me (thanks!), I am currently on PTO overseas so I _will_ respond, but maybe not super timely. Also, we're looking for our first QA and our first DevOps role if non-SEs are reading...

If you're willing to work in Texas, send me an email (check my profile). We absolutely do not mind if you have gaps.

semi-OT: To all people in this thread who say there is no shortage of developers: if you know any of these developers willing to work in Texas, send them my way!

We are struggling to hire for front-end/full-stack developers. It isn't a problem with pay - we offer quite competitively AND Texas has low cost of living! The problem is that we seem to get people who can't pass variations of fizzbuzz (i.e., implement max, min, mean, median on a list) or who we filter out after an intro call due to red flags (claimed to be a web application security specialist but also claimed no experience with web browser APIs, another that claimed to be an expert in databases but didn't know what a schema was!).

I am willing to believe the talent is out there, but we are having a hard time tapping into it.

<comment><USER47> I am just curious, why do you need to test somone's ability to find max of a list. Language designers have recognized this as a basic utility and incorporated them into the language. Is the hypothesis that - if someone cannot write a simple algo to find the max of a list then what other difficult tasks he/she can perform ? Even though in reality we all understand no one needs to write a max algorithm.

<comment><USER48> Yeah, I'd say the latter. Finding the max element in a list is an extremely straightforward thing to code; if someone can't do that, it's almost certain they're going to be lacking in a lot of other ways as well. Of course it's not the only thing you would check, but it would make for an easy early filter (which, unfortunately but conveniently, would probably weed out the majority of your resumes).

<comment><USER49> Fizzbuz removed us 90% of potential hires and saved a lot of money in cutting interview short.

Granted this is a rural area and ymmv depending on the local average skill level, but still if you want to grade someone from zero to ten you need to start with exercisers close to zero.

Otoh if your interview questions are all 9 or 10 in difficulty most of your candidate will fail them and you'll have no data for a decision because all 8s will fail to answer in the same way as 6s and 3s

Much better to start with some stupid loop and work up from there.

<comment><USER48> > Otoh if your interview questions are all 9 or 10 in difficulty most of your > candidate will fail them and you'll have no data for a decision because all > 8s will fail to answer in the same way as 6s and 3s

Besides, it's a waste of their time and yours to have someone attempt a 9 or 10 before they show they can pass a 1.

</comment></comment></comment></comment></comment><comment><USER25> I think it is a bit like dating in the modern era: there's always the hope of finding the perfect unicorn.

There's also the fact that people sometimes dont hire until it hurts (they have too much work to do) and then there's little or not time to train.

There's also a flood of folks from the bootcamps that may or may not have skills but want the salary of a jr dev. These folks (understandably!) flood any jr job posting, making it hard to get through to the hiring manager. There's a bit of the flavor of the year 1999 in my opinion, where everyone wanted to be a programmer (and if you could say "Java" you were hired).

Finally, an investment of months of training makes sense if an employee will be around for years. But because of the erosion of the employee/employer social contract, there's no guarantee as to how long a trained employee will stick around. Better to wait and hire someone who can make an impact their second day.

That said I think there's an enormous opportunity to do this kind of training, create loyal employees, and improve the world by training more devs.

</comment><comment><USER50> I figured I'd add my two cents since I'm still a juniorish developer (sitting at around 2.5 years of experience) and I definitely noticed during my my more recent job search that there was a dearth of Junior job postings. I'm of the opinion that there are two major issues in play:

1\. There's the myth of the junior developer breaking prod or wiping databases. This is usually the result of teams not having enough process or protections in play. These are only exposed when a newbie developer does something silly because senior developers have learned how to navigate the system.

2\. There's the myth of the junior developer not adding value until they're fully trained. Personally I have never had an issue ramping up, but from what I've seen across my network and search is that there's a fear of developers leaving once they gain enough knowledge. And, well, that usually happens because junior developers can be heavily underpaid without any promotion opportunities which makes job hopping the best way to increase your salary.

So I would say right now there's an overabundance of mid-level positions that could be filled by junior developers but due to irrational fears results in them just foisting the work upon smaller teams. I definitely noticed that the moment I hit two years of experience that the search became a lot easier

<comment><USER51> I've never heard of or experienced #1 and have been in the industry for 8 years. We all break shit. That's not a reason to pass on junior devs.

In regards to #2, it's not that you won't add value until you are fully trained, but there are X number of people applying for the same position, and as the person doing the hiring you are going to try to get the most experienced developer you can for that role.

There are still plenty of good companies that go out of their way to hire junior devs (for budget or other reasons)

</comment></comment><comment><USER52> So far I've seen everyone on the path of "we train them, they're great, and they leave! That's expensive!"

Fundamentally, I think that's the best case because good->great people can be useful and a benefit to the team in a variety of ways after they get over that first few months.

I think the _bigger_ risk is the people who are unobviously duds. You meet them, they have a ton of potential, and you invest time and effort into them. After that first few months when they should be useful, they're still sucking up time and effort. It's not so much that people complain "get rid of them!" but enough that they never add _anything_ to the team. They suck and suck and suck.. and they still suck.

</comment><comment><USER53> While you might say "I don't know React, but will start learning it as soon as I come into work," someone else is saying "React is so cool! Yeah, I haven't done much with it, but I was playing around with it the other week and I made a little todo app. My code was so much cleaner than doing it the old way."

Which person gets hired?

Companies are willing to do on-the-job training, as long as the person appears enthusiastic and the gap between your current skills and the target isn't too large.

P.S. A cynical person would say that you don't even need to have followed along with some todo app tutorial unless they call your bluff and ask to see code. :)

<comment><USER54> The second will get hired, but may be a much worse employee. Also tech stacks are exploding, so learning everything is not possible any longer.

<comment><USER55> > The second will get hired, but may be a much worse employee.

Why would they be worse than the first candidate in this example, if they've actually tried out React and the first has not?

<comment><USER54> There are many fantastic devs that don't chase fashion.

<comment><USER55> Trying out new technologies isn't "chasing fashion". It's an indicator of intellectual curiosity, drive for self-improvement, and openness to new ideas.

Blindly adopting everything new and claiming it's the best thing ever is "chasing fashion".

<comment><USER54> It certainly can be and is largely subjective. But, I bet you know that already.

</comment></comment></comment></comment></comment></comment><comment><USER56> I work for a big corp who has always hired a lot of graduates for a grad program. We rotate people through two teams of 6 months each then place in a final team in one of those areas or a third if necessary. Traditionally it has worked well as we get a good source of smart people. Recently though grads are leaving really quickly, like 18 months, even just a year.

Maybe its because the job market is hot people can get mid level jobs with 1 year of experience. I don't think a recent grad with 1 year experience is worth paying mid-level salaries, but I guess that is all they care about.

Training grads really sucks, they are negative to productivity, but I personally try to spend a lot of time interviewing, mentoring, training, doing extra code reviews because I've enjoyed it and want to help people. When people leave after 18 months with the company though its really disappointing, almost insulting. I feel like I'm wasting my time. Our team is going to stop asking for grads because we are really getting nothing out of it.

</comment><comment><USER57> Our startup is located in El Paso and it's super hard to find senior devs here. I had to start teaching programming classes at our local maker space to find our first hire. After a few months of teaching I cherry picked the most promising candidate and gave him a job. He's still learning but has quickly become an integral part of our engineering team and I see him as a future leader in the organization. I am very happy with our decision. I don't have to break the bad habits or cater to the inflated ego of a more senior dev.

As his skills are growing we are adjusting the pay accordingly; He already makes double what he started at. Being in El Paso, this model makes sense and works but may make less sense if you live in an area with a bigger base of techies. If we were located in San Francisco or Austin, we may have pushed for a more senior level hire but we plan on staying in El Paso and continuing to train and build up our employees.

</comment><comment><USER58> Could you not argue that the move towards hiring developers from bootcamps is not a step towards on-the-job training?

I know of very few examples of knowledge industries where you can go from nothing to "able to pass an interview" within 2-3 months of intense study. The same goes for self-taught developers that learn on the side, and then use those skills to build a portfolio.

I've worked at places where they hire heavily from bootcamps, and a small team of senior developers are tasked with mentoring and training these entry-level developers. From my experience (in the UK), the issue is that people "are" hiring juniors, but the market has become flooded with entry-level and junior- level developers. Bootcamp graduates have become the entry-level, on-the-job trained types, whereas university graduates are expected to have an acceptable level of knowledge to be able to hit the ground running in a junior capacity.

</comment><comment><USER59> Over the past three years we've employed a team of 19 software engineers in Nepal. Bar 3 of them, we've trained up 16 developers from Interns to fantastic engineers working across phoenix, elixir, ruby, kubernetes and javascript projects.

We've treated them well, trained them up, brought them on board interesting projects. When it comes to staff so far we've a great retention rate. Nepal has a huge problem retaining the best and brightest, many leave the country straight after high school or college to seek better opportunities. I think we'll keep hiring juniors but I'd love to have more senior (20+ years experience) engineers on board. They don't seem to exist in Nepal.

<comment><USER54> Nepal barely had computers twenty years ago, outside of expensive internet cafes.

</comment></comment><comment><USER60> Be careful what you wish for.

This is the norm in Japan. Students are hired out of college. They often actually have no real programming experience but based on their major they are hired into an engineering track.

Programmers in Japan start at $20k-$25k a year. Many famous Japanese companies have limits set by HR of $60k a year for a programmer regardless of experience.

I'm not saying that's the result you'll get but at least in Japanese culture the fact that the company trained you is at least one small part of feeling an obligation to stay on and that fact the so few people switch jobs is yet another reason salaries don't rise here.

<comment><USER61> Again, are these total earning? in USD? Because many companies (especially in US ) have performance bonus, stock etc... where their actual "yearly" earning is way higher.

And just to make it clear, The difference between a junior Dev and Super Senior Dev is only 3x?

( I am still baffled by how widely different the dev salary are in different region )

<comment><USER62> In most countries and companies of the world programmers are not paid any bonuses, and even less so RSUs. It's mostly just a base salary.

And yes, the differences might be normal. In germany it's even less. One might get around 50k€ fresh from university. But there will be far less than 1% of roles which offer a compensation of >= 100k. At least in engineering, management is different.

<comment><USER61> Yes in most countries, but most ( English ) article are written from a American perspective. And they have lots of different way calculating their earnings.

</comment></comment></comment></comment><comment><USER63> They can hire a mid/ senior developer who will get up to speed fairly quickly and be able to work on their ownand then will leave after a year or two, or they can hire a junior Dev who will take longer to get up to speed, and use up the time of other more senior devs, or increase tech debt if they go off on their own, and then they'll leave after a year or two.

To put it another way they can either pay a senior developer a lot of money to do work for them, or pay a senior developer a lot of money to teach a junior Dev (who they're also paying),only to lose them both after x amount of time.

</comment><comment><USER64> My experience has been that many manager want to run or at least pretend to run a tight ship. So, they would rather splurge on finding that awesome- senior-dev than train people from scratch.

Though this seems odd, it tends to give hiring managers some sense of security when they report to their superiors. They'd rather say:

I have X who has Y years of experience in Z framework

than

I have X who has zero experience in Z and we are going to train them.

It is like Kanehman's certainty effect. They'd rather be certain of competence than bet on the fact that you might be trained to be competent.

</comment><comment><USER65> You say that "it would take days or a couple weeks to learn XYZ framework/library/whatever to the level of competence that is required for the position", but in my experience finding people capable of self-learning XYZ framework/library/whatever are exceedingly rare and almost impossible to interview for.

Conversely, teaching is really, really hard especially when you have other work to do. There are just so many gaps in a newbie's knowledge that, unless you're prepared for it, add significant friction to support and development operations. I would dearly love to hire someone at whom I can throw work and have them mostly be able to figure it out on their own. Instead, I've had to hire people who don't even know the fundamentals of my various technology stacks. This means I spend a _lot_ of time teaching new hires how to (e.g.) use the Unix command line before I can even think about teaching them how to follow our good current web server deployment practices, use our version controlled configuration management infrastructure, and troubleshoot problems in the front or back ends. Meanwhile, my management expects me to complex offload work items (including service package design!) onto junior staff while not taking into account the effort required to train them. Here on the other side of the hiring line, it's frustrating to say the least.

</comment><comment><USER28> Most of the time because companies are hiring out of necessity. They either need to deliver more, faster, or are lacking technical leadership / expertise. This means the team is under enough pressure to deliver as is and don't have resources or incentive to onboard a junior.

My advice is to keep learning on your own time, push yourself to learn a valuable skillset e.g. React (as you say you do frontend) and make something with it. For a new hire getting familiar with a project is a given, even a senior needs time to do this. However knowing a language, framework, or skill is your responsibility before applying for a job.

I've applied for jobs that were above my experience level but ended up getting hired anyway while I didn't have enough "years" under my belt I knew the domain and tech stack required for the job. This often meant when applying for a senior job I'd get signed as an intermediate and same with intermediate roles where I was hired as a junior. Once your foot is in the door, if you work hard it will be apparent that you're adding the value of more experienced member than your current job title and from there its an easy promotion discussion.

Just my 2cents. Know your stuff, that's your job and stay humble the promotions and opportunities will come.

</comment><comment><USER66> I don't mean this the wrong way, but maybe the issue is something with you?

If you're having trouble getting interviews, it's possible your resume is not great, or you are applying to jobs that have a bad fit.

If you're getting rejected after interviews, it's possible you need to practice programming interview questions.

It's also possible you haven't achieved a high level of skill yet. If this is the case, spend time building your skill set and competence.

</comment><comment><USER67> There are places that (shock! horror!) don't actually mind that much what tech stack you have a background in. These are also likely to be places where to use the right tools for the right job, failure and learning from it is encouraged, and everyone helps to fill in the numerous gaps that everyone has in their knowledge.

It might be tricky to find them, but it will be well worth it.

</comment><comment><USER68> On the job training is very hard and takes away time from senior devs to teach and mentor junior debs as far as management and HR see.

I used to mentor junior devs in Visual BASIC in the 1990s and got written up for doing so. It helped the junior devs become more productive and experienced. It is usually management that is against it not the developers.

</comment><comment><USER69> The gulf between a senior dev and the average junior is akin to the gulf between a senior dev and the average window washer. The gap is too wide between juniors and seniors.

Plus the market is flooded with junior devs. At this moment it's tough -- but not too tough -- to hire a senior dev. But juniors are a dime a dozen.

<comment><USER70> In what ways is the gap this wide? I tend to think the opposite.

</comment></comment><comment><USER71> Its basically a sign of the balance of supply and demand shifting I think, and particularly a large influx of new opportunists who jumped into programming for the money but might not have the aptitude or motivation.

Companies are very, very risk-averse in hiring and they don't want to get stuck with one of those types. They overestimate the short-term risk of making a bad hire and underestimate the long-term risk of not moving fast enough or hiring enough.

Even from a purely cover-your-ass perspective, a manager who makes a bad hire will likely be blamed for not screening candidates well enough, but a manager who fails to hire enough can easily point to the "talent shortage". No one ever got fired for choosing AWS, and no one ever got fired for hiring an ex- Googler :)

<comment><USER72> > Companies are very, very risk-averse in hiring and they don't want to get > stuck with one of those types. They overestimate the short-term risk of > making a bad hire and underestimate the long-term risk of not moving fast > enough or hiring enough.

Actually, a bad hire is a long-term risk. It's hard to fire fast and bad hires add up. B players hire C players, as the saying goes.

</comment></comment><comment><USER73> I'm seeing a lot of comments from a HR perspective or that once they get the training they leave. To me it's much deeper than that. This industry of software development only recently has exploded because it's much more mainstream and the demand is growing.

I feel if we compare it though to other trades the issue is simply the industry as a whole has top-ended and completely changed itself the last 7 years each time. I've seen Senior Devs take a junior role at their next company simply because the rate of change is so fast.

This is not a trade like plumbing or even electrical work where once a way of doing something is set in stone and you'll do things a certain way the rest of your career.

If you told me 10 years ago I'd be writing javascript all day everyday...

</comment><comment><USER74> The problem is that you are identifying yourself as "front-end UI/interaction dev". Once you shoe horn yourself like this, your job offers would depend on what you know in this area. It's not that companies don't want to do on the job training but the fact that failure of you not knowing X while claiming to have specific specialization would be a put off.

All of the Big-5s hire massive amount of folks straight out of college or just 1-2 years of experience. They don't even care which programming language you know, let alone knowing specific framework during the interviews. The important part is becoming a generalist, a problem solver who can tackle anything that comes on the way while developing a product.

</comment><comment><USER75> At the businesses where I worked, developers were hired to be productive in taking on workload. Obviously, new people had to be brought up to speed on the existing systems before they could fix problems or add features. If we first had to give them technical training for months before they could be trained to understand the existing systems, that would have taken too much time. Even the front-end user and B2B interfaces were large and complex, let alone the arcane and hideously complicated domain-specific business logic - that took years to learn and be proficient working on. If in a job interview I heard the equivalent of "I can learn your UI framework or whatever" there would not be a hire.

<comment><USER76> I don't really understand this?

It's trivial to learn a new UI framework, why limit yourself to only the devs that know the one you've selected?

I guess if you have a lot to choose from why not.

<comment><USER77> Companies are under the crunch to be productive. Generally, unprepared people are not as productive as prepared people.

Being prepared to learn to produce value is not the same as being prepared to produce value.

</comment></comment></comment><comment><USER78> My brother studied with focus on AI (Germany) and is searching for nearly 1 year for a job... one should think that this is the most requested job on the planet. But nobody wants to have AI experts without 5-8 years experience.

If somebody wants to change that message me here ;)

</comment><comment><USER79> I am a senior developer in a small company, we almost exclusively hire Junior developers and train them.

It's not a tech hub and so while we have had positions open for senior developers at good salary for the area by any stretch, we just cannot hire them.

I believe as others have said, we run the risk of training them and then they leave. However, that has not been my experience so far.

Perhaps one thing that I do with training that may be different to elsewhere is that I make it clear that they do control the codebase, and the challenges are always getting more complicated, the number of customers we get is growing and the markets we are in are expanding, so they should definitely see personal development opportunities within the company.

</comment><comment><USER80> This question resonates with me because I am a junior dev (bootcamp background, 20 months into my career), and am currently on the verge of switching jobs. I am very thankful to my current employer for hiring me and giving me a shot to grow into this career and treating me extremely well in the meantime.

The thing is, they pay below the market rate, my wife is pregnant and not very employable because she doesnt speak the local language, and the 40% pay increase would allow me to get the mortgage to buy the apartment we live in. Otherwise we will be priced out of living in the city. I just feel really guilty, but my responsibility to my family exceeds my commitment to my employer...

</comment><comment><USER81> Stay away from companies and recruiters who ask you to be familiar with a laundry list of technologies, IMHO it's a red flag. If you kill it on the CS fundamentals and programming practices/patterns, then it shouldn't matter whether or not you are an expert in dime-a-dozen technologies like state management frameworks and view frameworks. Anyone worth their salt as a developer can learn and be somewhat productive with a framework in less than a week on the job.

I'd rather pay a math/engineering graduate who knows nothing about React than a bootcamp student who has had a year of experience with React.

</comment><comment><USER82> What I have found by working with junior developers are our company is that I end up learning, reflecting, and growing myself, my skills, and am able to better express myself and my ideas as well.

I also get good questions that I may or may not know the answer too. So, I feel not only am I teaching someone who has much less experience, but I end up learning things myself and new ideas or thoughts and ideas I never had before.

Seems like a win-win to me. Plus, it's super fun having co-workers who are hungry and curious and to work on for-fun side projects with once in a while.

</comment><comment><USER83> If you work in an intense environment like an agency, particularly one with high profile clients, then on the job training causes more problems than it solves.

We had a guy who wrote a production web application software, completely untested in R lang (which is the worst choice for this situation) with terrible code (Think of mixing camel case and snake case, sometimes with same names (ExVariable and ex_variable and they both refer to different things). This thing kept failing over and over again to the point where the clients terminated their contracts with us.

I had the bad luck of having to re-write his R code into Python which was suitable for this specific problem than R was and had to explain to this junior dev. Still, he wouldn't budge and kept writing untested production software in R when in reality most of his peers already knew Python and Ruby, whereas he was the only one with R knowledge and no one else in the company could understand his code, not even people familiar with R.

Eventually he costed the company a lot of revenue, in terms of clients, and the company almost hit bankruptcy to the point where almost everyone quit (including me).

Learning on the job isn't such a bad idea if the impact you have isn't as much. Like writing in-house applications for experimentation. Other than that, it's a terrible idea.

<comment><USER84> >>I had the bad luck of having to re-write his R code into Python which was suitable for this specific problem than R was and had to explain to this junior dev. Still, he wouldn't budge and kept writing untested production software in R when in reality most of his peers already knew Python and Ruby, whereas he was the only one with R knowledge and no one else in the company could understand his code, not even people familiar with R.

Why was he given so much freedom in writing code? Especially as junior? I'm a senior at this point and I couldn't just arbitrarily decide to use R(or any other language that isn't C++ for that matter) for my job - it just wouldn't go through code review. Because I'm sure you had code review at your work, right? And if you did - who was approving his mess of a code?

</comment></comment><comment><USER85> The big 10 tech companies pretty much exclusively hire junior devs. At the scale Amazon, Facebook, etc are hiring, they have no choice but to primarily recruit folks straight out of university.

That said, unless you are currently attending a top computer science school, you can be forgiven for not knowing this. Junior positions aren't really advertised outside of college recruiting trips.

I'm only aware of a single major tech firm (Netflix) that is philosophically opposed to hiring junior developers.

</comment><comment><USER86> We certainly hire junior engineers at my startup - we have about 50/50 "people who need some training"/"people are contributing at 100%". That said, at a startup, it is some drag on the build/test in the market cycle, so I feel like we're "weird".

We certainly are hiring, just not in front end - looking for backend engineers and applied cryptographers/security folks. I'd be happy to look at your CV though!

</comment><comment><USER27> Don't lose hope, it's just that you haven't met the right team yet. I have seen many times senior folks are hired to cover the hiring teams back in case something goes down south. You cannot shift the blame if you hire juniors. Am a senior and I believe passionate people do great work irrespective of their age. Reach me (find my email from my profile) if you just want to talk, will be happy to share whatever that I know. Am a full stack engineer.

</comment><comment><USER87> Only anecdata, but if the team (company) is small and you're chronically understaffed, there may not be enough time for "training" \- maybe this is a bit skewed towards "more generalists than specialists" \- but I've had this experience.

Let me try to give a only somewhat made-up example. If you have 3 people doing a big web application in one stack, I see no problem having 1 or 2 of those 3 be relatively junior. If you work with 5 different tech stacks that keep different parts of the company running, it might be a bit hard to get someone to learn 2 programming languages in addition to needing a little advice in their main tech stack.

Not saying it's a valid reason, but if a lot of your hard decisions are actually important architectural ones and not small "how will this small piece of software be developed", senior people are actually a lot more important than usual, than say, in a team doing feature development.

Also about your definition of Junior.. depending on where you work, 4 years often is not really junior anymore - elsewhere you'll not progress to non- junior until a few years more...

</comment><comment><USER88> I have seen people being put on a project not in their field and start with a lot of enthusiasm. FFWD 1 year and they don't particularly have talent for their new job, they feel they took a wrong career turn, they just aren't progressing (I also saw the opposite btw). It is difficult to judge this in advance and thus a risk. Now I feel it can still be done but only with people who are honest to you (project lead) and themselves by being willing to admit they either need more training or really should be doing something else. But this ability to reflect is also something that often comes with age/experience. I think I work at a company where it is certainly appreciated when you try to develop new skills and failing or losing interest is not a big problem but as a project leader it can be frustrating to think: "Hmm, well that was an FTE I'll never get back." Especially when you see the person really not enjoying themselves. Of course, this is a learning curve for the project leader as well and it turns you more into a coach from time to time. Which is fun tbh.

</comment><comment><USER89> 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](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](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](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!]

</comment><comment><USER90> > I ask this because I'm 4-years-experienced as a front-end UI/interaction > dev, nothing but glowing references, looking for another, similar, position > (regular, not senior or lead)

It depends on what country you're in. This USA has an obsession with calling anybody with more than 2-3 years experience a 'senior' developer. In Europe senior is more like 7-8 years.

<comment><USER91> I don't think seniority has to do with a number of years of experience but the quality of that experience. You could sit at a company for 8 years and not advance your capability, experience, and worthiness.

<comment><USER92> "Some people have 10 years experience. Some people have had 1 years experience 10 times over..."

</comment></comment></comment><comment><USER93> The company I work for (which is fairly small) used to hire college interns and provide training, but to be honest, it just wasn't worth it for us. Their turnover rate was too high, their work quality/quantity was too low, and they significantly distracted the more experienced developers. We also spent years cleaning up after them.

<comment><USER54> There's a difference between junior and intern, which is essentially a neophyte.

</comment></comment><comment><USER18> Basically everyone at the small company I work at has come up through the ranks. I've been there the longest at this point, and I started as a true greenhorn, with no experience, and I've learned on the fly for almost eight years now. I like to think I kind of know what I'm doing some of the time now ;-)

Our other employees that have stuck around and become productive have all been initially hired as part-time testers and interns. Some of them were students at the time, others were coming in from other trades entirely. But they all trained up incrementally on our products and learned our business over time. Granted, theres definitely been a filtering, as maybe a quarter of all those we put in those testing roles proved capable of moving on to doing development work, but that is much better than the success rate we have had trying to hire for actual development positions, whether junior or senior.

</comment><comment><USER94> I run a mentoring organisation which I started because of my interest in teaching. I used to help the graduates find jobs that they liked. After a couple of years, I started a small services company of my own and started to hire mostly out of my own student pool. I'm very happy with the decision. I develop rapport with the students (and later employees).

A 4 month training program, while beneficial for the students, works as an extended interview for me. I get to teach them skills which I think are relevant and fix what I think are cracks in their learning. All in all, at the end, I get employees who have skills that I want and with whom I share a rapport.

The approach has scalability problems since I'm just one person but I see no reason why companies shouldn't formalise something like this and hone good talent rather than fish in the labour pool for it.

<comment><USER95> That's what we did, too. As a company, we formalized our open source R&D activities ([https://github.com/RaRe-Technologies](https://github.com/RaRe- Technologies)) and launched a "Student Incubator" programme.

Junior people around the world get to benefit from the mentorship, and we get access to talented people early on. Without that much internal risk, since it's open source.

The problem is exactly as you describe: scaling. Mentoring is an extremely time-intensive process and when things go rough, such "charity" activities are the first to suffer.

<comment><USER94> Fascinating. I'd love to chat directly and exchange notes. Can you email me? I'm nibrahim on github and that has my contact information.

</comment></comment></comment><comment><USER96> Never call yourself "junior", forget those "internship" jobs also. Just jump in and be a dev. Nobody will hire you if you call yourself unexperienced, but they will hire you if you solve problems and you can deliver the homework in good quality. So just be a normal dev. ;)

</comment><comment><USER97> It's a great option, but it's a hell of a lot of work if you want to do it right. At the end of the day, you also need to continue to provide them all the benefits and perks of developers that came to you with more seniority. None of this is bad, unfair or in any way problematic, it's just a lot of work. In return you may get a bit of loyalty, but again that only goes so far.

I like to hire a mix. Have 1 senior person (initially that could be yourself, it'd always be me in the start) per 5-10 junior people. The juniors should also be a blend to some degree, you do not want some super senior developer coaching 10 new grads, but if you get the right mix...you can create a super productive team this way.

</comment><comment><USER98> One aspect that no one has mentioned but I've experienced with interns is that some juniors don't want to learn. Some think college taught them everything they'll need, others just have no idea how to learn on their own without hand holding after 14+ years in the education factory.

I'm a big believer in education and training people I like teaching and I'll put in a lot of my own time to come up with projects within their skill level and tutor them through various things like debugging, but when that's not reciprocated by them having a desire/ability to learn you really feel burnt out.

I'd be much more willing to put time into people that are self taught, but HR will only give me college graduates.

</comment><comment><USER99> The reasons are twofold:

1\. Managerial sense of urgency. Hiring a junior means training them up, for harder and longer than a more senior hire. And probably tie up your remaining senior staffers for longer training them.

2\. A desire to fix the problem permanently. A senior hire will be with the company a long while. A junior hire you train up is going to leave when they're more senior than they role they filled. Especially if your corporate promotion and salary policies are rigid, you may have difficulty retaining junior employees once trained to the level of a senior.

Until managers believe that hiring and training juniors is a long-term strategy that can be planned and budgeted for, the junior glut - <USER2> shortage dynamic will persist.

</comment><comment><USER100> I'm currently looking for a junior dev role. The issues I'm finding is

A: They expect you to have 4 years of experience or be a college degree. I have neither in software development or

B: They are these terrible "apprenticeships" where they also expect you to have 3-4 years experience, train you for 3 months on their technology stack, and make you jump through flaming hula hoops.

I see a lot of comments talking about how you train juniors and then they leave but I'm skeptical of that. From my personal perspective, I'm not looking to get trained then jump to SF for a 150k a year job. Pay me a decent wage, give me ongoing feedback, and make sure career progression is laid out and I'm good with that.

</comment><comment><USER101> > To further stack up the frustration, it's not uncommon to see the same > position listed and re-listed on LinkedIn and Indeed for months: certainly > somebody could have been hired and trained to the level needed in that time.

There are a lot of companies that aren't serious about hiring. They post jobs, conduct a few interviews, but never actually hire anyone to fill a position. My guess is that they think it's a good idea to always list an open position just in the case a demigod of computer science happens to apply.

You can usually tell right away if a company is serious - they actively shepherd you through a short but intense hiring process, and if they want you, they make an offer quickly.

<comment><USER102> I think there's another complication here, which is that companies will list a position once even though they are hiring several people.

</comment></comment><comment><USER103> Not true. I run 110 people team for a large retailer. I built this team nearly from scratch. About 80 percent of my team consist of right of college kids or folks with less than 2-3 years of experience. We they are very smart kids. :). I paired them up with other seniors from different department to train them up. We also pay very well. Entry level pay is 80k plus like with only college degree but with hard interview. I Also work very hard to make them successful example include sitting down and knowledge sharing of how the business works or even sitting down to layout framework or debug etc. i truly enjoy working new generation the old is status quo :(.

<comment><USER104> Where do you work and how can I get in contact?

(I run a YC-backed Computer Science academy that aims to be very rigorous and has incredibly hungry students - [https://lambdaschool.com](https://lambdaschool.com))

</comment></comment><comment><USER105> Maybe the small companies that are happy to employ 'junior' developers struggle to find them in the first place. We are hiring @ theurge.com but not sure where to find junior talent. Please email us if you are interested in roles in Sydney Australia.

firstname.lastname@example.com

</comment><comment><USER106> I'm the co-founder of a web-focused consultancy which works with larger, "enterprise" type businesses to fund work with much smaller companies, usually pre-seed startups. We hire more experienced engineers to work on the ground with the larger clients and we actively hire more junior engineers to work alongside a small number of experienced people on the startup projects. We find this offers solid on-the-job training for the juniors as they rapidly get exposure to a wide range of skills and technologies without necessarily being hampered by legacy codebases, massively complex change management and deployment processes and office politics.

</comment><comment> VvR-Ox 1\. It's expensive 2\. You don't know the result (he will be the work force you need for the price you want) 3\. There is certain other risks like the junior goes away when he had the training because there is another company that pays more (there is allways that other company where roses are more red) 4\. Why should there be training when all the people in CS are ok doing training for free at home? Hell, there is even Hackathons that are used to get creative ideas and real work done in no time for no money (nope, all the catering, fancy prices and lousy shirts didn't cost the same it would've with some senior dev's)

</comment><comment><USER107> For one, you have to pay a senior developer to train them for a year plus before they'll really be productive. And secondly, there's not really a cost saving. If I hire a senior at $200,000 a year they're likely 10 times more productive than the boot camp grad I can hire at $80k a year or the offshore contractor I can hire at $20k a year. Plus that senior dev will be able to think about good architecture, team dynamics, bring industry experience, etc.

Now I do think there is a place for hiring interns and new college graduates once your development org reaches a certain size or the company is at a certain level of stability.

</comment><comment><USER108> I'm kinda curious what a developer with a couple years experience and making his own company would be able to demand back in the states.

I think "apprenticeship " isn't a thing in tech. Things change quickly and companies don't want to pay more money for people to develop software. Mostly because developers are viewed as a cost (a well-paid cost) and not money makers.

And then the ageism problem. my biggest concern is what I will do if my business fails. Would companies even bother looking at me? Who knows _shrug_ I'm in my late thirties and I'm pretty sure no one would hire me for developing, though I could probably be hired as a manger or team lead.

<comment><USER109> It used to be when I started in the math modelling group of a world leading rnd organisation.

I went on the custom mech eng "higher" apprentice course (that had been developed for the local industry) at my local college.

1 day a week plus an extra half day a week for the first year to get my tech drawing O Level (GCSE)

of course the Jammy buggers who worked for the civil service at RAE got an extra afternoon to do the home work

</comment></comment><comment><USER110> In VC land at least I think there is a preference for cumbersome employment agreements to capture intellectual property and head off potential competition, even if unenforcable by law (simple psychological / fear). Legally programmers are universally hired as "exempt" salaried "employee" (vs. worker).

Junior devs should be hired on as exempt hourly workers. This would replace the worse than random interview process and do lots of wonderful things.

It cuts lawyers and HR out to a large degree so I have a hard time seeing it catch on, but in the longer term smart contracts and other lawyer labor saving packages could bring it in.

</comment><comment><USER111> Simple: nobody has time.

Due to capital availability [1], the SV/SF ecosystem is highly optimized to favor spending money over time. That's why you get much-more-expensive WeWork over private office leases, everyone wanting to pay 2x as much for very senior staff, and few companies able to build a good content marketing brand.

Patience is a huge competitive advantage, if you can manage it.

[1] [http://www.davidralbrecht.com/notes/2018/11/risk- capital.htm...](http://www.davidralbrecht.com/notes/2018/11/risk-capital.html)

</comment><comment><USER112> I worked for a company that did this very successfully for a long time - <USER3> paid very high salaries and had lots of nice perks so that people weren't tempted to jump ship for financial reasons. However, as tech salaries have increased the last few years, they have hit the problem of people jumping ship after a couple of years, presumably because they can now earn more as developers in the finance sector or with Google, Facebook etc, though I expect something more subtle might also be going on as the company has grown in size.

</comment><comment><USER113> Generally speaking I'd say if the devs have to be there no matter what you want juniors. If you have a goal to complete use experienced devs. Have the experienced devs build a product and the juniors support it.

At the end of most 1-2 year projects I usually feel like I could turn around and duplicate it in a matter of months with the knowledge I have. If I do another similar project it just flies. Experienced devs are a better value for your money in general. You can be a 10x developer and barely get paid more than twice the average rate.

</comment><comment><USER114> My employer does... many of our best candidates come in as interns and outperform experienced consultants, but snotty tech companies won't touch them because they are not from the right schools.

<comment><USER27> Schools are overrated in tech industry, at this point in time, you would do much better if you just spend your time learning and trying things on your pace and time rather than wasting on spending in a school.

<comment><USER114> I agree. One of the best network engineers that I've met had an AS in Welding Technology.

</comment></comment></comment><comment><USER115> One thing that our company did right was hire a load of junior graduates; they were extremely lucky to benefit from years of learning and explanations from their very senior mentors and it encouraged people to think through why things were being done and to choose simpler solutions for them.

However, I still wonder if any of them are natural programmers or if they were just doing it because it was a good job. By this I mean it would be hard for them to understand and be self sufficient even after a year of intensive training.

</comment><comment><USER116> The very obvious reason is that a junior dev is by definition replaceable (because he can't work on his own), and thus makes no sense hiring full time locally - better (cheaper) be outsourced to India or Ukraine. Outsourced people are unreliable, but with junior ones, this is OK, some trial and error is quite affordable.

Or better yet, you can hire a senior in Ukraine for the price of junior in the U.S.. And junior ones in Ukraine just do ghostcoding for the seniors until they can find clients of their own.

</comment><comment><USER117> HOW the heck CAN you evaluate _potential_ or _learning speed_ in a 30min interview?! I've been a couple times on the interviewing side of an interview (being an engineer), and trust me, _evaluating a senior is 1000% easier than evaluation a junior:_ resume makes sense, the fact that he has experience that may overlap yours makes it easy to come up with relevant and revealing questions during and interview etc.

 _Evaluating a junior is SCAAARY! You have no idea what to ask him so that you can get relevant answers!_

...so most people "give up" and throw an algoritmic puzzle or something like that hoping that "raw IQ + ability to manifest it during the stress of the interview" means "she has a reasonable chance of being useful for the company".

As a startup the risk of wasting time onboarding a junior that turns up not to be useful it might simply not be worth it.

Also, this is the reason why companies like banks still look at _education_ when hiring juniors, more like "heck, maybe the top-tier universities did _some_ filtering themselves so it would make our job a _little bit_ easier".

</comment><comment><USER118> Not here in the Netherlands at least... the last three companies I've worked at have all hired junior developers, though it tends to be done once a team has already been built up from more senior people and the way of working/team cohesion has stabilized a bit.

What kind of companies are you applying for? If you want, you could send me your CV and I can have a look over it, I've been involved in hiring said junior devs before and maybe I can offer some feedback. firstname.lastname@example.com

</comment><comment><USER119> I agree with you that there seems to be an industry bias towards more experienced developers, and I think it's to everyone's detriment. Our team recently took an someone with 0 experience, who worked their way into a role with us from a business team we interfaced with. We had a strong team to begin with but we were all pretty senior so none of us were really actively mentoring. By adding someone with little experience it's really rounded out the skill set of the whole team.

</comment><comment><USER120> I've built a team of 10 junior devs in the Washington DC area. The prime motivation for hiring juniors is that there's ton of good entry-level talent (worked on published research in college, built an app and got some users, etc.), but good mid-level has been hard to find.

We give good raises and a lot of coaching, but since our work doesn't change much, people typically get tired of it and leave after a year or two. Ideally we would find a way to retain knowledge and talent.

</comment><comment><USER121> A year ago my company hired two young developers straight out of university and we've been training them on-the-job ever since. They are pretty well up- to-speed now, but it did take a full year to get them to a point where they are more gain than drain on the rest of us. I guess that's why not many companies do it, since it has been fairly expensive in salary to the new guys + productivity loss for the rest of the department.

It's great now, a year later, though.

</comment><comment><USER122> I'm a fairly senior mobile/web dev (12 years full time, part time and hobbyist before) and the best part of my job is mentoring the juniors! I push hard for hiring people who are hungry and fun to work with, and it's paid my company dividends. You can spend a few months training a junior or a twice the time hiring a senior, and the juniors always bring good energy and open minds. It's not for every company but I have enjoyed it immensely.

</comment><comment><USER39> 4 years experience probably makes you more of a mid to senior developer. Why even bother applying to positions below your level. That is probably why you cannot get one.

<comment><USER121> I don't know where you work, but where I'm at, less than 6years of solid experience would be considered junior, no where near seniour - that's 10-15 years of relevant experience.

</comment></comment><comment><USER54> The "shortage" isn't real, or could be described as caused by the industry itself. A cynic would say in order to hire cheaper folks on a visa. They also won't hire women or forty year olds, or those that can't code with a gun to their head, and certainly not anyone who needs four hours training. What do you think we're morons? We'd rather sit on a job req for nine months waiting for a unicorn to walk in, because that's how Spolsky did it in 2002, haha.

</comment><comment><USER123> Some form of this debate has been going on since the mid-1970's when I was in your situation. The answer I got the most often back then when I asked a similar question was that company ABC does not want to train Company XYZ's future employees. From what you describe, very little has changed in terms of the mind-set of prospective employers vs. employees that are a "good fit" but not necessarily a "perfect fit".

</comment><comment><USER124> We do that. We hire the most algorithmists straight from the university, we even have a special training program for that.

The problem is, if we want to extend our expertise, and we do, we want to hire people that can train us. So yes, apart from hiring juniors, we do have senior positions that we close in months, sometimes year(s).

It's all about the balance. We want people with their own experience, and we are ok with training juniors at the same time.

</comment><comment><USER125> One person that knows what they are doing is better than a hundred who don't. Junior devs out there, keep learning and keep getting better. You will have to get used to that anyways as development is a never ending treadmill of self- learning and improvement. But it's better to have zero devs messing up the code and forcing new opinions on the development process. As they say, cut your teeth somewhere else.

</comment><comment><USER126> If you are just a junior dev then it may be unnatural for companies to see 4 years of experience in your CV. They probably expect you to be a middle dev given the number of years in the field.

And the most important thing: companies generally tend to expect you to bring the value from month 1. Many of them are scared to death by the prospect of an extensive training for someone who may or may not be a good fit in the long run.

</comment><comment><USER103> Oh. The issue I have seen is many of new grads want work for the big name company or tech companies. And they limit their options. Just be true to yourself that if you want work for tech company they need people who already know cutting edge technology and start to produce from day 10. Where as non tech companies need people who can understand business and how to solve biz problems.

</comment><comment><USER127> Here in Budapest (Hungary) we have like 2-3 coding school startups. Their input is somebody who doesn't know what `ls` is, and their output, I think 6-12 months later, is somebody who can set up an AWS/Python/JS/React/etc app. They then "sell" their students to companies. It's a pretty hot space, these companies are getting funding.

</comment><comment><USER128> Because it's hard to do well, and you have to build everything with it in mind.

We've been very successful with a strategy of hiring new graduates and training them. This is what we've done:

[https://www.haplo.com/news/working-with-early-stage- develope...](https://www.haplo.com/news/working-with-early-stage-developers)

</comment><comment><USER129> I missed the boat here. I unfortunately didn't find a mentor with my first two engineering jobs. Now I'm too experienced to be mentored as a junior, but not good enough to be mid level. I've since been unhappily working support roles, getting even further from writing software. At this point I'm stuck deeply in the support trap.

</comment><comment><USER130> [https://dilbert.com/strip/2018-11-22](https://dilbert.com/strip/2018-11-22)

;)

</comment><comment><USER131> To OP: your easiest path is to try to make contact with someone in a chosen company that is NOT HR. HR won't look beyond your resume if you have a requirement unchecked.

Leverage your network. If you don't have one start building it. I personally think it's easier to identify companies that you'd like to work for and focus on those vs. a shotgun approach.

</comment><comment><USER132> Usually it's not related to checking boxes. Both HR and recruiters closer to the actual work know it's not what makes a good employee (image a guy that check all the boxes but is an insufferable asshole and can't produce any value).

What you need to show in a job interview is your ability to produce value, work in a team, work until tasks are done rather than until the clock is up, a salary in line with the company's budget, etc.

It is disastrous for any company to hire negative value producers and is usually the biggest focus of any interview. When they ask if you know this or that tech, they mostly look at your ability to be excited, have an opinion, ask a few clever questions rather than say "Yes and I'm a rockstar" or "no and I think you shouldn't ask but provide training".

The best interview is when you do the interview, and start understanding all their problems and business in front of them. The simple fact you ask "I'm rejected by job interviews, why is on-the-job training dead?" is a bad sign, I feel. I would ask "How can I reskill to help companies more?" instead.

</comment><comment><USER133> I trained a guy that was a analyst and now he is a great dev in my team. I am working on getting another non-programmer to train to learn Python. I find its much easier to get devs this way. You just have to have a self motivated person willing to learn.

<comment><USER134> Hello tmaly,

I'm a non programmer who has been going to self-taught route studying to become a developer in Python. I'm willing to learn and I highly motivated to become a better programmer I could enter the tech/finance industry.

It would be great to get any advice insight from you. Not sure if your post was for non-programmers at your company or for outsiders who are willing to learn Python and programming from you to add more developers to your team? I'm just trying to find a way to break into the field of professional software development that involves the use of Python programming.

Please feel free to contact me at your earliest convenience. If you like, my email is:

firstname.lastname@example.com

Thanks.

\--K

<comment><USER133> I just replied to your other thread with information on how to apply.

Best regards,

Ty

<comment><USER134> Hello Ty,

Thanks for the prompt reply. I appreciate the help you provided in the posting along with info from the other thread. It has been quite helpful.

Much thanks,

\--Kwaz

</comment></comment></comment></comment><comment><USER135> A good quote I stole from r/sysadmin: Any Job should pay you twice. Once in Money, and Once in Expereince. That experience is paving the way to your future. If it stops paying well in Money or Experience, move to a different job.

</comment><comment><USER135> Quote I stole from /r/sysadmin: Any Job should pay you twice. Once in Money, and Once in Expereince. That experience is paving the way to your future. If it stops paying well in Money or Experience, move to a different job.

</comment><comment> King-Aaron I just recently hired two junior front end devs who I'm in the process of training, although I did throw them in the deep end to see if they could swim.

Maybe extend your horizons and look further afield for roles in other cities/states?

</comment><comment><USER136> This is not a new problem, look at accountants and lawyers and what they have done in their respective industries. The key is for you to walk into the boss' office and ask for what you deserve with a well thought out case.

</comment><comment><USER137> This is literally today's Dilbert: [https://dilbert.com/strip/2018-11-22](https://dilbert.com/strip/2018-11-22)

</comment><comment><USER138> I think many companies simply don't know how!

Once big companies stopped investing in training because they thought they could push most new work offshore people gradually forgot how to do it!

</comment><comment><USER139> Facebook is doing exactly this. It is called the Rotational Engineering Program. Check it out: [https://www.facebook.com/careers/life/facebooks- rotational-e...](https://www.facebook.com/careers/life/facebooks-rotational- engineering-program)

I know we aren't the most favorable company these days. The recent press fury gets a lot of stuff wrong which does not help. But it is a really great place to work at as an engineer. I'm proud that Facebook is willing to try unconventional methods like this.

Disclaimer: I work for Facebook. These are my own opinions and not those of my employer.

</comment><comment><USER140> If you are not training junior devs you have completely and utterly failed. Quite frankly if you are not training junior devs, don't consider yourself a senior.

</comment><comment><USER141> There is no developer shortage. If anything the junior level is saturated. Good companies are afraid to hire bad developers because bad code is a long term cost.

</comment><comment><USER142> Most problems in the programming industry - and there are many - <USER4> ultimately be traced back to the poor socialization of its constituents.

</comment><comment><USER143> Because after a few years they up and leave for somewhere else, case in point:

> I'm 4-years-experienced ... looking for another, similar, position

</comment><comment><USER144> There's a shortage of cheap developers, not just any developers. Lower your compensation by 50% and you'll be hired pretty fast.

<comment><USER145> Yeah that's the problem.

</comment></comment><comment><USER146> See "why you're historically a shitty investment if your credit score is a certain number"

</comment><comment><USER35> There is a shortage of experienced developers, not just any developers. The irony is that the more developers out there, less percentage of them is experienced.

Training is possible, but in our fast-moving industry everybody wants something tangible as soon as possible, and proper training takes too much time without any guarantees.

Also, you can get a position being a junior, by showing your good attitude, passion to learn, and, sadly, sometimes, desire to overwork – companies like that, because you can grow fast, and will surpass your salary really soon, so they will get a loyal middle developer for price of a junior.

tl;dr: too long to educate a regular person (not a brilliant, a lot of companies will accept these guys) and too big chance they will just leave after some time, without bringing much value.

</comment><comment><USER147> I'm a senior developer and I hire a wide range of developers. If you want to contact me, I may be able to answer your question directly and also help you. My contact info is all on my Hacker News user page.

</comment><comment><USER148> I don't really get the question? The company I work for (and many others) hire a bunch of new grads who require a lot of training to become productive.

In your situation, I think you're making a strategic mistake. Don't say "nope, don't know anything about react". Spend a small amount of time to do a basic hello world, say "oh, I've toyed around with it and I'm interested in property X but I haven't used it professionally" and you will put yourself in a better position.

The other possibility, honestly, is that you're doing a bad job at interviews and your lack of experience in the relevant technologies is a convenient/polite excuse. That sucks, but there you go

</comment><comment><USER149> When you get your rejections, are you getting feedback that it's because you don't know X skill that it was on their checklist?

The developer shortage, by the numbers, is real, but it's not why companies can't hire. Let's say, in aggregate, there are 1,000 developers looking for work, and there are 5,000 companies trying to fill developer positions. If the hiring market were efficient, then each of those thousand developers would be hired somewhere immediately, and the shortage would be felt more acutely, since open positions wouldn't even be attracting resumes. But the hiring market isn't efficient. Each of those companies has dozens of resumes from that pool of a thousand developers, and for whatever reason, they're passing on them.

So why is the hiring market inefficient? Because there was this transformational shift that Silicon Valley started, and slowly went and infected the rest of the job market. Do you remember the days when developers used to have to wear a _suit and tie_ to work? Why was that even a thing? Because formal culture papers over the natural differences that exist between people on an individual level in order to try and help establish a baseline for productivity. When Silicon Valley drove a corporate culture shift, and people started to have an expectation that everybody who they hired needs to be cool enough to grab a beer with, hiring managers slowly started to filter out people who they felt personal friction with during the interview.

Is there a cost and risk to training people? Sure. But there's a cost (in management overhead) to hiring people in the first place. And people don't leave bad companies - they leave bad bosses. If it takes a company more than three months to train somebody, then either the person was woefully underqualified or the company is woefully dysfunctional. And if new employees are leaving you that quickly (frequently enough that it's not exceptional), then it's not for a salary bump elsewhere. Recall that those people who would leave that quickly, went through the same recruiter-interview-reject-repeat cycle you're going through now.

The sad fact of the matter is, hiring is now a numbers game. If you're looking to move, you need to spam recruiters and job postings, and give the process time. Last time I went through this (within the past year, not Silicon Valley), I spent four months with zilch, probably something like 40-50 rejections (including FAANG companies), and then I had six offers inside of a week, which also gave me leverage when negotiating.

Stop focusing on why some company didn't like you (your haircut? your sandals? your sense of humor? who knows, and why should it matter) and start focusing on finding more companies to spam with your resume. Good luck.

</comment><comment><USER150> Most people do not know how to teach.

</comment><comment><USER151> First of all the shortage of devs is mostly a myth. Companies that know how to hire don't have problems hiring. the problem is most software companies don't know how to hire and thus have a lot of problems. Or they're located in some impossible location like palo alto or San francisco and try to low ball everyone with salaries under 200K in a location where housing costs 3million$ plus.

About hiring junior devs. You have to understand, most engineers that interview you don't understand or perhaps simply don't appreciate the concept of ROI. So, they're not thinking, geez we can get a guy with a few years less for 20k less and still come out way ahead. No they're simplying thinking, we want the best possible talent, regardless of cost. Very few people in the hiring process actually know how much that developer will cost, nor do most people care. This leads to a huge bias for more experience developers.

Furthermore, the engineers that interview you may be excellent engineers, great at programming and design but probably have very little experience or training in Hiring people. I know when I started interviewing people I made mistakes. It wasn't until I had a good 5-10 people under my belt that I really got good at hiring people. Most companies don't dedicate much resources to training devs to do hiring, partly because leads and managers often don't know how to do it well themselves. this leads to all kinds of mistakes.

My advice to you, is try not to take it personally and think any less of yourself. Failing an interview isn't necessarily your failure, it could be the ones who interviewed you that failed. But, it never hurts to learn everything you can and always expand your knowledge. There's nearly an infinite amount of Free tutorials and learning resources online, so learn as much as you can.

<comment><USER152> It is far from a myth. If it was a myth, salaries wouldn't be increasing so much, while the number of developers also increase. The demand for developers exceeds the supply so much that this is possible.

Do you know any other major industry, where people with little or no formal training can get in and up so fast? Where people in their early or mid twenties routinely make 6 figures? I don't.

The median salary is now above 100,000. [https://money.usnews.com/careers/best-jobs/software- develope...](https://money.usnews.com/careers/best-jobs/software- developer/salary)

That's roughly on par with chemical engineers but whereas (almost) all chemical engineers have at least a bachelor's degree, an increasing amount of software developers have no other training than online courses and still make salaries that would make other professionals with 4-5-10 years of education envious.

I love online courses, but try get a job as a chemical engineer (or any other engineering job) with just some online courses. As a software engineer that would only be an issue with some of the most sought after places, like Google.

Yes, I am sure there are a few thousand petroleum engineers in Texas and other niches that make more than software engineers, but generally, engineers make less.

<comment><USER153> > an increasing amount of software developers have no other training than > online courses and still make salaries that would make other professionals > with 4-5-10 years of education envious

When oh when are we going to get these salaries in the UK.. because I'm not seeing them.

</comment></comment></comment><comment><USER154> The problem with hiring junior developers is risk. They could be junior because of incompetence or wrong attitude opposed to just lacking necessary experience. When hiring a junior you are hedging either competence or experience against expenses and hoping for potential. Potential is the magical ingredient and its hard to recognize before hiring somebody, which is why this is risky.

Conversely hiring really good seniors saves the company money even if a good senior is really expensive. A good senior can probably do the work of 4 junior developers while also introducing code that demands less maintenance into the future, which pay dividends over time.

What I see from some juniors who spoil it for everybody else is immaturity and unrealistic expectations. A hiring company is there to provide you compensation for work. They aren't there to satisfy some emotional fantasy or other self-serving justification.

Because there is greater risk in hiring juniors demand for juniors is lower and there are more juniors competing for those fewer positions.

\---

With all of that said above, the goal isn't to get a better junior job, but rather become a senior. Here is how I did it.

First of all I didn't want to be a developer. Travelocity couldn't hire competent front-end developers. It's like they didn't exist. The company saw potential in me and involuntarily relocated me into a developer position. If I wanted to stay employed I had to figure it out. I sucked really bad a first and felt like I was struggling in a vacuum.

After about a year of this my military job needed me to perform security assessments in Afghanistan. You have a tremendous amount of available time on military deployments. Just before deploying I started a personal project, which I continue to work on today nearly a decade later. This little code beautification project kept me busy and it forced me into deep learning of complex algorithms.

When you are deployed in a combat zone you have to be self-sufficient. You don't often have internet. At the time I was writing code on a small netbook with 16gb total storage, because it was durable and portable. I didn't carry around a bunch of unnecessary tooling. You simply learn to do more with less.

Once I got back to Travelocity I discovered I had surpassed some of my peers in problem solving and code proficiency. I was coding all the time even when I didn't have to. I had found every little bit of proficiency I had gained in personal practice allowed me to work faster which then allowed me to become that much more proficient like an accelerating force.

The primary distinguishing factor between seniors and juniors to me is self- sufficiency, predictability, and simplicity. I find juniors tend to spend most of their time living in frameworks, dependency nonsense, tooling, and configurations. These external things distract from predictability and simplicity. They certainly don't benefit self-sufficiency.

<comment><USER155> > The problem with hiring junior developers is risk

Yep, 100% this. I'm involved in a lot of hiring decisions. In the past few years we decided to take a chance on a couple of junior people who didn't pan out. Huge waste of resources. We're very hesitant to do so again.

</comment></comment><comment><USER156> False premise.

There is no shortage of devs. That has been a complete fabrication, made up entirely by big tech companies, in a propaganda push to promote more and more people getting into CS.

It's entirely so they can pay developers less.

<comment><USER157> Then why do developers get contacted by recruiters constantly? Every developer I know gets contacted. Yet no non-tech colleagues I know experience anything similar in their industry.

I'm not saying I disagree with you, I'm genuinely curious.

<comment><USER156> As someone else in this thread pointed out - being contacted doesn't mean anything comes from it.

It's EXTREMELY easy for recruiters to spam out messages. Since they're payed based on hires, it's a numbers game for them. Get as many people into the interview as possible.

How many of those interviews actually result in jobs? That's the important question. As this very post shows, there is a clear disconnect: HIRING is much less common than INTERVIEWING.

<comment><USER157> Sure, I agree with all of that. But spamming has to have a certain level of return in order to do it. There must be a tangible level of demand out there. Like I said in my first post, when I talk to people in other industries (medical, journalism, electrical engineering, etc), getting spammed by recruiters is utterly unheard of.

I only have anecdotal evidence, but so does every one else in this thread. Personally I have been receiving emails from the same recruiters in some instances for years. I'm not a stand out developer. I also know, again anecdotally, that when we open a developer rec at my current company, it can take a very long time to fill.

My gut says there is a shortage. How much of one is very hard to determine and how artificial the shortage is due to generally poor hiring practices, low salaries, or other factors is also hard to determine. But I find it very hard to swallow the idea there is no developer shortage at all, which is what sparked this thread.

</comment></comment></comment></comment><comment><USER158> I'm guessing you're looking for a job in a saturated market (west coast, NY). I'll suggest looking elsewhere at companies that are not primarily tech (but have large IT shops). I mean Fortune 500s, not mom-and-pop. And be willing to shift out of front-end, unless you just love UIs. The pay will be lower, but the cost-of-living will also be muuuuch lower. And you may have the opportunity to be a bigger fish in a smaller pond. It worked for me :).

Show those folks that you learn outside of work. Your silly Raspberry Pi project or learning a new JS framework for the fun of it shows that it's something you care about. But don't ever expect on-the-job training or mention it. Show that you'll pick up anything they need you too as the industry changes.

Nothing pisses me off more than peers complaining about not getting training. This is IT, our job is to keep up. If you're not getting it at work, then you need to work on it outside. It sucks, but it's true. Show that you're the teach yourself person, vs the whine about lack of training person. Unless you're pulling genuine 60 hour weeks. Then you're just getting ripped off.

Look at companies where folks put in 10+ years, vs. hot tech companies where 2-3 is the norm. They're more willing to invest in learners vs people who know everything they ask for. Honestly, I wouldn't trust a company that wants you to know everything you need to do the job, because they don't care about you developing. And any hiring manager who expects to hire experts in the position is a fool. You want people to develop, and you don't want them to come in with 1000 preconceptions about how to do X based on prior (possibly irrelevant) experience.

As someone shopping a position at one of those big companies where we have 1000's of developers with 10+ year anniversaries in a fly-over state, it's impossible to find folks with 2-5 years of on-the-job experience that have not only done contract programming.

We just hired a person with almost no relevant experience because they showed the ability to learn fairly unrelated technology in their previous position in a mom-and-pop setting. Everyone else who applied used "the tech lead/business owner rejected my user story" as the answer to every behavioral question and ended with "I accepted their decision." I hate behavioral interviews, but with a big company our hands are tied in the interview process and an answer like that just shows that you just work tasks.

Contract-to-hire is a rip-off that you should avoid unless you're jobless. No one invests education in a contractor because there's no ROI, and you'll never get any experience making decisions in those type of positions.

Also consider the fact that maybe you are not interviewing well. Make sure to show your flexibility, problem solving, self-motivation, and positive attitude, even if you think it's not necessarily work-related. If you don't have those traits, work to develop them. A lot of times interviews are more about these than technical skill. Senior vs. Junior is more about leadership than out-nerding your peers. At least if the interviewers know what they're doing. If they didn't then you're probably better off for not landing the gig,

<comment><USER54> There's no keeping up any more. It worked in the nineties, but stacks have exploded. Try keeping up with 50,000 MS employees or 100k floss devs, or millions of js devs.

</comment></comment><comment><USER150> More and more I think it's because it's difficult for companies to identify the capacity to be successful at this type of work early on. Partly because it's actually difficult, and partly because companies are really bad at identifying skills as a rule.

Instead they resort to the simplistic. Senior developers have made it through several filters. They've proven they can do the work, they've done it at several companies, and they've survived in the role enough to be promoted a couple times. That's just signal that they're less likely to run into problems, and that there's less risk the hire won't work out.

So, companies are lazy. Not intentionally—but because they're literally squeezing every ounce of time and focus on the very complex and wildly difficult task of managing a company and staying solvent and productive and going in the right direction.

They shouldn't be—they should have room for training and developing a talent pipeline—but this is the real world, and most companies can't even do basic company things really well, so the prospect of _also_ doing on-the-job training really well to de-risk the hiring of junior engineers seems pretty far out.

In addition, many hiring managers have learned the hard way what '5 years of experience' means, because they've had 5 years of experience themselves, and only on the 5th year of that figured out how to do their job in the way they now know it needs to be done.

It's not an arbitrary set of skills they know they need, but an experience working in an ecosystem in specific ways that they know are crucial. Experience is not necessarily just skills, but a sequence of realizations, hardships, events, and successes that teach you things you can only learn by going through them.

Hiring managers hiring for a Senior role and pointing to a checklist of technical skills are probably not being fully forthcoming—they're likely looking for someone who does not see their own value as a checklist of technical skills.

Not saying that's you necessarily, and they could certainly be wrong, but personally I've learned that when the team needs someone with 5 years of experience, it takes 5 years to develop it, and there are no shortcuts to gaining that experience. The one thing I've found that speeds it up is experience in smaller companies or starting your own business—you'll experience a lot more much faster.

That said, there are companies that truly invest in on-the-job training, and with a holistic business model centered around that as a core value, it can be successful. It takes a philosophy, though, that most businesses will never mature enough to reach, dare I say, especially tech businesses.

The one I know of is the Greyston Bakery in NY, which was started by a Zen monk named Bernie Glassman (who passed away a couple weeks ago, sadly). His book "Instructions to the Cook" is really interesting, and outlines how they made a policy of hiring anyone who wanted a job work very well. They now run the Center for Open Hiring that helps other companies do the same thing.

It would be pretty incredible to see a tech company embrace that kind of thing and really invest in hiring and development as a strategy. I'd almost imagine it as a merger of something like General Assembly with an actual product and long-term business. It would be interesting to see if the significantly greater investment would be worth it over the traditional model.

</comment><comment><USER159> They don't call it junior devs but "university grads".

Allegedly EA has found that the latter is cheaper and just as good as senior devs. Not sure what that implies but it is EA after all.

Then you have piece of shit companies in Vancouver, BC that pays about what a Seattle starbucks barista makes, mostly UBC and SFU students.

I've given up largely on the industry after spending two decades. What is happening is beyond commoditization of technical laborer, we are probably going to see high school kids among the workforce.

It's insane to ask people to commute 4 hours a day, do mundane unimportant tasks that managers who got where they are not out of merit but due to seniority, people stay behind long after 9-5 because they are afraid of getting fired, and then going home only to briefly eat dinner and sleep, to start the nightmare over and over and over again.

At least in feudalism days, you grew your own shit and didn't have to pay 1/50 of your earnings on an unhealthy fast food because the foreigners and criminals have laundered their money through the real estate and businesses have to raise their cost.

tldr: software is getting complex yet barrier to entry are none, expect shit.

/rant

<comment><USER160> > they won't raise salary.

Not while they can employ people at the salary they're offering

<comment><USER159> ^ this. the fact that some people can be pre-IPO yet hire mostly students who work for nothing, get all pissy when people ask for a raise for staying past 5 consistently, and to boot, writing fake glassdoor reviews because you can't hire actual engineers anymore due to the bad rep you built.

I don't know what kind of people would entrust their companies HR data to an organization run like a sweat shop.

When you walk in and see mostly Asian workforce, head for the exit. I've seen consistently again and again, immigrant hires who are used to working 8am~10pm in their country now bringing the same fucked up neo-confucian work ethics.

God I hate Vancouver. What irritates me is that criminals and drug dealers who have successfully laundered their money through the real estate are now venture capitalists, now seeing their net worth explode. Did time for moving drugs? Hey now you are a CEO of a crypto company. Used to be a serial killer for a gang? Now investing in local startups, calls himself VC lol.

I hate this corrupt ass backward world sometimes. I've lost faith. No. Fuck this, this isn't why I came to Canada, to be a glorified white collar slave. Sure as shit not going to be blue collar so what does that leave me? When society rewards and protects criminals and punishes those who play by the rules out of humane morals? What does this leave me with?

<comment><USER160> > When society rewards and protects criminals and punishes those who play by > the rules out of humane morals? What does this leave me with?

Europe

</comment></comment></comment></comment><comment><USER161> Companies used to do this. You might join working the helpdesk or as a manual tester, then work your way up. But now those junior, entry level jobs have been outsourced and offshored.

</comment><comment><USER162> Because training is hard. Harder than coding.

</comment><comment><USER163> Our industry simply thinks that the more experienced you are, the better it is. I can tell you from my recent experience that microservices, kubernetes and the cloud, in general, have made experience with old desktop apps completely useless, for example. Not only useless, but counterproductive actually, because you think you are doing the right thing. So, experience alone doesn't help.

Why do people still keep hiring more experienced devs then? Many times because of bad hiring management skills, or because they don't want to officially have to mentor a young dev. In the end mentoring happens nevertheless even with seniors, though!

The main idea is that a senior dev will be up to speed much faster than a junior dev. While this is most of the time true (especially if the senior dev has already worked with the same domain and with the same set of technologies used by the company she is applying for), it has some drawbacks. For example, not every senior dev is ready to change, to improve, etc. Not every senior dev has the same speed of learning and "hunger" of a guy who just finished his college. A young dev is typically more malleable than a senior dev that "in my previous company we did it this way, and it always worked, this is crazy what you are doing here", that is crucial to fit culturally.

This leads to the second part of my post. From what I see, this trend is actually changing, and while it's sad because senior devs can bring a lot on the table (like, typically they are less hasty than younger devs), it's also good that our industry is starting to understand we are not just a bunch of people pressing keys and moving a mouse randomly - the more keys you have pressed in your lifetime, the better it is.

More and more companies are "hiring for attitude", or at least they think they do. There is also a book about it with the same name, which I recommend.

Shortage of devs, as someone said, is a myth. Such companies should start wondering why they can't find the right people. Maybe it's them doing the wrong thing? :)

</comment><comment><USER164> Basically in 1981 Reagan fired 11000 striking air traffic controllers which broke the backs of American unions, permanently establishing corporations' privilege over humans. Ever since companies have been insisting that workers spend more and more so that they can be slotted into ever more specific niches without the company risking anything.

<comment><USER165> Unions typically protect existing workers by constraining the supply of new ones. At the very least, holding wages high constrains the number of workers a firm can afford. Unions are great as an employee, but I would not be pining for them as a job seeker, particularly a junior job seeker (seniority rules are notorious).</comment></comment>