Ask HN: Why not more hiring of junior devs, then on-the-job-training? | Hacker News Reader

Ask HN: Why not more hiring of junior devs, then on-the-job-training?

367 pointsthe_antipode479 comments

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!)

View on HN

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.

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?

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.

I did this. I landed my first job out of school way below industry rates (like 2/3 typical junior in my area, mostly because I'm bad at negotiation), got a tiny (~2%) salary bump at 6mo and then nothing for a year. I never felt comfortable asking for a big raise, despite learning a lot and contributing a lot, and after a year the bump at 6mo felt more like a slap than anything. I jumped ship when another opportunity arose. They counter offered more than where I was going (double my current salary) but I didn't care, they had already eroded my trust (and confidence) and I didn't want anything to do with them any more (not that I actually said that, gotta follow my M.O.).

My communication skills are my biggest flaw, especially around things like negotiating salary / talking about how I feel with the job. My technical communication is pretty fair, but I turn into a brick wall when we approach higher level meta conversations. I had plenty of opportunity and I wasn't mistreated, but being paid half what you think you're worth for a year with no change in sight really does a number on your confidence as a new player, and I never spoke up about it. I'll accept if that means it's my fault for not getting myself a raise, but I also won't feel bad about leaving after getting on the job training.

If you want to keep your junior employees, pay them what they're worth now not what they were worth 6mo or a year ago. Switching companies is just the only way to force companies to reset the memory of what your salary used to be and reevaluate your value.

That said, based on your other comments itt, that may not be the case in your example.

Embed salary upgrades within the employment contract.

We already know jumping gives on average a 15% salary increase every two years, so you just have to beat or match that.

Now people might still leave for more interesting projects, but you get one of the larger motivational factors out of the way.

People often leave because negotiating a salary upgrade is way harder than navigating an interview.

So, unless your hidden motive is to have cheap labor just write down in the contract that every two year the salary will increase 15% minimum, unrelated to objective bonus and all that bullshit.

The you have it. The secret for training and retaining talent in a competitive market.

Give proper annual raises to pay people what they’re worth instead of barely keeping up with inflation.

After two years, you’re essentially a mid-level engineer and the money you can command is way more than what a junior developer with two annual “raises” is typically paid.

Pay them more.

Isn't this why most junior devs leave? Because they are getting crap junior dev salaries? Once you've trained them they are no longer junior devs. The market certainly doesn't think so.

I was lucky enough to get my first job when I knew very little and learned so much on the job and I am very thankful to the company for giving me that opportunity. I worked there for almost 3 years but for the last year I was basically doing an act of charity to the company (Fair because they did the same for me but there is only so long that I can work for almost free). They couldn't afford to pay me a livable amount and I was still working on super basic junior problems.

If they had an option to move up and work on interesting problems than I would have stayed.

I suspect many others are the same. The only people hiring juniors are the ones who can't afford to pay mid level devs and when the juniors become mid level what are they to do but leave.

> very smart, fast learners

Well that is your friends first problem!

For a smart fast learner your friend isn’t providing a benefit worth the cost of a couple of years of low job growth.

Your friend should look for candidates who are average learners, want a steady paycheck, and don’t want to do anything tech related outside of work hours.

People stick around when they're challenged, paid competitively, and treated like people/adults. I suspect that one of these has broken down.

Realistically it will work only when the job market liquidity is low.

Think of Japan, where changing job is like a lifetime event, training is graciously provided, since the firm assumed that your loyalty is guaranteed. Or in case of some companies in China, where they can sue you if you quit your job before the agreed years are met on your contract. Both seems undesirable to me personally.

> Does anyone have ideas about how to make this work?

Pay more. If they can make more money by switching jobs, you're not paying enough. They paid for their training by working for a lesser salary for 1-2 years, and it's not irrational for them to then want a competitive salary.

Frankly, I did the same. For me the reasons were:

- Personal growth: Devs in that company were nice, but not stellar (I was the most "senior" one after a couple years), so I couldn't learn much from my peers.

- Nature of the business: I moved from customer service to product development, which is a personal preference.

- Money: The new place paid about 40% more.

Graded salary based on a mix of tenure and experience, with clear performance goals tied to moving those salary grades up sooner. This works very well for our grad programme.

Also; most people leave managers not companies. So if pay is right, and the people are otherwise a good fit, it might be company culture that pushes them out.

Some companies in my home country have a clause in the contract which says approximately this: "The company will provide $FOUR_TIMES_MONTHLY_SALARY worth of training to employee. If employee leaves the company within first 2 years he will have to pay $TWO_TIMES_MONTHLY_SALARY back".

> 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.

There are already many companies that lock you in contract in exchange for comprehensive training.

Here's how apprenticeships work in Switzerland:

Before leaving school you try to find a company that is willing to take you on as an apprentice for a four year contract.

Time is roughly split 50/50 at work in the company and specialized schools. The companies will cover the cost for the school, and pay a small amount to the trainee (~550$ first year to ~1400$ in the fourth year)

On average companies lose money in the first 2 years, but make it up in the last two for an overall win. Especially for programming apprenticeships, this can be quite lucrative for the companies.

So even if they leave immediately after the four years, it is not really bad for the company.

Can't you make a binding / contract? My company did that with me. Basically forbidding me to quit for 12 months.

Ways you can do it in germany: hire. After 2 or 3 months to see if he is a good fit. Give him a bonus to stay. The contract allows you for up to two years without issues, maybe three. If he quits earlier. He must pay back the bonus back (Valles Heilung des bonus in german, healing 9f bonus) after a few months he won't have a chance to get something better.

You also can increase the salary in a bonus. Which he eeds to payback if he wants to leave early.

Is that not possible in America?

I have seen it work. I think that the key is in transition, company must change how it treats them as they progress. It is not just about salary and may not even primary salary.

They need (not just want, but need) progressively more and more autonomy, bigger and bigger tasks, more and more responsibility. It also helps when the company culture/management is such that they can talk openly about their preferences and dislikes. It does not mean they should get everything they want, but there should be no "punishment" for saying what they want.

Culture and individualized incentives. Build a culture that aligns with the values of people hired and performers. Most people are motivated by positive feedback incentives. Others are motivated by monetary incentives. This guides career growth.

Even if they leave, they will be back because most companies lack a unified culture with clear values.

Increase their salaries to fair market rates as they improve. Stop being a cheap bastard.

Rise their pay when they become competent

Pay them enough to stay?

I had a conversation the other day with some work colleagues where we were talking about a friends dad who just retired from working as an engineer at AT&T for something like 35 years. We made some jokes about how that would be unthinkable these days and the conversation moved on.

Loyalty goes both ways. If you want someone to stick around, incentivize them to.

My dad worked for the same company for about 40 years. My brother only recently left a job where he'd worked for over 20 years.

My sister and I are the only ones in our family who switch jobs every few years. Switching often seems to be better for our careers, though my brother has worked on some very interesting stuff. (All of us are in IT.)

That's hard to do at a startup though with FANG salaries and benefits being so extreme. You really have to double down on the value prop of small agile teams, culture etc. Even if you nail that it's hard to turn down 2-3x salaries.

This only works in a monopoly or oligopoly, where you can’t easily switch careers. If you were out of AT&T, your experience there couldn’t translate easily to other companies. This works even today: there are few ex-Googlers, because experience inside Google is most valuable to Google; there are few other gigantic search-first companies to move on to (OK, you can go to Facebook or Amazon or Microsoft and that’s about it).

So, unless you want the economy consisting of a few dzaibatsu-style monopolies, the “loyalty first” approach to hiring is unsustainable.

defined benefit pensions were a huge incentive

While I don't think you're wrong, I think the problem is modern corporate thinking. People are no longer expected to have a job for life, and to develop and progress at the place where they work. They are now disposable cogs. You don't repair/improve individual cogs, you replace them. So I think companies have brought it on them selves.

And to be honest I hate having to look for jobs every 2 years. If someone offered me a job for life, job security, development etc, I'd take it.

There is a schema that I've seen used in Nestle which is quite bad TBH: they offer a course that you have to pass for a position this guy was trying to get to. This training course was fairly long (4 years) and expensive for an individual, however the company would pay for it. BUT only on the condition the student/employee would finish it and stay in the company for at least 1 more year.

Now I hear you, they cannot force you to stay in a company (slavery laws and such). Well, the way it was structured legally is that Nestle was loaning money to the individual for Nestle's course. Then the debt would disappear as long as you stay the right amount of time. Oh, and also it was mandatory to take the course for the role this guy was trying to transfer to.

Of course, the employee would study on the side while working the normal fulltime job and even get complains for missing 2 days for the tests.

If I recall correctly (but don't trust this paragraph so much), the training was internal but it was preparing for 2 external tests (once every 2 years).

This is actually quite a common arrangement at larger companies in the UK.

I don't have a problem with it myself - it's simple to understand, and the company is giving you something of high value, and retaining your services for a minimum period in return.

This is common for consulting companies with MBA or field-related masters studies as well. The company effectively loans you the tuition money and forgives the loan if you come back for at least 2 years post-graduation. If you leave early you have to repay the loan with your own money.

I'm not sure this could work with normal raise-type compensation in the software world due to the difficulty of enforcing such a thing or clawing back money from people who leave early. The traditional way this was done was with pensions that ramp up with length of time at the company, but those are few and far between these days due to the overhead hit on financials.

So here’s something the boss of my previous company did when I went to work for him straight out of university.

First year I earned a low junior dev salary. Third year after delivering a few projects and company financials improving I received a 66% raise. Fifth year a 50% raise.

And I was not the only one. The idea of raises pegged to inflation seemed absurd in our company when based on performance and company income we could increase our salary by 50% or more every few years.

Sure we had one or two devs who came, trained up, got bored and moved on but by and large if you’re clear that salary increases are not always going to be single percentage points you get more longevity out of your employees.

...So why did you leave then?

Kind of curious about what you're saying. Essentially that when the dev is getting up to speed with that training they quickly become more valuable to the company but the company isn't willing to acknowledge it?

That's only part of it (although I have certainly seen that existing employees raises don't compete with the salaries of new hires with the same amount of experience at the same company).

Another part is that if you hire an inexperienced programmer, not only do they have lower productivity than an engineer with 2+ years experience, but they lower the productivity of at least one other senior engineer that needs to mentor them and bring them up to speed. I'd estimate that mentoring a new inexperienced hire would at least half the mentor's productivity for a couple months at least. If you hire someone that's already worked a couple years, that lost productivity was paid for by a different company.

One thing the current company oftentime couldn't offer is a change of scope and focus, bigger companies tend to be better since they have many more teams that work on very different projects.

Another observation I had is that the upwards mobility is easier in between companies than within the company. The sad truth is, most companies only acknowledge your importance when they are about to lose you. If they consider you are comfortable in your position, they have no incentive to promote you. So assessing yourself against the job market periodically is a logical and practical way to keep your career path in check, regardless of your company.

One part of their answer is that it might also not be well aligned with their self-interest. Someone right out of college might take any job they can get a hand on (e.g. webdev). Later after they've gained some experience, and also matured more overall, they might notice that ther are other areas they are more interested in (e.g. IoT), which the company doesn't offer and now they are in a position where they can easily choose such a job.

I had something like that happened to me at my previous gig where I was Head of Engineering (in Guadalajara, México).

We hired several good developers who were more or less jr. After an average of 2 years, 4 of them left to go to Google, Facebook, Amazon and some company in Austria.

For me it was an honor, a couple of them even told me that, they had been applying to those companies before but could not get in, and it was after they got into my team and got some specific experience, that these companies wanted to hire them.

In some other fields, it is expected that a Jr person will be for a couple of years and then "fly away". For example, I know it is a normal path for a just-graduated finance/economics person, who gets into a VC fund to get experience, and after 2 years he leaves for an MBA in a "top school". I've seen it several times (with people from VC funds that invested in companies I've been). That is something expected and accepted.

