Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why not more hiring of junior devs, then on-the-job-training?
367 points by the_antipode on Nov 22, 2018 | hide | past | favorite | 479 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!)




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.


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

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

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

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


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

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

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

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


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

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

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

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

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


> the company’s health plan was on the hook for a million in costs

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


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


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

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


How is the infant financially liable?


Maybe more civilized countries can offer them asylum. Its just incredible to what degree the US is fucking its own people and how unwarrantedly proud they all are about their country.


To some degree yes everyones life is ruined. The people with nothing still get some medical care, it's the working poor who make too much to get welfare but too little to cover expenses after insurance who are really screwed.

In the US only the wealthy ( millionaires ) are safe from medical bankruptcy and even they can get taken down by some issues.


The hospital bills a million dollars, the health insurance says, no we'll pay you $125,000. That's it. I don't know enough to understand how this situation came about, but the bill the hospital provides is often 2x to 10x the reasonable cost and the insurance company only pays the reasonable cost. And has sort of negotiated this beforehand with the hospital. This is the situation that truly ends up screwing people without insurance, because their only negotiating power is that they literally do not have enough money to pay.


This is really screwed up. "Everything is worth what its purchaser will pay for it" is deeply immoral when applied to life and limb. I can hardly understand how a democratic society can accept a system like this.

I mean, can you even imagine other areas of life where every person you purchase from attempts to screw you over by demanding 2x-10x of the reasonable fee unless you had the information to be aware of it? It would be impossible, because everyone would just take their business somewhere else.

But you can't exactly say "oh, I'm not willing to pay my life savings for this, I'll just take this 3 months prematurely born baby to the shop across the street, or maybe get it done in six months time instead, when it's more convenient.".


It's even worse because neither you nor the people treating you actually know how much cost you are incurring. You find out a few weeks later when you get the bill. Imagine if anything else worked like that?


> As a jr employee they’ll never rise to chief architect

Considering that only few people get to the top title at a big company (I think there is ~20 Technical Fellows in Microsoft world wide), I think that is a fallacy. If you work at a small company that grows, you're far more likely to become a chief architect.

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

Only applies to the US. EU citizens don't really have to worry about that.


The thing is that in a big-co, you don't have to become chief architect or CTO to have a healthy career evolution. You can be "just" architect and impact a much bigger team than the 10-people startup.


Technical Fellow is an academic and/or research position. SMEs don't have technical fellows, although technical fellows sometimes start their own companies.

Senior/Chief Architect is an engineering/production position, with limited scope for game changing R&D. In a typical 10-20 man shop the position is usually taken by the CTO, who will be usually be in it for the long haul for both financial and technical reasons.

Very, very rarely a startup will turn into a unicorn with hundreds or thousands of employees. You can get some way up the ladder when that happens.

But the odds are against it happening in the first place. And at the higher levels you'll still be competing with talent hired from outside.


> As a jr employee they’ll never rise to chief architect

This is so important, as a relativley junior developer at a 6 person web dev shop, the owner is the only other backend developer. I have no room for climbing, even if I get a job title upgrade or a raise, my responsibilities and the level I work at won't change. I will handle the day to day backend and the owner works on strategic choices. There is only so much impact I can make in this position


> There is only so much impact I can make in this position

I'm reminded of this talk : https://www.youtube.com/watch?v=hER0Qp6QJNU around the 8m30 mark is the pertinent point, but worth to watch before that to get where his point is coming from.


Big companies will spend money on training but personally I have learned a lot more at smaller places because I was able to explore a lot more and my contributions had a lot more impact on the buisiness overall.


So in a sense, small companies are the training. You pop in, learn what you can, and jump ship.


The holy Grail of small company is to get trained and keep getting trained at the same company as your trainer(s) rise to executive level.


As a junior, the switch job raise is much higher than that, especially if you decide to move to a larger / more active city (which is not that big of a deal as a junior). During my first job I got raised 12% over 2yearish, and swapping and moving to a larger metropolitan area brought an additional 30%-45% (depending on which offer you looked at). Now ofc there are other factor (higher life cost), but still that's massive.


Absolutely. Fresh out of school, I job hopped twice and ended up with >50% raise. Started at $40k CAD, 18 months on jumped for $48k, and 4 months later (there were other reasons too), jumped for a greenfield project at $65k.

The first job refused to match the $48k offer. I’d probably still be there if they had, a decade on. Awesome place, awesome people, but... student loans and wanting to not live in a dumpy apartment won...


I was able to achieve a 264% raise in the first 2 years of my dev life by switching companies and roles.

Startup -> Medium sized company

I didn't have to move states.

Edit: I'm a college dropout too. Rapid learner so I learned a lot on the job at the startup. Did a ton of tasks nobody else wanted to do (devops, automation, performance, tests).


> (for the local market)

There is no local market, at least not in the long term. Once a junior developer has acquired some skills and experience they're going to start looking at other markets where their market rate will be higher, and being less likely to have attachments that make it harder to move they will find it easier to move than more senior developers.


In big-co you can change team/product to get some change in you career.


