Elite tech companies have no problem with the current implementation of technical interviews.
Engineers whos skills range from Great to Mediocre don't have a problem finding a job.
Software quality has generally improved or stayed the same.
What's true is that Google and Facebook have such enormous budgets and such huge positive profiles in the talent market that they don't need to work hard to put together functioning teams. They're paying more than they need to and having to deal with more bad hires than they should, but it's for them a marginal problem.
You mean lots of companies are terrible at firing terrible engineers.
The argument is basically the current implementation leads to false negatives. What impacts does that have?
Presumably those very high-profile devs aren't lacking employment opportunities, even if it isn't at the elite tech companies.
Companies, from Elites down to pleb-tier, while perhaps pressed for resources, are still able to execute.
So why is the problem of false negatives a problem we should focus on?
The first N months of a developer's tenure at a job is difficult to measure because of ramp-up and calibration (even good developers might hop to different teams after getting hired based on work style fit issues). Whole projects can flounder and need rescuing so that attention to ineffectiveness gets deflected to group leads. Most good development shops will try to make things work for a new hire that isn't performing at the 6 month mark, and that process takes a few months.
Once the decision is made to fire, most big companies will PIP rather than fire. Sure, once you've hit the 7-8 month mark of poor performance, your severance from the firm may be a fait accompli. But the ultimate process to make that happen can easily be made to take more than 12 months.
Once you have a year-long stint at a company on your resume, you can bank that "experience" on your resume.
And that assumes a relatively well-run companies. Most companies aren't well run in this regard, and you can be a terrible developer but last 2+ years in most jobs. If you can reliably put more 2+ year jobs on your resume than 1-year jobs, you will end up with what will appear to most companies to be an extremely attractive resume.
Remember, many management-track developers only write code for ~8-10 years. Once you fail up to Dir/Eng, you're basically tenured.
Since almost nobody qualifies candidates effectively, failing up is a super powerful strategy for this field.
I've not hired anyone who turned out to be bad at coding, but I have hired people who had other performance related issues, which were difficult to suss out during an interview.
From my own personal performance, my approach to interviewing has led to far more true positives, than false positives, so I am biased towards continuing.
What are some examples of these?
Or, failing to complete tasks they've taken on, requiring other teammembers to step up in order to meet deadlines.
There are more extreme cases, like insubordination, theft etc, but they are pretty rare.
How are you defining "skills" in this case? "Skills" as in the skills needed to perform well in the traditional technical interview gauntlet?
If that's the case then you have a tautology on your hands.
And if not, then maybe it'd serve us better as an industry to try to find a better proxy than the traditional technical interview for whatever definition of "skills" we really want to optimize for.
My question is this: Why does the industry need to change the interview process?
If companies are able to maintain a quality bar of it's employees, and engineers are able to find meaningful employment, doesn't that mean the system, even if it has a flaw (false negatives) isn't really a problem?
Perhaps the problem is that many of us who write code, consider ourselves good at it, and getting rejected is a hit to our ego. We want to change how interviews are done solely for the benefit of our egos, when instead, we should understand that if you interview, you might get rejected, and that is okay.
Nothing is fundamentally wrong with the process, nothing is fundamentally wrong with you, and in 6-12 months, you can try again.
> My question is this: Why does the industry need to change the interview process?
Because at the end of the day the process makes very little effort to optimize for any of those metrics of code quality you just laid out, and purposefully offers candidates programming problems and working conditions that deviate significantly from those they're likely to encounter on the job for no apparent reason, thereby hampering its reliability as a useful proxy for developer skill even further.
> If companies are able to maintain a quality bar of it's employees, and engineers are able to find meaningful employment, doesn't that mean the system, even if it has a flaw (false negatives) isn't really a problem?
No, it really doesn't. Just because a majority of software engineers manage to stay employed, doesn't mean we should ignore flaws in the system and insist that it's not a problem.
And if you would, take a moment to consider widening the definition of "companies" you have in your mind when you made that assertion. Yes, the process works well enough if you're Google or Facebook and have a constant stream of candidates and can accept just about any arbitrary false negative rate because you have the law of large numbers on your side when it comes to hiring. But startups and many non-tech companies large or small (most of whom don't have a lot of developer mindshare) often won't have that same luxury, because every month wasted in the hiring process to a high false-negative rate will take you that much closer to the end of your runway if you're a startup, and to the eventuality of being out-competed by a more efficiently run, technologically innovative competitor if you're just another technologically stagnating company. Countless numbers of these startups and technologically stagnating companies die off every year, and likely in no small part due to their inability to attract, recognize, and hire skilled developers in a timely fashion.
> Perhaps the problem is that many of us who write code, consider ourselves good at it, and getting rejected is a hit to our ego. We want to change how interviews are done _solely_ for the benefit of our egos, when instead, we should understand that if you interview, you might get rejected, and that is okay.
I don't doubt this is _one_ aspect of why some people want to change the interview process, but I emphasized the _solely_ part because I take issue with that part of your assertion. Getting rejected hurts, sure, and that can certainly bias one's judgement towards wanting change for their own benefit. But that's certainly not the _only_ driver for why people want to change the traditional interview process. You can see countless well-reasoned, rational cases, that make no appeals to emotion, for the many issues with the traditional interview process, both in this thread and elsewhere, made repeatedly by people from all walks of the industry from both sides of the interview process. Some people definitely do want to change the interview process for purely selfish reasons, but that shouldn't invalidate any of the countless well-reasoned cases constantly being made against the traditional interview process.
> Nothing is fundamentally wrong with the process, nothing is fundamentally wrong with you, and in 6-12 months, you can try again.
I would offer the counterpoint that, if nothing is fundamentally wrong with you, and you can get accepted again simply by applying again in 6-12 months, without having made any significant improvements to your skill level, then that is a clear indication there's something fundamentally wrong with the process itself. It all comes down to the fact that the ideal technical interview process should optimize for vetting for developer skill, and do so in a reliable fashion, minimizing both false negatives and false positives.
The traditional interview process has been well known to to exhibit a high rate of false negatives. If your company is deep-pocketed enough and attractive enough to candidates that you can afford the false positive rate by virtue of your naturally high rate of hiring, then by all means, keep using the traditional interview process. This is a process that has been proven to work well enough for companies hiring under those circumstances, and it's likely that for you, the risks posed by the high rate of false-negatives won't outweigh the risks resulting from adopting one of the less well-adopted and well-studied interview processes.
For everyone else, however, I'd strongly advise very carefully weighing how much risk you're really taking on by accepting the high rate of false-negatives that come with the traditional interview process, and consider one of the many possible alternatives to that approach before jumping blindly into that calgo-cult.