Personally I don't see anything bad for that. Maybe the only disadvantage is the "know how", but it can be mitigated if you establish the right documentation and knowledge transfer processes.

This isn’t a hypothetical for my team. We filled a position twice with a fresh out of school dev and both times they left after a year or two for senior positions with massive raises even though they were both on the fast track for such things at our shop. Now we just hire seniors only.

If they were hired away, then it sounds like your "fast track" wasn't quite that fast. Business jargon?

Why wait?

If you aren't giving juniors significant pay raises when they get good, you deserve to lose them.

But also, younger people (who are more likely to be juniors) want to get more experiences, find somewhere more suited to them, and have less tying them to a given location.

this only happens if the place training the junior doesn't offer them a decent medium/senior salary. This probably also means they won't be able to attract new medior develops, since they pay too little.

Prisoners dilemma.

New guys are expensive (especially in time), experienced guys are valuable.

If I spend a bunch of money/time on new guys I have less to spend on experienced guys compared to the company that just spends it on experienced guys. So, the companies that don’t train new can pay experienced more, thus getting the experienced guys.

But surely if they're leaving for a better job elsewhere, it's because the company that trained them hasn't increased their salary in line with their new abilities?

Playing devil's advocate here, but if this is the expectation, then it perfectly explains why the problem exists. If the company pays the training cost AND ups the salary consistently for the juniors, then why would they ever hire and train them? They can just hire them after they've been trained elsewhere, pay the higher salaries, but avoid any training and development costs.

