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?


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:


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.

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.

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