Now assuming they got another three - four years of Soul Crushing big-co Life, that should be 7 years into their professional coding, turning 30s, questioning everything there is in life. Would they have rejoin their first company if they were given the same salary?


^THIS I have come into a job missing a particular qualification, but being the best candidate. Then I have worked my socks off, and had all the plaudits off senior management and colleagues.

But still I was being paid less than the job was originally advertised at, because of a missing qualification.

So I moved, yes. Pay people what they are worth to you, not what you think you can get away with.


It doesn't matter what his friend gives them. I can beat it _and_ for those who prefer just working on technical design and code with an experienced team, I can offer them that. No forced mentorship taking up your time. Since senior engineer mentorship is a different thing, I can easily give them a better job than the "you have to help train junior engineers" guy.

Altogether, this is the best approach. The guys at two years and slightly more of experience have learned on the job from someone else and you can get them for relatively cheap vs. the huge opportunity cost of having your senior engineers mentor people if they don't want to.


Care to disclose where you work/what your org does?


No, I'd rather not. Angry HNers are best kept on the other side of the online/offline divide. Pleasant HNers I hope to see in real life :)

The downside is I can't recruit off this user handle but c'est la vie.


One could argue that their "raises" were paid in training


If the only raise you give them is in training, then the only way they can turn that 'raise' into something tangible is by leaving. If this is your attitude and you're still shocked they're leaving you've missed something in your calculus.


Sure, but the baseline of comparison here is vs a situation where the job didn't give you raises nor good training.

And yes, the employer in OP's example should reconsider providing value through training vs straight cash.


In a static analysis. But in a dynamic analysis, the employee has learned some things and is now in a completely different job market.


Training was “paid for” by the low initial salary.


I don't think the OP indicated anything about lowness/highness of the initial salary. OP did mention that the training they provided was exceptional. That's kinda rare.


Maybe they simply can't afford to pay more. Big companies tend to have a bigger budget.


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.


I have been working for a"consultancy" (just an outsourcing place in reality). They low balled me on my initial salary but I was desperate to leave the previous job so I took it. After a year I was told I did a good job, but I saw not getting any increase because of salary bands. Like you this is not something I am especially good at negotiating.

Took me less than a month to find someone who was offering significantly better salary, yet the consultancy seemed surprised when I told them. Suddenly the salary bands became a lot more flexible.

I shouldn't need to have another job offer to get offered pay rise in line with inflation.


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.


I wonder if that job jumping statistics is "poisoned" by causality.

You could argue that head hunted employees that's a good match for the job they leave for probably get higher salary.