This is exactly what happens in the majority of companies, and they only hire seniors. Which is what prompted the OP to ask the question in the first place.

Salary isn't the only thing that people are looking for. Especially if you're early in your career, your interests and abilities aren't clear. As you learn more, you find you enjoy one thing more than another, are better at some things and not at others. Also, early in your career, you have fewer options, so you may start out in an area that's not close to your specific interests.

I'd guess it's more likely than not that someone who's learning lots and quickly will find that they're better suited, and thus more valuable, to a different employer than their first employer. It's not simply a matter of raising wages. It's getting a close fit of aptitude and interest with the work at hand.

Maybe that wouldn't happen if companies would raised their employees pays... If the only way to get some substancial raise is to change job, what else could you do?

In my country you will have to switch if you want any significant increase in salary. At least at the overwhelming majority of firms.

Loyalty goes both ways and unfortunately most companies doesn't seem to understand that where I am from.

Maybe there should be transfer fees as in soccer?

https://www.wikiwand.com/en/Transfer_(association_football)

Is that a thing in any other profession, paying for the training company/instituition?

>I think the reason is simple: once the junior dev is trained, they will leave

Sounds like something a contract could fix.

> once the junior dev is trained, they will leave.

But this is exactly not how it works. The only job I stayed 3 years where I had gaps, told them in advance, and learned.

Where would you rather stay: the job where there is no learning curve or where you can learn something new?

I think the reason is that decision makers want to minimize all their risk, being okay if the employees manage a fair amount of all the risk.

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.

> new trainees leave when they realize they can get better salaries elsewhere

This is one of my biggest gripes about software companies, particularly larger ones. You hire someone fresh out of school and they work for you for 5 years? They damned well need to be paid at that point like someone with 5 years experience, not someone who started at a fresh grad salary with a nominal 3%/year raise.

I 100% agree with everything you’ve said about training people up “from scratch”. The most loyal teams I’ve seen have been in that exact same situation.

"The only worse thing to training employees and losing them is not training them and keeping them"

-- Zig Ziglar

I call this method of team building the "island of mistfit toys", it is something I practice on my team since I was a misfit toy myself.

