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

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.

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

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

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

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

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

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?

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.