The current job of a dev is more likely to be the first job for the dev (after job jumping it's never the first job).

Since the dev age pyramid is quite base heavy, job jumping is a indirect measurement of more experience.

Just being able to job jump is a indirect measure that you are sought after and that brings higher wages.


The problem from zero to hero is more than that. Entry-level college graduate non-developer positions might net 50-60k even in the Bay Area. So if you hire a 22 year old with a degree at that base and then teach them how to be a react pro over the course of two years they will then be eligible for 100k+ salaries. That's a 200%+ increase that is very difficult for even modern businesses to take sitting down.

If Starbucks starts making coffee 3x as good will people happily start paying $12 for coffee?


>>That's a 200%+ increase that is very difficult for even modern businesses to take sitting down.

Because businesses would rather have a person leave and then hire someone at 1.5x or 2x their salary than just pay the first person 2x what they were making the year before.

This happens all the time. Employers want to have 2x people at 1x prices, and that doesn't work for long.


One place I worked "wasn't able" to give me a pay rise, yet they were able to hire 1 and a half people to replace me (one full time and one on split between projects).


I had the same thing happen: They co7uldn't take me from contract to permanent at the pay rate I was getting contract, but they could hire TWO younger men to replace me (both of whom left after six months of 10 hour days, 6 days a week at lowball salary.)


I am not business savvy so I am curious why businesses choose to do this.


It's very simple, really. If you only raise salaries on personnel rotation, you do not have to raise salaries of those employees that do not jump ship. You save a bundle if you have a large workforce.

This attitude introduces a skew where your workforce gets progressively filled with people who do not switch jobs. It's a dangerous outcome, to be managed with care. If you get stuck with those who do not switch jobs because they are too incompetent, you have a big problem. If you manage to get those who are competent but content, and not very concerned with higher earnings, you have the ideal result: stable, competent, performant team, with controlled costs.


If you can't pay the guy who has spend the last two years learning everything about your business and your tech stack the going rate for a programmer with two years experience, how are you going to afford new hires at that rate?


> If Starbucks starts making coffee 3x as good will people happily start paying $12 for coffee?

When Starbucks entered the market here, their $5 coffee was about 3x the price of the status quo cup.

Also, if businesses can't pay the market rate for labour (by definition, the money the employee can get in an open market is the market rate) then they don't have a sustainable business model.


Those positions are in exceedingly short supply. Also contact can follow whatever salary curve your local market has, so this whole point is moot


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.


It's not just the salary. It's often about personal growth and wanderlust. Let me try an odd comparison: after graduating, would you choose to live with your parents if they fed you even more and offered you an even bigger room with more furniture ?


Careful about using that analogy. While the Western world would most likely choose to leave, the Eastern world would more likely do the opposite.


It isn’t even true for the Western world. More like Northwestern Europe and those polities founded by people from those countries. Italy has a high rate of adult unmarried children living at home and it’s definitely part of the West.


As an Italian expat I can assure you it's not because people want to do that, but more due to the economical conjecture. Sure, there might be the odd one that is just "lazy", but p.much anyone you speak to <35 that hasn't left home yet will tell you that moving away from parental house is very high up in their priority, but they just can't afford that.


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.


Pay or being capped as the junior in other peoples eyes.

In my first dev job, which was a fantastic job, some gatekeepers wouldn't give up access or tasks that I was better suited for.

I was always going to be a bit younger, always the junior guy on the team, despite the fact I had relevant education and, in my opinion, was probably better at the job.

Eventually I left and they were upset, but I didn't like being held back. Not everyone is like that though.

Nowadays I build and run teams. I don't do any real technical work unless I need to show a junior a working example on how to do it. I'd rather watch them learn and grow.


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.


Smart fast learner is not in opposition to want steady paycheck nor with "does non tech outside of work". The two don't imply average learner either.


Sure - I’m saying you want a combination of the three.


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.


This may have been true for some industries historically in japan, however modern day softwave developers will change job every 2-3 years, same as in the west, for the same reasons.


Is that true for Japanese people, or others hired on the salaryman track? If you’re hired out of university by Toyota, Sony or Rakuten isn’t it expected that you’ll be there until retirement?


Shit, in China, it’s very common to jump ship after one or two years to get at 10-30% raise in many industries. Many of my students have done that.


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


What country is this from? In the US the case law is iffy and in practice it seems like companies aren't willing to go to court for it [0].

[0]: https://www.hrdive.com/news/when-an-employee-leaves-can-you-...


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


Which is mostly illegal in the developed world - its illegal in India but employers still try and enforce bonds.

You could go back to the real apprentice (no modern apprentice shelf stacking mc jobs) route but in that case the apprentice signs for x years and you cant make them redundant - and you also not guaranteed a job after it finishes


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.


Same in Germany, but programming apprentice and computer science major is a completely different thing, afaik also in Switzerland. No one coming from 3-5 years of unpaid (and depending on country expensive) university is up for this kind of payment and training.

Though the majority of devs would be better of with a programming apprenticeship instead of an university degree in the first place. Only a fraction of devs work on these hard technical problems or complicated architectures that are actually engineering and not just programming.


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?


Why would anyone want to sign this kind of a contract when most companies don't play these games? Even as a junior I wouldn't see this as an opportunity, I would wonder what is wrong with the company.


The company offers you 10k bonus with the condition that you stay at least one more year. Otherwise you have to pay it back.

If you intend to stay anyway or are not so keen on leaving, why should you say no?

It's similar to stock option vesting and that is very common.


What is "Valles Heilung des bonus"? I'm German, I have never heard that and it brings up nothing in google.

But yes these types of bonuses are common, especially as stock options with vesting. More so outside of Germany as far as I'm aware.


Roughly 2/3s of the states in the US have “right to work” laws, which basically means that either employer or employee can terminate the job at any time for basically any reason.


You are thinking of "At will employment".

Right to work means you can't be forced to join a union.


That's not what he is talking about. You can also always quit your job in Germany.

He is talking about payments that are conditional upon you staying at the company for a certain amount of time. Relocation bonuses and stock option vesting are a very common type. If the bonus is high enough, it makes it very unattractive to quit. He is exaggerating though.


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.


In my non SV experience, most people will leave for +20-30% though, which quite accurately reflects the incompetence (and/or ego) of managers. It does not even cover locating and hiring a new talent. Nevertheless they are happy to pay hiring agencies through the nose. Sometimes I wonder whether they get kickbacks from it.


you can stop wondering, many offer kickbacks.


> That's hard to do at a startup though with FANG salaries and benefits being so extreme.

Why is a startup in the early cash-poor stages competing for FANG-level people?


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.


I'm not sure I agree with the idea that there are few ex-Googlers. I am only one person, but it seems like there are a very significant number of ex-Googlers, likely more than current Googlers.


Not in these days we deregulated telecoms


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.


It is common in the UK and normally they are well thought out and have balanced benefit for both parties. I did dodge a bullet once in my career though where a bunch of mid level devs were proposed a course to take them to senior (and a 5% raise) but it came with a 2.5 year retainer.

I read all the docs carefully and I wasn't convinced by the course content so didn't take it. On the day the course was to begin, one manager pulled me to one side and said they really value me and would offer me a 8% raise—but I had to take it right now—he even had an amended contract and pen in his hand, open on the last page for me to sign then and there. I refused. I was seen as a bit of black sheep by management afterwards and sidelined.

Every dev that took it came to me over the course of the next few weeks and said they wished they hadn't taken it as they didn't learn anything they didn't already know and they felt like they'd been cheated. They could get out, but they'd owe the company something like £7,000 which gradually reduced each month over the course of the retainer.

It was a tactic to stem the flow on the revolving door that place had. The weird part is although technically and ethically it's by far the worst place I ever worked, I made so many friends there and the people were truly amazing.

Eight years later I'm still in frequent contact with several of them and we often reminisce and recall the crazy stuff that happened at that strange place on an almost daily basis. Looking back now it's almost comical, like something straight out of a Dilbert nightmare. But the stress at the time was immense.


By 'course', I had assumed the parent meant something valuable: a degree, masters, PhD or well-recognised certification, such as PRINCE2. But reading your comment, and again that of the parent, I'm now not so sure!

Anyway, my point is that my response had made those assumptions, as that's the kind of arrangement I know is common.


Yes, the only part is that it was mandatory. You should be given the option if there are conditions like that.


Mandatory only to transfer to the new role, not for remaining employed. However, the program this person was in was finishing, so it was either take that or stop working there...


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?


I left after 8.5 years...sometimes you move on for more than money.


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.


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

That is the theory - in practice it is a bit different.

It takes a lot longer to become a senior who can easily switch business domains and tech stacks than it does to skill up in a single business domain and tech stack combo.

Two years in house is easily comparable with 5-6 years on the market if you work in a complex domain and have a good training program.


For sure. Just saying that I think that is the argument.

Our team is about 70% guys who learnt from scratch on the job I think. We have very low turnover, and you don’t come to us if you’re chasing max compensation anyway, so we do not have those problems as much (we don’t pay bad, but you can certainly make more other places).


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


OH on LinkedIn:

CFO to CEO: What if we train our employees and they leave?

CEO to CFO: What if we don't train them and they stay?


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.


That’s the story of the island of misfit toys though; They were still fun toys to play with, but they didn’t fit the mould, and so didn’t get sold.

I don’t find it denigrating, but I also was a bit of a punk in high school, so it’s a label I’m comfortable with.


I think you might be comfortable with it. But, any one that isn't would smile and take your offer then leave as soon as some one comes along that doesn't call them a toy.


Oh yes, because I definitely openly call people misfit toys, especially when I have just met them and am interviewing them for a professional job. Come on, it’s just a metaphor I use in my head. Have you even seen the movie?


I'm not say you openly call them that. but, you have to be careful about subordinates. A lot of them like to smile and agree then be pissed behind your back.


not only that, but if you call them that in your head, it influences your attitudes subtly.

I spent a couple of years calling subordinates "minions" (before the movies, but remarkably similar mental concept). It took a drunken conversation with a perceptive colleague to change that. It was amazing how much my attitudes to my people changed after I stopped thinking of them as "minions".


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.

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.

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.


Minimizes the risk of hiring great people.


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.


this. The really great people we found were an absolute no-hope if you just looked at their CV. One of our best database folks was recruited into the company as a data entry staffer, and we only found out that they knew SQL from some breaktime chats. They were so unconfident about their skills that they didn't think they should/could apply for a dev position.


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


It is absolutely not unethical to remain somewhere once you've decided to leave. The agreement between you and your employer is that you provide your work in exchange for their money. If you're employed at-will then the company is free to fire you any time they think they're not getting their end of the deal.

Of course, it is more fun to work at a job you care about. But you are under no obligation to "care," and there's nothing wrong with keeping a job while you don't care until you find another one.


Having been through this recently I certainly empathize with feeling like you're doing something wrong when looking for a new job. What got me through it was realizing that if the company was looking to replace me they would do the exact same thing - it's just how business works.

That being said, as difficult as it is to continue to give 100% leaving well is very important for building references that could help you in the future.


It is not, absolutely not. Just think from the company side, they protect their financial interest first and in time of difficulties they lay you off with no mercy. There is nothing unethical in that as well. You just do your job in a professional manner even on your last day..


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


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


> When you quit, you lose leverage.

Not if you have any other kind of safety net, e.g. savings or frugal low cost lifestyle.


You do not owe your employer your true heart and soul. You exchange your services for money. If you are holding to that agreement you should not feel guilty about doing what is best for yourself.


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.


I have switched a few times in the last few years, one time was because a start-up wasn't paying us (two devs quit on the same day,I was officially fired for making enough of a fuss).

Not having a job when you are applying for new ones puts you on a back foot with salary negotiations, as you don't have anything to compare it to. However you do have a lot more time and energy to put into the interview process. Especially when people are looking for technical tests and you have limited spare time and energy after work.


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.


In Australia, you'd probably make more money in construction vs software engineering.


That doesn't necessarily mean you'll be happier, however. Most construction jobs are very hard on the body.


I very frequently consider getting any job that involves being outside and doing physical work over sitting at a desk for 8 hours a day. I like programming, but I hate not being outside for vast majority of the day and what this lifestyle is doing to my body.


Do you really believe that? Being outside and getting exercise is really nice, but using your brain is so much nicer. Would you really give up a job that is intellectually stimulating for one that uses you mostly for your mechanical abilities?


Yes. I have worked manual jobs in the past(repairing bicycles, working at a warehouse and as a driver and for a while at a semi-construction job that involved being outside a lot) and I feel like overall I was more consistently happy. I would come home and do coding in my own time to satisfy the intellectual needs.


The handful of manual labor jobs I've had (delivering water, installing business projects), left me bored and tired at the end of the day. Any health benefits of the exercise I got was taken away from the boredom of waiting around for person/thing to get from point A to B. There's a reason why many construction workers are overweight.


Yes, but if you do construction or manual labor of any kind as a living (i.e. for years, decades), it leaves your body frail and broken. With programming, you only have to watch for relatively minor things like carpal tunnel and bad posture.


I'm reasonably certain that plenty of people do manual labor for a living who don't end up "frail and broken", and that decades spent in a sedentary position can have detrimental health effects beyond mere bad posture. And carpal tunnel is no joke.

Either can be taken to an unhealthy extreme, but on balance the human body benefits more from physical exertion than the lack of it.


My concern with manual labor jobs is not the effect on my body, it's the effect on the mind. Like I said in the previous comment, after a hard day of manual labor, sure I was tired, but I was mostly bored out of my mind. Moving some heavy object X from position A to position B gets less romantic when you've done it 50 times.

Sitting in an office desk for 30 years can't be good for you either, but if it's in a position to keep my brain active (even if my muscles aren't), I'd take that job a thousand times before going back to pure labor.

In fact, one of the most memorable parts of those summer jobs was creating a shoulder rest for the 25 lbs bottles to sit on, out of discarded plastic. I honestly can't remember whether it worked at all or not, but I definitely remember being far more interested designing and cutting this piece of plastic than carrying bottles of water.


> Would you really give up a job that is intellectually stimulating for one that uses you mostly for your mechanical abilities?

Do you find programming jobs intellectually stimulating beyond junior level? Maybe I have really bad luck, but all that I seem to be able to find - and see my friends doing - are the computer equivalents of lowest-level construction work. I usually have to step into other people's competences (e.g. contributing UX or even domain-level ideas) to get anything interesting from them.


Ride a bike to work. If you live too close then take a more interesting path to work that gives you some proper fitness every day.


I already do. It's not about the fitness.


I think I get what you mean. I do landscaping and misc. yard work on the weekends to get my "working outside" fix. I'm sure it's different for everyone, but for me I need to really break a sweat out in the sun once and a while to keep my happiness levels up.


>Most construction jobs are very hard on the body.

So are sedentary jobs. Obesity, heart disease and everything else that goes with them are no joke.


Maybe, maybe not. I was pretty happy when I was doing construction.


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.


From my experience of outsourcing to India, they give those juniors a real, paid projects to learn on and do very little babysitting and quality control on the code produced, reducing their costs, so they're still making them money while learning - but that results in poorly written code and creates all sorts of problems for clients.


>but that results in poorly written code and creates all sorts of problems for clients.

which is where the service contract comes in


So, in which group were you? The ones that left or the one that stayed?


Neither. I am not in software.


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.


I agree wholeheartedly that it's shortsighted. Junior devs need training and guidance from experienced engineers. I view the problem as a failure to take the long view of progress.


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 have a residency permit aka a Bleue Karte - which is tied to my employer. I have to maintain a job and it has to pay above 50k euros but it’s good for 5 years.


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


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


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.


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

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


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


I have twenty years of impressive experience, work is highly complimented, took me a year last time to find a job, was one month away from homelessness. “Shortage” self inflicted.


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.


Can you imagine how awkward it would be to discover it a week into their new job?


On the job you'd have a computer and just google 'list max min median <language of choice>'


If they are looking for 'get list 4th largest', they will need more than Google search...


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.


Houston. :)

Hiring remote would be an exception to the rule, for us. Not impossible, but you'd have to be worth it.


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.


Not GP, but I'll add my 2 cents. It's to test that you have at least a tenuous grasp of the programming language at hand. It should be an absolutely trivial task and take only a couple of minutes to do.

It shows you can iterate over an array and use conditionals, something literally everyone should be able to do if they know the language. These kinds of tests are a quick way to screen out applicants who are straight up lying about experience with a particular language.

It's not like asking them to write a sorting algorithm or implement Dijkstra's algorithm, which requires specific knowledge of algorithms and isn't trivial to implement. And it's not some obscure brainteaser that has no relevance to their normal work.

Iterating over arrays and using conditional logic is something I do every day. In fact, I'd say that's basically 80% of what my job is.


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


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

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

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

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


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

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


It's a fizz-buzz bozo filter. If you can't write a loop over a list, chances are you are a charlatan that can't provide any value as a programmer.


As everyone else has said, it's essentially just a fizzbuzz test without using FizzBuzz. I don't need someone to write an algorithm to compute max, but I DO need someone who can take simple verbal requirements and write a program to do it. Everyone understands max/min/mean/median (or can quickly understand if they are unfamiliar). If they can't take that concept and apply it to code, then I don't trust them with inevitably more complex requirements.

One problem we just encountered in production that I'm trying to work into a prompt was our impression generation created a large amount of duplicates. Identifying the duplicates and eliminating them takes some simple verbal requirements but has a lot of depth. If they cant't do max/min/mean/median, they surely can't do answer that (which our least senior developer was able to do, with guidance (mostly on optimization)).

We have other questions that are much more relevant to day-to-day tasks, but both kinds are important.


>One problem we just encountered in production that I'm trying to work into a prompt was our impression generation created a large amount of duplicates. Identifying the duplicates and eliminating them takes some simple verbal requirements but has a lot of depth. If they cant't do max/min/mean/median, they surely can't do answer that (which our least senior developer was able to do, with guidance (mostly on optimization)).

Does that problem not require separate thought processes though?

In terms of a max/min/mean/median style problem, the candidate needs to come up with an algorithmic solution to find those values. In the later case of finding duplicates, there is minimal (depending on problem complexity, I suppose) amount of algorithmic complexity and the focus is more on data structures; for instance, does the candidate know they could use a data structure like a hashmap or variant to find unique items with the drawback being an additional storage unit.

So, I guess what I'm trying to trace back to is how you say if they can't answer one then surely they can't solve the other, but (while relatively 'simple' problems) I'd argue they take different mindsets to solve. Obviously in the grand scheme of things one mindset works for both, but in this it can vary a bit.

Anyway, late-night thoughts so hopefully that's not a jumbled-up response.


A self declared mathematician that can't tell you what the answer to 4x + 7 = 19 is, is not going to be a good mathematician even though it's generally not the case that solving trivial algebraic problems makes up any meaningful chunk of a mathematicians daily work.

I think your point would be fair for more complex problems, but getting the max of a list is something anybody of a logical mind could easily do even without knowing any formal programming language. And for those that do know a formal programming language it comes down to the most incredibly trivial basics of a language - comparison/variable/iteration.

In other words a self declared software developer who can't tell you how to get the max of a list is not going to be a good software developer.


I agree with what you've said, though you have some mistaken assumptions.

They aren't exact duplicates. Instead, the code to send an impression was firing repeatedly, so it'd be more like that person refreshing the page once per second thousands of times (except the page content never changes if they don't refresh).

At it's most basic, you're essentially just finding chains of impressions based on lag from the last impression. In practice, we also need to maintain data integrity (foreign keys) and deal with several other issues stemming from common cases where the assumption 'if they are within X seconds, count as duplicate' doesn't hold.

So you could completely ignore performance and still have a question that could prompt a lot of discussion with a candidate (though performance should be part of that discussion). I'm not sure if we'll end up using it due to the relatively large amount of baggage associated with the problem (table layout and business requirements), I've just been toying with reducing the problem down to a simpler prompt that would be feasible.

I'm fairly new to interviewing/hiring, but I really like questions that cut across multiple 'areas of competency' and are amenable to asking followup questions ('what if we wanted to add X?'). Algorithmic questions have their place, but have less day-to-day relevance. We can teach algorithmic stuff on the job.


Reading this, one could be confused into thinking that you’re arguing that a developer shouldn’t have to prove they can write find max of a list. Is this task too below them? Does it not adequately demonstrate knowledge? What else?

I think what you’re might be missing is the basic fact that programming is so stupid lucrative, especially compared to the other jobs that are out there, people will do anything to get these jobs. I’m pretty sure you want your new hire to know HOW the magical library list.max is written. Writing code is surely more than piecing together other people’s utility functions and ideas?

By way of analogy, should your new EE hire be able to compute basic ohms law voltage drop over a resistor? We teach kids this formula. Is this knowledge too below a senior electrical engineer to still know? Of course not.

Finally, someone’s attitude towards answering these questions will tell you a lot about what kind of person they are to work with. If they are surely and refuse to implement list.max, well then, what will their attitude be when it comes to grungy code tasks?


It's a very basic filter for the right way of thinking. Even if you have never programmed it before you should not have any problem with it.

I interned in a medium sized cloud company this summer and they require you to complete a homework project within 4 hours before interviews. You have to setup an environment in your language of choice, query an rest api, parse some json, do a rather easy rearranging of data and post that back to the api as json. Took me about 1 1/2 hours with simple documentation and cleaning up my code. It really only asked basics you should know, if you ever worked with a CRUD app. They also told you before the clock started that it's about HTTP, REST and JSON so you could prepare.

I heared from multiple people from the local colleges that were friends with other interns that this project was way to hard and they had no way of doing it. But it was the bare minimum you needed to do your job there without having to be babysitted by a senior fulltime.


We use such things too, it's exactly to test if someone is at least in general able to code. Surprisingly often there seem to be candidates which look good on paper and talk like that but are unable to perform such toy coding tasks.

Even if you usually would use a library function, finding the max of a list or similar problems are still sufficiently simple tasks which every programmer should be able to perform. It's straightforward and not about remembering some complicated algorithm from some CS class years ago nobody ever implements themselves.


I don't mind getting downvoted but can someone please explain why - this is an honest question. Many devs have scoffed at interviews when I've asked them some really basic quesitons such as finding max element in an array.


I don't think you should have been downvoted. Likely, people expected you to already understand the purpose of the question because I called it a variation of FizzBuzz - which is fair as it's quite well known, though maybe not worthy of downvotes.

Those devs don't understand the reality of interviewing or take offense too easily. The reality is that people lie on their resumes, which makes such questions necessary. If they can pass, they can feel scoff all they want, but they had best answer the question or I will assume they are acting to avoid showing they can't answer it.

It's an unfortunate waste of everyone's time.


Yep, being unable to write a function to find the max of a list correlates pretty highly with being unable to do pretty much anything else in programming. It's one of the simplest possible things you can do.


You don't need to write one but if you have only a little bit of coding skills you definitely should be able to whip one up if you have to. Same for fizzbuzz or maybe invent some simple sort 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?


There are many fantastic devs that don’t chase fashion.


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

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


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


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.


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


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.


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

Ty


Hello Ty,

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

Much thanks,

--Kwaz


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.


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

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

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


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

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

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


Job reqs kept open but not filled, as mentioned up thread. Recruiters chasing an elusive paycheck just like candidates.


That doesn’t add up to me. In my experience a lot of the recruiting comes from engineering managers, the CTO, CEO etc of the company.

On top of that, this recruiting has been at a fevered pitch for at least 4 or 5 years. If it was as unfruitful as you claim, I’d expect the recruiters to have learned that by now.


Spam is known to be a numbers game, don’t know what else to add.


Then I come away unconvinced. I just can't imagine recruiters are going to spend all this time making such little money. People naturally gravitate to where the demand is.


Just because they're being contacted doesn't mean job offers actually come out of it


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


Ageism is a thing. Not many experienced folks under thirty —> more fabrication.


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.


Wow, I would not want to work with this person!


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


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

Open markets don't have shortages, those are caused by price controls. In a market the product is always available to the highest bidder, unless there are zero suppliers at any price which is obviously not the case here.

But "shortage" sounds like a problem that needs to be solved by some kind of external intervention, whereas "wages are high" is more of the sort of thing people like to see in the economy, and is not actually a problem at all because the high wages on their own are sufficient to attract the necessary talent to the industry.


Law of supply and demand. If supply increases but demand stays the same then the price will fall.


It's more complex than this, as there many supply and demand interactions relevant when creating a piece of software. The company selling the product knows what price it can ask for the product in a supply and demand market. This price dictates what costs are acceptable when producing the product, and this also has impact on how much they can offer the developers.

They may be able to hire more devs if they increase salary, but this would mean that the price of the end product would become too high, and they would go out of business.


Depends where, the world is not USA

Europe has a real shortage in some countries


This isn't reflected in the wages which are terrible in Europe compared to the US.


Economies aren't that simple.


Ok then, can you explain why wages for programming jobs are low-ish in Europe even when there is, apparently, a shortage?


Maybe there is a shortage because wages are low thus people are not programmatically attracted to the field? ;)


These are just my thoughts, take them with a grain of salt:

Success makes more success. If you're a billion dollar company, you can afford to pay more for employees. This lets you hire better developers, which lets you be even more successful. If you're in a poor country and you're trying to start a company... you're still poor. The fact that you need developers doesn't suddenly make you rich enough to afford the same wages a billion dollar company can afford to pay.

These lower wages mean that good developers in such regions are often swayed to move elsewhere to get paid better, leaving that original area even worse off than it was to begin with.

JetBrains has managed to build a globally successful company in the Czech Republic, where engineering wages are usually about a third of what the US pays. Call it luck, elbow grease, whatever. They did it. From a quick google search, JetBrains pays wages that are competitive with Silicon Valley. They can only afford to do that because they have been so successful. This success is making them even more successful, since they can afford to pay competitive wages, and it probably doesn't hurt (now that they're successful) that the cost of living in Prague is super low compared to much of Europe. But it's not like anyone starting a company in Prague can suddenly afford to pay $120k+ per developer.