I disagree that training juniors keeps them loyal. When you bring someone the island of misfit toys and they get some experience and success, they no longer see themselves as a misfit toy. But when they come in to the office in the morning, they look all around them and see misfit toys. But I am not a misfit toy any more! I can leave the island now!

Misfit toys are hungry people! They want to prove that they can do it, since by all other metrics they should not be able to. And once they have proven they can do it, they leave to find better appreciation of their talents.

I didn't have that experience. Possibly because I didn't see this great team as being made up of "misfit toys", which is a bit denigrating to be honest. My team was mostly made up of awesome people who were being overlooked by completely shit recruitment processes.

Built a team of over a dozen programmers the past year using a similar strategy. I was able to bring over a couple more experienced developers I had worked with in the past to serve as mentors and get things kick-started. Then filled out the roster with inexperienced but capable developers.

From the very start, we put a lot of effort in our hiring and onboarding process. We treat hiring as the beginning of onboarding.

Our company is smallish with a startup vibe but recently we hired a VP of HR with a lot of corporate experience and it has started going this direction, too.

And there I think you have the answer to the OP's question: companies cargo-culting their hiring process and strategy and succumbing to that tendency that Daniel Kahneman identifies as the root of all bias: WYSIATI.

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.

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

Having experienced my fair share of HR-induced job search frustration in the past, this is incredibly inspirational and validating.

> 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.

I think when people say they can't find good devs, it's not that they are only looking for seniors, it's that they can't find the eager ones you are talking about either. Amongst the realm of juniors, they are quite rare in my experience.

Perhaps they're just not making it past the filters. Have a look at the ratio of people interviewed to the number of applications filed. If it's particularly low, it's likely a case of a lot of false positives on the filters before the interview.

> 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,

When I ran my tech recruiting business, I made screening tech resumes a key part of the interview process. I could onky get it to work if I wrote the job ad myself (as a recruiter who talked directly to the hiring manager), told the interviewees specifically what I was looking for, and specifically coached them to find reasons to like people.

Did you do this in a product or agency environment? What was the typical talent bar for a green new hire and what was your financial arrangement with them?

>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.

Don't quit your job without your next source of income secured.

>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.

I've had 5 jobs now, each lasting about a year and a half at most, and I only quit 1 of them because everyone on the team was being replaced to avoid having to grant any options prior to an acquisition. Twice my employer went out of business entirely, another time they laid off 20% of their workforce to secure more funding, and most recently a company let go all of it's remote developers after a change in leadership.

While I agree you shouldn't quit your job without having the next thing already in place, at least in my experience this is a very volatile industry and you can't really expect to keep a job for a long time anyways. The odds may be better at a bigger company, but it still happens. One of the largest employers in my city just laid off about 1100 people.

I've been lucky in that I've been able to quickly find work after these things happened before, but I look at it like I need to be prepared to potentially have to go without work for months at any time. Hopefully my next job will be one I can keep for several years, as the constant job hopping really isn't for me.

On the contrary, I quit my job without having a job to move into, only $1000 savings and a credit card, and then moved to Australia.

Everything worked out well and it was the best decision I ever made.

Upon saying that, I knew that there were a lot of jobs available, and I was also willing to do any kind of job, not just software engineering. If push came to shove, I was willing to go back to working in construction or hospitality.

I also had a backup plan if all else failed, which was to fly back home and stay with my parents while I sorted my life out.

My advice would be to not quit your job without a plan and a plan B.

By the way, the next source doesn't have to be a full time job. Explore contracting as well. I have found that to be a great alternative to an FTE position, and have bounced back and forth between FTE and contractor. (Preferably on your own but through a body shop works too.)

It's not exactly the same skillset, but you'll understand and appreciate sales and accounts receivable much more after a stint of doing that yourself.

There's also an element of desirability in having a job. If you have a job, it means someone has selected you and is paying you to do certain roles. In and of itself this makes the candidate more desirable than one who has either quit or been fired.

This is good advice

To OP and aphextron: Keep your head up and treat unemployment like a full-time job. How many is "way too many" interviews? If you haven't been able to pass phone screens, you must identify the reason why. Interviewers and recruiters are looking for engaged candidates, so make sure you do research about the company and come up with some good questions to demonstrate interest. This is the main problem that I've seen with my friends that have "failed" phone interviews. If you need any help with soft skills, ping me on Twitter (info in profile).

Count me in the exact same situation. I left my last job because my mother in law's house was destroyed by Hurricane Harvey. I wanted to help fix her home, then move back to Chicago, and realign my career where I wanted it to go.

It has been a total disaster, exact same thing you quoted and your statement as well. Will I ever dare try to help someone else to that extent again? Or make an effort to better my career? No. Lesson learned, we're lucky to have jobs at all. I've done what both of you guys did, but for 6 months now. I feel at the limit of my sanity from all the interviews. I have so much to offer, a very solid background, solid references, I'm very well spoken and convincing- but I'm just not good enough or they're trolling the market as you so very well said. I have 10 years of experience, 8 in devops and 2 in webdev. I've started telling employers- tell me your stack and I'll be up to speed before my first day. I'm willing to work for peanuts.

At this point, I realize that I've picked my passion, but chose my career very poorly. My last company told me that the rule that HR had set for hiring was senior devs from the US, entry to mid level exclusively from from India. Going back in time, I'd have nothing to do with software. I would've picked a licensed profession, bonus points for one that offers a union. I'd probably become an electrician or do HVAC and start my own company.

