I've gotten a couple of those "show up and we'll train you" jobs but with a catch - the hiring people didn't believe that "anyone" could be trained quickly to do it. But I convinced them that I could.

Now that I've been on the other side of the table for a while, there's no shortage of candidates looking for job, but there's a (real or not) perceived shortage of quality candidates. And the thing that makes it really screwy is that we don't even know how to train developers very well. CS programs don't teach the "art"/"instinctual" part of it, bootcamps don't, even many jobs don't. Yet the difference between a bad codebase and a good one can have impacts a project that persist for years after those first developers have moved on...

> We are not seeing the evidence we would expect to see if this was a tight labor market.

The evidence of a tight labor market is in remuneration. If the appropriately skilled labor was so abundant, then there’s simply no way to explain the remuneration.

You can use some pretty simple first principles to explain the hiring practices. If you were advertising a high salary position in a tight labor market, what would you expect to happen? I would expect a huge amount of low/no skilled applicants to apply, and a small amount of appropriately skilled ones. Anybody who’s tried hiring to a decently paid engineering position has seen this for themselves. How would you expect companies to deal with this? I’d expect to see rigorous evaluations being performed on candidates.

The software industry also has some additional confounding factors, in that it’s filled with low quality products (although for which there is still plenty of demand). The average software product is low quality and poorly coded, because that’s the only kind of product that the average product manager, technical leader or software engineer knows how to make. Software is a very immature industry, and a result of that is it essentially has no consistent standards for quality. So if you want to implement your own standards, you have to content with the fact that a majority of the labor market won’t be able to meet them.

I once interviewed a "senior engineer" who was nearly twice my age. I was very intimidated; his resume indicated that he should be the one interviewing me, not the other way around.

We chatted for a while, and I felt really good about him. However, I had a gut feeling I should just check to make sure he could do the equivalent of fizz buzz. I said something like "Sorry for this formality, I know it might be seen as an insult to your experience... could we do a bit of coding?" His resume indicated nearly twice as many years of C++ experience than me.

I took out my laptop and produced three function signatures - one passing by reference, one passing by pointer, and one passing a pointer by reference. I asked him to explain the difference between the three. With a completely straight face and unshakable confidence he replied "no difference, they are all three ways of doing the same thing". I asked some clarifying questions, trying to probe the difference between pass-by-reference and pass-by-pointer. Again, he answered extremely confidently and coolly (but incorrectly).

"Err, no." I replied. "This ampersand here is a pass by reference, which means c++ handles the referencing and dereferencing of the pointer automatically. It's much safer than the other two, where you are ultimately dealing with a raw pointer and need to check for null pointers before dereferencing". Immediately he broke out into an uncontrollable sweat; it was really remarkable. Before asking the technical questions, I felt really good about him. I wonder how many companies he has fooled.

This statement applies to software developers of all ages and fortunately it is very easy to identify these kinds of developers.

However, using the write an algorithm test for this can be problematic as it can easily eliminate software developers who are very good at coding and problem solving, but have chosen not to spend their time memorising the inner workings of standard algorithms, in the hope that one day they will be asked about them in an interview situation.

I don't need to know how to write my own hash table to know how, why and when to use a hash table.

I don't need to implement my own sorting algorithm to sort my list of items.

These and many more standard build blocks come pre-built and ready for use as part of the software development kit.

It honestly is shocking. I tend to ask a question that I think would be an easy 101 homework assignment, and easily a third of candidates fail it so poorly I could end the interview right there. Another third fail, but close enough to where there's a bit of hope if they did the rest of the interview perfectly.

It's basically a word problem that can be solved with a for loop, and you wouldn't believe the number of people who hard code for the values in the list instead of just looping through it (think 10 if statements).

Yeah, which is why in-person coding challenges became a fashion in the first place. It's shocking to see the number of "software engineers" who manage to engineer for themselves careers where they don't actually engineer software.

If anything, my personal beef with the classic FAANG interview problem is that it's conflating two very different skills. These are "hard" problems, and require some reasoning and logic in addition to coding. What's constantly surprising to me is the extent to which these skills are decoupled. It's routine to find very smart people with excellent math skills who can't code, and the converse.

And the really mind-bending thing to me is that of the two, it's coding which is by far the rarer skill!

I think the cushy salaries come from the fact that programming done right is extremely profitable. So the capitalists toss a chunk of money to the engineers.

For most programming jobs wages are lower now than in 1995. Back then, I had many friends who were charging $100 an hour just to build VisualBasic apps and they had more work than they could handle. And Phillip Greenspan has written that his company, from 1996 onwards, offered $100,000 to recent college grads. That was really good money back then, especially if you wanted to buy a house.

Wages right now only look good compared to where they were during the depths of the Great Recession. Over a longer time frame, wages look terrible, except for certain jobs at FANG companies.

I think this point is really key, more than the general idea that "there isn't really a short supply of good programmers." It's imminently easy for a rich capitalist to tell the difference between a factory laborer who works hard and one who does not, than it is for them to say the same about an engineer; the evidence is plain as day in front of you. Longer hours, more sweat, quantitatively more physical tasks done, period.

For engineers of most sorts, the signals are actually counter intuitive, a lot of the time. There's the easy cliche story of two engineering teams tasked to the same project (not necessarily even software only). Team A has a slow and steady road map, no drama, everyone leaves at 5pm, they never make any noise, mostly hit their deadlines, even if the deadlines are unambitious, etc. Team B always is fighting fires, huddled around someone's desk talking, always working overtime burning to make aggressive deadlines that are never quite reached anyways, always communicating with the wider company about status of issues and problems, etc. Which is the more effective team? Team B will definitely be "known" more in the wider company, and might have more individuals who respect them and think they are hard workers. If you took a "peer survey," Team B might actually still come out ahead. But they may still be a much less effective team for the larger business in a lot of ways.

Hypothesis:

There's such a flood of qualified labor that employers can afford to arbitrarily shrink the pool of applicants without significantly worsening their outcomes. Their behavior indicates that just the top N% of the market is enough to fill the needs of all selective companies. "Top" can be a semi-random filter, since the pool of basically competent people is much deeper than N.

(There's also a much larger flood of people who aren't qualified, which definitely complicates the process.)

All else equal, if employers simply stopped rejecting qualified applicants for arbitrary reasons, they could solve the "shortage" overnight and pay much lower wages that developers would still accept. But all else isn't equal. Their past decisions shaped the playing field, so now external-but-related factors like the housing market and competitors' responses limit their options in practice. They can't just take a bunch of people and drop wages, even though they "could", without disrupting other things that aren't worth disrupting.

Edit: Too late to delete, but this is not a good analysis. Companies are clearly feeling some pressure to do something, but there are too many unknowns in this to draw the conclusion, and a ton of factors I've ignored.

When they say that, they want phds, not entry level candidates