This cycle of brain drain is very hard to counteract. Banks aren't usually excited about freely giving out large sums of money to try out this whole "paying people more" thing and seeing if that yields better results than the other tech startups they tried to fund, but failed due to a lack of talent, random chance, or mismanagement.

If a company becomes successful, but they're only successful locally, then they're tied to the low economic success of their area. They don't have any more money than other employers, so they can't pay wages competitive with other places.

I'm no professional economist or anything, so I'm sure I'm missing some of the nuances of the situation, but a shortage in one thing (developers) doesn't somehow imply an abundance in another thing (funding), it just means that there aren't enough developers available within the funding that these companies have available.

It takes a certain amount of dish soap to clean dishes, but an absence of dishes doesn't mean your home suddenly has an excess of dish soap... you might not have any dishes or dish soap!

If the companies had a bunch of money, they probably wouldn't have too much trouble getting developers to work for them... but without those developers, how can they get the money?

Banks don't write blank checks, especially not to people who have no track record of success. If someone has a track record of success starting companies, they probably don't need the banks to give them a loan nearly as much.

The whole thing is a catch-22. There are solutions, they're just not obvious or every smaller economy in the world would already be employing those solutions. Stuff like this might help: https://tulsaremote.com/ It's hard to know.


> I'm no professional economist or anything, so I'm sure I'm missing some of the nuances of the situation...