I guess that's what opioids are for, to end ourselves. We are apparently not wanted nor needed in this industry, possibly the economy as a whole. I'm going to keep applying and interviewing, but I've now accepted that I'm going to slip out of the middle class. No way around it. Without my wife's public teacher's health insurance, I'd be in big trouble.

This economy and job market that everyone is talking about is a lie. If you're investment class, sure, things are great. There's an abundance of guys like us walking around. All the news articles saying how great it is had me completely fooled, I thought it was time to make my move. I'm not complaining about any of this, I'm tough as nails and forge on in every situation I've been in life. I can handle it, but I do think there's a good chance nothing comes up here I'm going to be delivering pizzas pretty soon. I do feel sorry for all the other folks who aren't as polished, have my resume, no criminal record, good credit, and without knowing someone at a company, outside of some very good luck, I don't think most of them have a chance in hell.

Why would you leave your job before having another one lined up?

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.

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.

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.

It is indeed negative, because not only they can break some things, but their code has to be reviewed thoroughly, and more experienced developers usually have to spend some of their time teaching them some concepts, which will slow down everyone.

Of course, not everybody is like that, but some people are, and here is the danger.

There's an article on the second group - The Net Negative Producing Programmer http://pyxisinc.com/NNPP_Article.pdf

> We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one. Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.

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.

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.

Unfortunately feedback has a price: senior engineers have to do more thorough code reviews, they may have to explain more fundamental things, and it all adds up. Some junior devs are independent and learn quickly with minimal feedback. Bless these devs, I love working with them. Some junior devs require a lot of time, and make the same mistakes over and over.

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.

I 100% agree with you. Over the course of my career, I've taken plenty of time, on the clock, to do such. Not necessarily with any particular direction of my managers, but just understanding that "My job is to solve problem X. Doing so requires learning tool Y, therefore, I'll spend a day of learning and an hour of coding".

Having talked to others, though, I find that a lot of folks don't necessarily realize that this is acceptable/encouraged. As I moved into senior roles, I tried to do a better job of conveying this. And overall, employers and managers need to do a better job communicating that doing this is expected/reasonable behavior.

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.

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).

I think this is the beauty of this approach as well (vs actively teaching skills). If somebody does not work out, you will know pretty early based on how they approach the learning in the first place.

On th job training doesn’t normally mean in a classroom, but reading docs and asking questions.

Understand, but I think the intensity matters here. If you are mentoring a junior developer and he asks you questions about every little detail (instead of working through some docs and trying things out), then I guess this is not the on-the-job-training you would like to offer.

To me this seems more like "common sense" than an unpopular opinion. As such I hope this isnt an unpopular opinion!

That's why it "might" be :)

I think in the HN community this is probably common sense.

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.

Personally, I think this is very dependent on the culture and work practices of the company in question. I agree that for the average company, training is very expensive. But I don't think it's universal.

If you have a strongly cross-functional, collaborative team, then a new person isn't nearly as much of a problem to bring on. As an example, Atomic Object is a midwestern software development shop that follows practices like pair programming, collective code ownership, short iterations, and a lot more. For them, interships and apprentices aren't a big problem, and have been key to their growth:

https://spin.atomicobject.com/2011/10/04/interns-and-apprent...

I also think it's worth looking at why people change jobs. I agree it's common, but I also believe that sucky jobs are common. If people leaving is such a problem, I'd like to see companies put more effort in to making them happy where they are. Not only would that be the humane thing to do, but it would make the ROI on investing in employees higher.

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.

> 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.

http://wiki.c2.com/?DryWaterhole

It also depends on the culture.

In Asia, it's not as cut throat as USA, where you shop around every 2-3 years. Japan they'll train you, and quitting isn't something that's easily done -- watch any Japanese netflix series about slice of life/normal life and you'll see the daily struggle or just read the news, or if you have the chance, go to Japan. Death by overwork is real and on the other hand, companies such as Rakutan will hire newly minted devs from schools that may know nothing and use the herd of workers to make them catch up.

Philippines and Indonesia is also similar with OJT training and filling seats.

Can't comment for anywhere else in Asia. But it is really 180 compared to USA.

Yes, this is common in India too. In fact, companies like TCS, etc are called 'mass recruiters' who recruit in bulk. There are satirical YouTube videos about them hiring by the kilogram. They hire indiscriminately, pay crap, in the the next 6 months people undergo on-the-job training. Some are kicked out, some are moved to better positions and offerings and the rest are contracted out to run-of-the-mill projects.

Back when I was graduating, we had TCS come to our Tier-I college. The recruiter started off by telling that the salary they will be offering was 250,000INR/yr (then about 7K USD/yr) and that those who found it too low were free to leave. About half the class walked out. The rest stayed, most were offered a position.

What do they do if you just stop showing up for work? Can they do anything besides stop paying you?

Oftentimes if the company is a USA startup, none of the experienced engineers have time to train or even mentor junior devs. A lot of startups want people who are "10x programmers" (however ridiculous that notion might be) or maybe it's less sarcastic to describe them as new hires that don't need any guidance or input, and will achieve maximum productivity after a short time adjusting to the new environment/toolset/workflow.

