Structural unemployment happens when the perceived skills of the workforce don't match the perceived needs of employers, so there is both unemployment and difficulty hiring.
A lot of engineers will tell you that companies are often expecting both too much (precise types of experience) and the wrong things (leetcode-type challenges, unnecessarily specific knowledge...), which leads them to pass over perfectly qualified candidates.
> Structural unemployment happens when the perceived skills of the workforce don't match the perceived needs of employers
https://en.wikipedia.org/wiki/The_Market_for_Lemons : when "buyers" cannot distinguish between good and bad due to informational issues, even the good products (or in this case employees) cannot find buyers. Market failure.
It might be improvable by the relevant parties getting together and agreeing on a curriculum and exams so people only have to take a test once, for example. But I think that's a long way off.
Of course, ChatGPT makes this a lot worse since it reduces the cost of fakes on both sides: fake applications and fake job adverts.
Unions have historically solved this problem. Non-union accreditation programs don’t seem to have the same effect, though in some industries they do have a positive effect on salary.
People have fixated on the word "union", but when a group of white collar people get together to set standards and gatekeep them it's called a profession. In the UK, this is usually structured as "chartered". It covers other types of engineers (see the repeated discussion of whether software engineering is engineering; iron rings in Canada; etc) as well as accountants and surveyors.
Older craft professions had guilds. Lawyers go back still further in history and have their "bar" exams.
But in all cases it requires imposing a costly barrier to entry in exchange for not having to prove yourself over and over again to potential employers. Nobody makes a lawyer do fizzbuzz before hiring them.
...because the state Bar Association has required them to pass a test just to show up. In most states the same organization requires a degree from an accredited law school just to sit the test (though I think there are like 2 states that let anyone sit the Bar Exam).
Put another way, everyone has to do the fizzbuzz leetcode test just to be in the industry. But you only have to do it once.
to qualify, unions may have solved this problem in the US. in europe, which has a stronger apprentice culture, unions don't have any role here.
(i am not saying this to criticize the comment but just to point out one of the many differences between unions in the US and europe)
the problem with apprentice programs is that they lag behind the changes in the industry. when i was in school there were none for software developers for example. there are now, but the second problem is that apprentice programs are considered of lower status compared to studying at a university. think blue-collar programmers vs white-collar software developers. the pay is also different.
i don't know anything about union accreditation programs, but i can imagine that they would be targeted at the available jobs, and with unions in the US having more influence at who gets hired, they probably can make sure that an accreditation actually leads to a job.
apprentice programs traditionally also promised that you'd get hired at the company where you learned, but this is no longer certain. together with the status and pay differences it is no surprise then that the number of people starting apprentice programs is declining.
on the other side university studies are not targeted at the industry. which only adds to the perception of candidates not matching employers needs. as an employer it is difficult to tell whether a candidate with a diploma is actually capable of doing the job.
unions are long established in europe, at least in western europe, and are a cornerstone of the social system. even white collar jobs have unions. this is in contrast to the US where unions are almost entirely non existent for white collar jobs like software engineering.
Union Law in a lot of "Europe" (a broad term so very dependent country to country) is much less adversarial with businesses than in the US.
At least in Western Europe, the big Unions won't fight tooth and nail over mass layoffs (eg. Volvo in 2009-12 Sweden versus GM in 2009-12 US) and make it a major political issue, as the Union Leadership has larger ambitions beyond their Union.
A lot of this seems to stem from the influence National Syndicalism had on most European unions in the 20th century compared to traditional Syndicalism in the US+UK in the 20th century.
>Union Law in a lot of “Europe” […] is much less adversarial with businesses than in the US.
US labor law was designed to be adversarial at the firm level because that gives individual firms greater power to crush unions and prevents sectoral bargaining and sympathy strikes. One can see the vestiges of “European” labor organizing in the film industry, which has an exemption to this that was grandfathered in.
You didn't understand the context. Unions in Europe are usually not involved at all in accrediting professionals in their fields. Thats what the conversation is about.
The 'guilds' seem to have a similar purpose here in Britain, namely that of providing legally-required accreditation programmes. However, these are only for certain trades, and I put guilds in scarequotes because they aren't as exclusive as the mediaeval form.
Re. universities, it was widely quoted a few years ago that more people graduated with a bachelors in photography during that year than there were practising photographers!
It would only make it harder for new grads, as unions aim to help their constituents increase salaries, which means paying non-union hires waaaaaay less.
Look at the Automotive Engineering industry in Ohio/Penn/Mich for example - a union contract engineer will earn a decent amount, but the majority of new hiring is non-union.
I'm relatively uninformed here, but isn't part of the union's job to propagate itself and ensure that there aren't non-union hires in the same industry and location?
> there aren't non-union hires in the same industry and location
We live in a globalized world where location doesn't matter as much.
Automotive Unions are good at demanding fairly competitive wages for their members, but this pushed margins significantly down, leading to vendors and even manufacturers in the Automotive industry to leave union-friendly states like MI, Ohio, and Pennsylvania for those that are right-to-work (eg. South Carolina).
A major reason companies like GM and Stellaris fell behind on the EV trend was because battery technology and automation doesn't fall under the UAW, so there were constant protests and strikes against EV manufacturing (eg. the UAW strikes a couple months ago).
Meanwhile, the Teslas, Hyundais, DaimlerBenzes, and Fords pivoted manufacturing to right-to-work states like Alabama, Kentucky, and Texas.
Imo, a big reason for the PHEV push recently in the US is because of UAW negotiations to protect legacy ICE builds which can be modified into PHEVs as they use most of the same parts excluding the battery portion [0].
Some of those interview questions have ridiculously short time constraints.
You need to be perfectly rested and well practiced in order to finish the exercises in time. Some of these tests seem to select for cheaters because only cheaters who either knew the questions ahead of time or who used AI to solve the problem could finish them in time.
Exactly. A lot of the problems asked of people are basically "do this multi week task that a team would probably work on at the actual company, except in an hour or two".
They also make you question whether you'd want to even work at a company with this sort of setup. Like, imagine a software engineering role where your boss wanted each project done within an hour, with no help from other developers or external sources, with a tech stack you're only told about the day the problem is given to you. Would anyone really consider that a good (or even tolerable) working environment?
My last take-home wanted a sudoku solving app coded from scratch in 30 minutes in an unusually restricted online sandbox IDE that would disqualify you if you defocused the window.
I have 28 years of verifiable professional software development experience on my resume.
I would just close the window 1 minute in because that's just ridiculous. Unless you've already done this before and play Sudoku regularly for fun, it would take you 10 minutes just to absorb the problem. Doesn't leave much time for coding. If you can't even minimize the window to read up on Sudoku, how the heck can you complete the task. The company will end up full of Sudoku enthusiasts who can barely code.
For my last online test, I wanted to close it within 5 minutes of reading the first question even though the problem was not particularly difficult, I just knew I couldn't solve it within 40 minutes because it was a problem that I had never seen before and was very disconnected from practical scenarios. I needed 20 minutes just to absorb the question fully. Also it was very late at night and I wasn't in an optimal state of mind.
Leetcode type challenges are just a proxy for logical habilities, which are highly desired for SWE positions. It's not meant to evaluate every ability. Despite imperfect, I don't know of a better indicator that has similar cost. An employer won't spend a lot more to evaluate with perfection how good we are with logic.
It really isn’t. Asking people stuff like N Queens, Trapping Rain Water, and other such questions is really about if you’ve seen the problem before and studied enough to solve them optimally in under 20 minutes while explaining out loud.
It really is about testing how much you prepared for the interview and not the job.
I interviewed at Netflix and Google and not once did I see a question that was on leetcode. I had to think very hard about how to solve each of their coding questions. However, they didn't need any tricky esoteric algorithms either which I think was really well done.
Microsoft on the other hand, did exactly what you said, they just pulled the classics, which I think is less helpful. I guess it filters on people who have a moderately good memory and are willing to study.
> wrong things (leetcode-type challenges, unnecessarily specific knowledge..
I'm curious about the dynamics of this. If leetcoding or requiring some specific knowledge is too much for candidates, those employers will not be able to find enough talent, so they will be forced to lower their standards and the mismatch should be gone, right? Case in point, I'd venture to guess that no more than 10% of the tech workers truly understand AI or stats or machine learning or basic college-level maths, yet magically millions of ML engineers or data scientists have popped up in the past few years just because the market had such high demand.
> If leetcoding or requiring some specific knowledge is too much for candidates, those employers will not be able to find enough talent, so they will be forced to lower their standards and the mismatch should be gone, right?
I'd revisit any train of thought that conflates access to capital with wisdom or intelligence. If someone invents a money printer then everything they do afterwards will be seen in a post hoc ergo propter hoc light as long as the original money printer still works.
For example, your statement assumes feedback loops I see scant evidence for in real life.
If the corporation as a unit were a perfectly rational actor, sure.
In practice, most corporations seem quite happy to collectively hand-wring over how they can't find new talent, squeeze everything they can out of the talent they currently have, and direct their existing personnel at direct profit-earners while letting systems gradually fall apart due to lack of maintenance.
Leetcode (or hacker rank or others) and other algorithmic qualification (have recruiter ask for years of experience in exactly X) is an understandable response to the automated firehose tools that allow applicants to deluge companies with applications with relatively low effort per app. Companies have to find some way to filter out the percentage that have very low likelihood of succeeding.
I hate it, but I don’t see a better way that doesn’t have its own limitations. (Referral of known ex-colleagues is a good one, but that’s limited in scope and has diversity problems).
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.
But when companies would "filter" you out because your resume didn't match some stupid algorithmic quirk, you have no way to even get to an interview without mass-filing to any opportunity that at least somewhat resembles the one you want. You don't know the rules of their gatekeeping, and have no chance to learn them because everyone uses slightly different but equally broken gatekeeping system. You know to have any chance you must pass this gatekeeping system. You know the chances of success are low, because you don't even know what they are looking for, and they can't tell you because that would invalidate their whole system. So, you need to send out a lot of submissions, to have any reasonable chance to even get to talk to somebody. And since you have to do that, you can't spend too much time on every submission. Hello, automated tools. It's a nightmare both employers and employees are trapped in, without any reasonable way to resolve it. Yes, personal referrals help - but what if you want to work somewhere where you don't have anybody to personally refer you?
Quite often perception of reality matches actual reality.
I've found it extremely rare to the point of almost being non-existent that what engineers think a company needs or should do is accurate compared to what a company needs or should do.
Probably to what company thinks the company needs or should do? It's rare - very - when a company really needs to do something unusual, which engineers wouldn't expect.
A lot of engineers will tell you that companies are often expecting both too much (precise types of experience) and the wrong things (leetcode-type challenges, unnecessarily specific knowledge...), which leads them to pass over perfectly qualified candidates.