You could've just looked up the economic definition of "shortage". What you're describing is not an economic shortage, it's market equilibrium. Of course there's always more demand than supply for something at a cheaper price than what the actual market price is.


Your reply isn't helpful. It's not market equilibrium. It's a shortage, because they need access to a limited resource to achieve something, but that limited resource isn't there.

Google definition of shortage: "a state or situation in which something needed cannot be obtained in sufficient amounts." Huh, that's exactly what I said.

In this case, the resource is being consumed by higher paying consumers outside of the local market. The whole market isn't necessarily suffering a shortage, but there are absolutely local shortages within a global market. Everything is in equilibrium if you look at a large enough picture.


Look, if you want to talk economics and get taken seriously, you need to get your terminology straight.

It's not an economic shortage when you're in a store full of goods that you can't afford. It's a shortage when the shelves are empty.


The shelves are empty because all of the goods are elsewhere. We've already established that.

By your self-contradictory definition, the term "shortage" loses its meaning and ceases to exist. Because with enough money, you can always buy what you need.

If you need a few tons of platinum to do something and discover that (hypothetically) there isn't actually that much here on Earth, you could build spaceships to go mine it from the asteroids with enough money. Bam! No shortage.

In the absence of sufficient money to go mine the asteroids, though, there would be a shortage of platinum on Earth. Except, your definition doesn't allow for shortages, because someone just needs to come up with the money. Maybe no human can afford to access it, but it's out there in the universe somewhere, so there can't be a shortage, right? I don't think that's a useful definition.

