A union doesn't have to be "workers for company X employees". It can be "web developers union" or similar - this is how the trades organize (see the pipefitters, and IBEW for some examples).
Neat thing about this type of organizing is that the union provides training and standardization paths. Both of those make moving between jobs easier.
They can also provide a standardized way of differentiating employee levels (e.g. union sets the standards for what a jr, sr, or whatever is). I'm not sure if that is good or not in tech, but it is a possiblility - and it's something that would definitely help employers too: rather than each company having to test each potential employee, a union certified X dev will have a certain skillset. Yes some X devs will be better than others, we're talking about humans here, but the minimum bars can be defined and the whole hiring process can become easier and more efficient.
Theres some interesting compensation challenges to get the idea of unionization more accepted in tech tho: stock based compensation and bonuses can get really tricky - something that I suspect is the real reason unions don't catch on more in tech.
> something that I suspect is the real reason unions don't catch on more in tech.
I think a bigger issue is the difficulty of measuring correctness and quantity of individual output.
For a classic-style of union in manufacturing, the standardized widgets coming off an assembly line mean it's easier to determine which workers are being fired for actual-cause, versus the ones who need to be protected by the union because it's a kind of employer retaliation or stealth-downsizing.
An awful lot of unions exist in spaces where "compare the widget to the template" is an impossibility. Some examples:
SAE standardizes the labor cost for a given task, although an individual mechanic may go faster and slower than the proscribed hours. The same mechanaic will have different times for multiple instances of the same task based on details of the job.
Police unions effectively require arbitration on an employee by employee basis, since police work is so highly situationally dependent.
Creative unions like SAG and screewriters guild often don't have the notion of measuring quality of output. They exist to ensure various workplace rules (safety, breaks, sane environment, etc) and minimum compensation standards are followed.
The union is not a template of how to be an assembly line worker - its a way to equalize the power between an employer and employees. The specifics of how one union negotiates its collective bargain don't dictate what a union for an entirely different group of people will negotiate.
> It can be "web developers union" or similar - this is how the trades organize (see the pipefitters, and IBEW for some examples).
This is also how unions exist in most of the rest of the world as well. We take it for granted how weird the US labor recognition process is.
Most other countries following a long history of craft unionism. But in the US the laws were crystalized during a time of active conflict between traditional craft unions and socialist-inspired "industrial" unions. So all of the principles of the NLRB are this weird set of dated compromises.
I quite like the idea of a trade union or accreditation board for SWE. The idea that we all work by a shared set of standards and terminology is appealing.
Sounds like a group that captures credentialing in the industry and then winds up using it to push their own flawed ideology on the entire industry. Because who else would actually be interested in being part of such a board.
Civil, mechanical, electrical, and most other engineering disciplines have an accreditation board. I don't think they are pushing a "flawed" ideology in those disciplines. At least I don't see civil engineers constantly questioning why they would do load modeling for a bridge, like SWE's constantly question the value of unit testing.
Yeah and what are the numbers on how many employed engineers hold that accreditation? Just because it exists doesn't mean it's used.
I know for a fact that aerospace, electrical, and mechanical engineers working on designing rockets, nuclear reactors, space capsules, and electric charging infrastructure do not need this credential. And so most of them do not have it.
Consistent educational standards leads to a common shared understanding of what knowledge and training your engineering colleagues have. This also makes it easier right off the bat for an employer to know what a "junior" engineer is - and leads to more consistent experience levels afterwards.
And you didn't quite mix it up, a degree from an ABET accredited school is required to get your professional engineering certification, which is often required in cases where engineering designs carry legal liability.
I think there's still a lot of inconsistency and judgement that happens for gauging whether someone is junior and for what skills they might have. Many software engineers don't have CS degrees at all and even more have ones from different countries.
I am unable to find concrete numbers on this, but I would bet that the majority of employed engineers in the US do not carry a professional engineering certification.
I don't argue with your point regarding how many engineers have their PE. I don't have mine.
My point is that accreditation boards and trade unions can help set standard minimums of what an engineer (or trades person) will know going into a job. Of course employers can ignore them, but in general those standards help bring consistent expectations to a given trade.
And yet, that's what we do with CoderPad, Leetcode, Karat, etc.
Yes, of course you should still interview them afterwards, I'm sure that's what credentialed professions do as well. My point is just to have the Leetcode portion be done once rather than for every company's interview.
I don't trust someone else, especially some credentialing body to administer leetcode style questions. I'm still going to want to have a candidate prove they can actually write code.
Do you perform interviews on potential doctors or lawyers you may choose to use? If you trust credentialing bodies for such important services why the distrust for something non-lifethreatening like an employee?
A second opinion comes after services are rendered. I don't think you put your doctor through a ringer like an employment candidate, was the point I was making.
No I do though, although the context is of course different since I don't know a bunch about medicine.
I ask a ton of questions and I've found that good doctors a) welcome the questions and b) do a good job of explaining. If q doctor doesn't really give me good answers then I'll go elsewhere. A lot of doctors appointments are ahead of some bigger procedure or an ongoing relationship, so the first meeting definitely is evaluative for me.
Maybe you can ask them domain-specific questions more relevant to the actual position you’re hiring them for? System design? Pair programming session? Debug a code sample? Present a solution for a home coding assignment?
Anyway, many companies are outsourcing phone screens now to services such as Karat, where Kiwi contractor engineers provide 24/7 interview availability. Yet those interviews cannot be transferred from company to prospective Karat-using company. So you get the worst of all worlds.
Contracting out interviewing is nuts. IDK how a company can think that the level of validation you get in a coding interview is necessary and also think that it can be outsourced to someone else. They seem completely at odds with each other. I assume they're just cargo culting what other companies do though.
I don't think memorizing trivia is a useful signal for a job, which is what a lot of "domain expertise" looks like in interviews. If you're going to write software and solve problems for a job then you should be able to sit down and solve some medium difficulty coding problems. It's not that hard. Personally I'd much rather do that than a take-home coding assignment.
The number of people out there working as engineers who can't write basic code is too high to not check.
To be fair it’s just the phone screens, but this is the world we’re living in. Eventually someone will build another Triplebyte with AI evaluators and so on and it might actually catch on.
To go back full circle, if you get a decent credentialing system then people who can code can simply pass a test once (let’s say every 5-10 years) and be done with it instead of every single time they interview. DRY!
If it existed then we'd legally be forced to write awful enterprise-style OO-heavy Java, because that's what all the "software engineering" courses at university taught as best practice.
Neat thing about this type of organizing is that the union provides training and standardization paths. Both of those make moving between jobs easier.
They can also provide a standardized way of differentiating employee levels (e.g. union sets the standards for what a jr, sr, or whatever is). I'm not sure if that is good or not in tech, but it is a possiblility - and it's something that would definitely help employers too: rather than each company having to test each potential employee, a union certified X dev will have a certain skillset. Yes some X devs will be better than others, we're talking about humans here, but the minimum bars can be defined and the whole hiring process can become easier and more efficient.
Theres some interesting compensation challenges to get the idea of unionization more accepted in tech tho: stock based compensation and bonuses can get really tricky - something that I suspect is the real reason unions don't catch on more in tech.