Also, you bring up an important point about time at the company. Anecdotal, but seems like a lot of devs spend 2-3 years at a company before moving on. That cycle is so short that the company doesn't think it's worth investing in junior people and doing so may even be considered counterproductive; the common view is that it's like investing in competitors. I'd like to think I'm wrong about that, but so far it remains a nagging impression.

"Not having the time" to introduce new engineers to the problem at hand, task, system or what ever is a recipe for wasting even more time in the future. It's very short sighted. Neither "10x programmers" or mere mortals can grasp a code base by reading it alone as by a thorough introduction.

I mean, a mediocre engineer that knows the system well is way more useful than an excellent engineers that just got his hands on it, for like half a year or more depending on complexity. If you give guidance you don't need excellent engineers. At least not as many. It's kinda surprising the way companies think of this.

Rather than officially allocating a developers time for introducing new employees or writing documentation for the system, Company 101 is to put 10 or 100 times the amount of dev time into catching up for the devs replacement when he quits, after he quits.

At the same time, these startups find it difficult to hire people especially when they have money but hiring is expensive in terms of time for a small startup team. This must be changed for the benefit of all involved - job seekers, company.

It doesn't have to be expensive, either in financial terms, opportunity cost or other people's time. That's exactly the problem we've solved with Skiller Whale - we make good training easy.

<plug> http://skillerwhale.com </plug>

As a Developer who was brought into the industry through this process, and now leading development of an online platform after leaving my last company, I feel there are definitely approaches my first company could have taken which would have kept me on for a lot longer.

Speaking with a CTO of a small web company recently I got to understand the issue from both perspectives.

CTO’s thoughts when hiring junior devs:

- Can be great for company but only if it makes economical sense I.e the developer stays with the company long enough after training

- From experience, the best devs from training move on to other companies soon after training

- Junior devs ask for frequent pay rises that aren’t viable for the company, holding the companies investment in the dev against them

Thoughts of a junior when considering other roles: - How respected & valued will they be old vs new

- How interesting is the work, and will there be continued opportunity to develop themselves and learn new skills old vs new

- Salary old vs new

- The potential for future career prospects old vs new

Good junior devs will naturally be very enthusiastic and eager to learn, and the company needs to support this through and beyond the training to keep them motivated and engaged. On top of this, juniors will want to see regular progressions through the training process in forms of clear recognition and increases in pay and responsibilities as they progress. If these are not given, it’s likely the junior will feel under appreciated / taken advantage of.

Progression through a training course like this is motivated by success, and rewards, not unlike video games.

In my opinion the best way a company can keep a junior happy is to follow this and apply some of the proven methods researched and applied all over the video games industry.

- Progressively difficult but achievable tasks (missions)

- A sense of accomplishment from these (contributing towards real projects)

- Regular checkpoints ( targets and 2-3monthly reviews to support these)

- Regular rewards (small but regular pay increases, matched with greater responsibility and clear recognition of progression in the company; mutual respect is important!)

The list goes on.

If an approach like this is followed, the dev is much more likely to come out of training with a great sense of achievement and an attachment to the company for the support and rewards that were received. I think this massively increases the chances of a dev staying on, Provided salary, job title and sense of respect are matched with other members of the team in similar roles. I feel this is something many companies don't put enough thought into considering the large investment they're putting into the dev.

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.

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!

Curious - are you in Germany on a visa?

I agree with this experience, I learned everything I know on the job.

I don’t hire any developer unless they can demonstrate they’re willing and able to deliver business value. Junior devs have a harder time demonstrating this ability.

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.

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.)

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.

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.

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.

> 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.

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.

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.

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.

> 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.

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.

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.

> 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.

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/...

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.

A very experienced programmer can learn a new framework in 2 weeks and start being productive - even if not not as productive as he/she will become in 1 year. But a junior dev won't become an experienced dev with 2 weeks of study, the productivity will still be that of a junior. Study helps a lot, but it can't replace real world experience.

> 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?

Because there are many things to learn and it doesn't make sense to learn everything just to get to the first interview at any company.

As a developer it makes sense to do one or two small projects with any framework just to see how it is, but that doesn't count as knowing the framework.

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.

I don't understand why people would believe there wasn't a shortage, when unemployment is so low right now. There was a shortage of tech talent when unemployment was 10%. Now it's like 3-4% (and for engineers probably half that).

How do you react when someone fails to implement the max of a list? And how do they react?

I can't imagine how awkward it is for both the interviewer and interviewee.

is it a major city in Texas, or middle-of-the-desert Texas? have you considered hiring remote? I'm not on the job market, I'm just wondering.

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.

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.

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

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)

If you don’t break you are not learning enough. What you said is right, process should manage things from being broken. Even a seasoned person will break things if he / she is overstretched for too long. To err is human after all. Junior folks break things is a lame excuse. Am a senior if 15 years is counted as such.

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.

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. :)

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.

> 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?

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.

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.

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.

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.

Nepal barely had computers twenty years ago, outside of expensive internet cafes.

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.

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 )

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.

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.

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.

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.

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.

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.

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.

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.

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.

In what ways is the gap this wide? I tend to think the opposite.

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 :)

> 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.

Actually, a bad hire is a long-term risk. Very hard to fire fast.

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...

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.

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.

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.

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.

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 ;)

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.

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...

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.

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.

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.