It doesn't really matter if you take me seriously, though, so I'm not going to keep expending effort trying to convince you to change your mind when you're not willing to consider my ideas.


> The shelves are empty because all of the goods are elsewhere. We've already established that.

No we haven't. I can assure you, the "shelves" of developers that companies in Europe have access to are far from empty. It's a matter of price. Developers from all over the world would flock to Europe if the pay was outstanding.

Having said that, let's imagine the scenario where some country allows zero immigration, all its developers are employed and would not switch jobs at any price (which is the crucial part), then you'll have a shortage. I'm not aware that such a country exists.

> If you need a few tons of platinum to do something and discover that (hypothetically) there isn't actually that much here on Earth, you could build spaceships to go mine it from the asteroids with enough money. Bam! No shortage.

If there's nobody that can meet demand of the platinum at any price, then there indeed is a shortage. Platinum that is in the ground or in outer space is not part of the supply.

> It doesn't really matter if you take me seriously, though, so I'm not going to keep expending effort trying to convince you to change your mind when you're not willing to consider my ideas.

Nobody who has basic literacy in economics will take you seriously if you can't get your terminology straight. Seriously, just look it up. Your "ideas" are besides the point. Yes, I get it, there are companies that can't afford developers. That is not a shortage in the economic sense of the word.


