My observation has been that the causality is the other way around: the pointless mindgames of employers trying to find "the best" people via interviews led to job-seekers finding ways to game a system that was rigged against them.
However, regardless of "who started it" in this round, ultimately, it is unquestionably a situation we can lay at the feed of industry, which abandoned decades ago the practice of actually training new hires for their positions. Sure, there are prerequisites they can expect (eg, in a programming position, you can expect some level of school learning or experience with programming in general, or particular categories of program/lanugauge), but the degree to which employers are willing to train people on the stuff they use has declined precipitously since the late 20th century. This is a well-known phenomenon, and it is substantially responsible for the modern arms race between job-seekers and prospective employers: if you know that whoever you bring on will get 3 months of well-designed training for the role they'll be filling, you don't need to spend 6 months vetting them over 10 rounds of interviews for an entry-level position.
The situation is bad enough that even for a moderate-sized codebase a newly hired employee is expected to contribute within increasingly (decreasingly?) short time. Getting familiarity with existing codebase is one of the most specific levels of training "on position", yet even that training is deteriorating to shorter and shorter times.
Yes, looking at big company interview processes, it can give you a huge unfair advantage if you can know what kinds of technical questions would be asked ahead of time. It's kind of ridiculous and counter-productive that employers are obsessed with selecting developers who can solve problems under time pressure.
The kind of developer who writes code quickly may also be the kind of developer who jumps to conclusions too quickly; this attitude is a huge problem in the medium and long term when working on any decent size project. Choosing sub-par solutions can trigger a cascade of negative consequences for the project over time. Often, it's better to have developers who are really thorough and don't move to the next stage until all reasonable possibilities have been considered.
The people who can solve problems quickly are often not the same people who can solve problems optimally.
The current system seems to favor fast-moving code monkeys with zero understanding of architecture or security.
not arguing this but, the assumption here is a certain kind of production web developer and similar things.. not all coder problems are hired this way.. unfortunately, ranks of new company leadership actually do not know themselves about this, dealing with money and personal power relationships daily.. so they copy others in the hiring practices and so do the personnel and low-level managers, who are vulnerable to termination themselves..
an industry expanding into distant lands with telecommute for ever faster results with ever cheaper workers, appears to be embracing the AI interview and AI CoPilot assistant standard, to further reduce the bargaining power and individual contributions of employees for writing ordinary code
What I find weird is that the kind of people that they're hiring are the kinds of people who are easier to replace with AI.
AI is useless at big-picture reasoning when coding. It's only good for short snippets. Yet companies seem to reject developers who are good at big-picture, architectural thinking.
And architects generally know where security gaps are likely to occur. If their livelihoods are threatened, it won't take long to find alternative funding for their skills.
>he kind of developer who writes code quickly may also be the kind of developer who jumps to conclusions too quickly
I'm the opposite of this, but when I wanted a really high paying job, I just practiced a bunch to code quickly. That was actually my biggest hurdle, sometimes I'd understand the problem but I couldn't bang out actual working code fast enough.
Other times I'd get so nervous that I wouldn't have time to code that I'd stumble on the thinking part. Once I deliberately practiced for speed, I was much calmer in interviews.
And now I have a really high paying job. shrug. Now, it's not the best at finding outright geniuses, but making people solve slightly harder than trivial coding questions is a pretty consistent filter for people who can't code.
If you're good at coding and you can't do it, then it's just a matter of practicing a bit.
Yes but what kinds of people have the time to practice puzzle solving? Not everyone. For example I've been coding for 10 years, I used to be good at solving puzzles under time constraints but I'm not as good at it anymore because I prioritized practical architecture and other code design skills. I'm a much better coder today by all relevant metrics. My problem is that I sometimes run out of time during the tech tests. It's arbitrary... Sometimes I get lucky with the questions sometimes not. An unfamiliar problem will take longer to solve.
That happens anyway - nobody's payroll dataabse is running on leetcode puzzles, so if you hire somebody, they must spend time - sometimes months - on learning the new systems and getting the lay of the land and how the things are done. It's inevitable.
I think there's still training for positions (which often means - the company's specific tech stack) - it's what the "junior" positions are. If, on the other hand, the candidate more or less fits the tech stack and other requirements (domain knowledge etc.) already, the company can skip the training, and offer a "senior" position, for more money.
That's the reality of most software positions - they're hyper-specialized, and key competencies don't transfer between them. It's similar in medicine - a top cardiologist could at best be hired as a "junior" pulmonologist-in-training, even though he may be a doctor with 20 years of experience.
As an applicant senior dev, I found a small take-home + a discussion over my solution + just chatting in general has worked best. Chill atmosphere and not going by a checklist helped a lot as well, to both sides.
However, regardless of "who started it" in this round, ultimately, it is unquestionably a situation we can lay at the feed of industry, which abandoned decades ago the practice of actually training new hires for their positions. Sure, there are prerequisites they can expect (eg, in a programming position, you can expect some level of school learning or experience with programming in general, or particular categories of program/lanugauge), but the degree to which employers are willing to train people on the stuff they use has declined precipitously since the late 20th century. This is a well-known phenomenon, and it is substantially responsible for the modern arms race between job-seekers and prospective employers: if you know that whoever you bring on will get 3 months of well-designed training for the role they'll be filling, you don't need to spend 6 months vetting them over 10 rounds of interviews for an entry-level position.