>>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?

Why, yes, I think what you're describing is a management problem: a) the new employee was given customer-impacting tasks without checking their competency properly, and then b) his work quality was not constantly evaluated in a feedback loop, allowing him to continue writing shit code.

I mean, you have a client LEAVE and the person still continues to do exactly the same thing? Excuse me, but that's not only the employee's problem.

At some point, shouldn’t his manager fire him if he is unwilling to write code in an “acceptable” language? Also, since he is a junior dev, why is he given any latitude at all in choosing what language or framework to use?

I think you're right in that one of the major reasons why companies prefer seniors is to reduce risk. But the agency in your story appears to have had such a lack of quality control that it was a disaster waiting to happen. Didn't you have any procedures to prevent things like this from happening?

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.

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!

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.

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...

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.

While this might sound like a good question on the surface, it does not get to the "root" of the problem. Let me explain ...

Yes, most companies prefer to hire people who already have the skills & experience rather than train "junior". This is not because companies don't want to develop the skills of their employees; it's simple economics. The biggest bottleneck in any company is experienced people. The senior engineers who already understand all the systems, have been to all the product meetings and solved many critical bugs in production. These people are the "goose that lays the golden egg". Most companies are looking for more of these "golden geese" who can be effective & contribute to the product immediately because the "ROI" on these people is 10x (or more!).

Training someone up from scratch in a key tech and all the companies systems usually has a negative "ROI" for the first 1-6 months and distracts senior people so it's a "lose-lose" in the short-run! Add to the fact that most companies have a "LIFO" pattern with hiring (the most recent hires are usually the people who exist first!), and many hiring managers (HR) are put off by the idea of hiring people who do not already have the required skills.

Consider the following often repeated quote/saying:

CFO: What happens if we train them and they leave? CEO: What happens if we don’t and they stay?

A lot of people have the mindset that training people costs too much time, money & effort and it distracts the key people in the company away from their focus (building the product).

This is not the fault of the company or the people working there. It's a "systems problem"; most companies simply don't have an effective system for "on-boarding & training" new people.

I've worked for several companies over the past 20 years (including starting my own twice) and have been responsible for hiring & training thousands of people.

Training people in tech skills, company culture & workflow simultaneously is a "hard problem". If you can get a "head start" on at least one of these areas the chance of successfully integrating someone is much higher. HR people know this so they want to "check" as many of the skills boxes as possible up-front. You as the "junior dev" can use this information to your advantage and invest a few hours up-front to demonstrate the necessary skills and make the HR/hiring manager's job much easier!

My advice to any "junior" person reading this:

1. Focus on your own learning/skills for at least an hour every day (preferably first thing in the morning).

2. Share your learning somewhere public e.g: GitHub or a Blog. that way the hiring manager reviewing your "CV" has a clear indication that you are "fast learner" and a "team player" who shares what they learn to help others "level up".

3. Pick the skill/tech/tool that is most valuable in your chosen industry/sector or even target it to a specific company you want to work for. e.g: if you know that AirBnB uses React.js https://stackshare.io/airbnb/airbnb you find and devour all the best tutorials for learning React.

4. Consolidate your learning into a tutorial of your own to show that you have understood the tech/tool.

5. Link to it directly from your CV/LinkedIn.

Seriously, this will take you 20h at most. You could get it done in a week and it will transform your "hireability" from "no thanks" to "when can you start?".

I know this because I have used this strategy to get jobs & contract work in the past to excellent effect. Investing in your skills and sharing your knowledge is the single best time-investment you can make. It's a 1000x ROI! Put in 20h of focussed effort and you will get an extra $200K in the next 2-5 years. Guaranteed.

My advice to any company wanting to solve the "problem" of hiring "junior" people and making them effective as fast as possible is:

1. Commit to becoming a "learning organisation" where everyone in the company shares as much of what they learn as possible.

2. Establish metrics for learning in your company! "What gets measured gets done". If there is no actively tracked & visible metric for each person's learning, people will stagnate and default to using their existing "hammer". https://en.wikipedia.org/wiki/Law_of_the_instrument what you want is people who are proactively learning new skills/tech/tools and then bring those skills into the company to improve effectiveness or build features that your current tech does not allow!

3. Systematically share anything that is not "sensitive" or "secret sauce" in public. Having private wikis with lots of learning is fine for internal use, but what if people could learn your "stack" before they join your company/team?

4. Hire the people who proactively contribute to the learning materials without being prompted. This is the mindset you are looking for: people who want to learn and share what they know regardless of getting paid.

Anyone looking for a proven example of any of this, see: https://github.com/dwyl?q=learn dwyl is a bootstrapped, profitable Open Source software company that shares all of it's learning in public. [disclaimer: I co-founded it!]

> 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.

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.

"Some people have 10 years experience. Some people have had 1 years experience 10 times over..."

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.

There’s a difference between junior and intern, which is essentially a neophyte.

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.

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.

That's what we did, too. As a company, we formalized our open source R&D activities (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.

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.

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. ;)

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.

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.

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 - senior shortage dynamic will persist.

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.

> 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.

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

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 :(.

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)

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.

Hi@theurge.com

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.

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)

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.

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.

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

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.

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...

I worked for a company that did this very successfully for a long time - they 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.

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.

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.

I agree. One of the best network engineers that I’ve met had an AS in Welding Technology.

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.

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.

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".

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. davedx@gmail.com

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.

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.

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.

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.

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.

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.

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.

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".

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.

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.

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.

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.

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.

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...

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.

https://dilbert.com/strip/2018-11-22

;)

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.

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.

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.

Hello tmaly,

I read your older and recent posts by you that your company is looking for junior/mid developers at Interactive Brokers in the CT/NYC area.

Well, I checked out the Interactive Brokers site and they have at least openings available listed on there what looks to be for Junior and mid-level Developers.

So, I see that you work for Interactive Brokers. Don't know if that still holds up but I wanted to check if the Junior/mid level Developer job is still available?

I'm a guy who has been going the self-taught route where I enjoy using and working with Python as far as learning purposes go.

And after quickly reading your post here I figured to reach out and try a somewhat different approach than the old cover letter and resume email method and contact you if you may have any info to this current opening at your company?

So with that said, here I am..and I wanted to inquire to find out if this opening is still available? If so, do you have a contact email to learn more about this position and the things you require in regards to the nature of the job?

My apologies in advance that this may not be the response to your post that you were looking for but I figured why not take a chance and try something different to reach out and learn what I can do to improve my chances to be part of the Interactive Brokers dev team.

Any help in this matter will be greatly appreciated. Thanks

--K

Also, tmaly... please feel free to contact me at pydeveloper22@gmail.com

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:

pydeveloper22@gmail.com

Thanks.

--K

I just replied to your other thread with information on how to apply.

Best regards,

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.

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.

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?

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.

This is literally today's Dilbert: https://dilbert.com/strip/2018-11-22

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!

Facebook is doing exactly this. It is called the Rotational Engineering Program. Check it out: https://www.facebook.com/careers/life/facebooks-rotational-e...

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.

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.

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.

Most problems in the programming industry - and there are many - can ultimately be traced back to the poor socialization of its constituents.

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

There’s a shortage of cheap developers, not just any developers. Lower your compensation by 50% and you’ll be hired pretty fast.

Yeah that's the problem.

See "why you're historically a shitty investment if your credit score is a certain number"

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.

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.

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

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.

Most people do not know how to teach.

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.

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...

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.

> 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.

Are the salaries actually increasing in the US? In Ukraine, they have been mostly stale: https://jobs.dou.ua/salaries/dynamics/

This is definitely one of the best responses I've read on HN. I agree with this - "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. "

Also the devs are going to be there for less than 18 months so there is no reason to think in terms of ROI

The thing is after failing for 8 months it kind of starts hurting.

The only measure for "shortage of devs", or rather lack thereof would be a pool of unemployed or underemployed developers who don't work at all or who work in a different field because they don't find unattractive jobs.

If that pool is small, as I believe it is, there is no room for the idea that there are enough engineers. "Knowing how to hire", attractive benefits, locations etc are only ways to outcompete other employers, not a sustainable industry-wide mitigation of developer shortages.

Not in the US but in the UK it depends if you do a quality check. Without quality, go to a consultancy and ask for Devs and you'll get them.

After you get hacked you get someone to ask some basic principles around the job, especially anything around security, and you soon see the lack of devs problem.

After a while you end up with the guys who glue code together, or the guys who call the MSP, in charge again and they don't understand the basics, so you no longer quality problem and you have an abundance of options again.

Is there any sort of training on how to go about hiring people? Other than experience of course.

I guess the best training is experience (I know, maybe not the answer you are looking for). If you hire someone and closely check up on how that person is doing in your company, you can get some feeling about what technical and personal traits are really needed.

I don't know about formal training, I can only imagine that something exists. But what also works is to get the company's recruiter more involved. Short of formal training, they can be a coach for those involved in the hiring process.

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.

> 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.

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.

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.

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.

Same thing, different perspective.

If I supply something (dev time, clean water) I think there’s no shortage; they just need to pay more.

If I demand something (dev time, clean water) I will say there’s a shortage if I can’t get it for a certain price.

There is shortage of experienced developers.

Big companies can hire more trying to get away from competition, but some people would go to startups anyway (especially recent graduates).

I agree. There is zero shortage of developers. I just left Google search. There, all the Dev's are PhDs and will drop everything to fix a non user facing problem at midnight or 1am. They all answer their pagers about it. There is no shortage of Dev's ... but ... these companies are looking for H1B slaves who work 24/7 and 60h a week times 7y of indentured servitude. There certainly is a shortage of Uncle Tom's willing to work for the Simon Legree FAANGs. The FAANGs are the biggest whiner crybabies on Earth about it.

There's no shortage of developers, but big tech companies are attempting to increase the supply of developers to reduce the cost of developers?

Depends where, the world is not USA

Europe has a real shortage in some countries

This. FAANG hires more devs than they need just to keep the rest of FAANG from getting them.

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,

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.

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

> they won't raise salary.

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

^ 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?

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.

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.

Because training is hard. Harder than coding.

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? :)

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.

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).

http://www.findingdulcinea.com/news/on-this-day/July-August-...

> At 7:00 a.m. on Aug. 3, 13,000 PATCO members went on a strike in violation of a law barring federal employees from striking against the government.

Reply on news.ycombinator.com