Germany isn't poor though and the wages are lowish still (this comment isn't to discredit the validity of your comment).


Actually market economies are exactly that simple.


If market economies are that simple, why are wages that bad in parts of Europe? Are the business owners just greedy? Is that really what you think?

see this reply: https://news.ycombinator.com/item?id=18508361

If you think they're that simple, why don't you move somewhere dirt cheap, then call up some developers elsewhere and offer them competitive wages to move to that area?

Show us all how it's done! You have that kind of money, right?

In reality, needing developers doesn't suddenly mean you have lots of money with which to pay those developers.


Market economies are that simple, but the market doesn't stop at the borders of any single European country. Personally I'm happy being an employee for now and have no desire to move or start a company. But if you're asking a bank to finance hiring more developers then you're really barking up the wrong tree. You need to find investors with a different risk profile.


As it turns out, those investors are generally in the successful areas, though... so, they're not around to ask. I mean, am I wrong?

You're right that banks aren't going to be excited about that, but if you have no local billionaires looking to take a risk, what are you supposed to do? Move to an area with lots of investors? That just reinforces the cycle of low wages in the area you moved from, it doesn't break it.


Lack of mature capital markets is a legitimate problem in some countries. But that's completely separate from any labor shortage.


It’s a common misconception but there are rich folks in poor countries, and they can be potentially be persuaded to invest locally.


Then why aren't they already investing? Why does their local economy not already have companies paying high enough wages to attract highly talented developers, due to their careful investments? Those wealthy individuals can be convinced, perhaps, but only if they're open to idea and the risk to their own personal estate.


Sometimes the country is disfunctional. Sometimes those in power are profiting from it.


In Europe it's even more like GP said. They salaries are even less adequate than in the USA.


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


Facebook Amazon Apple N? Google?


Netflix

https://www.investopedia.com/terms/f/faang-stocks.asp


Thanks!


Netflix. Common abbreviation for big tech companies in Finance.


Finance?? Those companies have little to do with finance--they're tech companies.


I think they are saying it is the term they use within the finance industry for those five companies


Thanks, that's exactly what I was saying.


Maybe they meant that's the term used for those 5 tech companies in the finance industry?


Source?


Stories told to me by ex-FAANG recruiters.


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?


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

Europe


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: