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.
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!
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'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).
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.
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.
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.
As a point of contrast, consider American industry in 1942, as the nation mobilized for war. It doesn’t matter what profession you look at, the attitude everywhere was “Just show up and we can train you.” That applied to welders and bolt tighteners and also the engineers who designed tanks and aircraft. Every company was hiring and every company was willing to hire inexperienced workers and then train them.
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...
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.
^When I say qualified I mean the informal sense - is able to do the job, not has a university degree.
