This write up sounds like it describes a very particular subset of companies. If you only want to work at the flashy unicorns in downtown San Francisco, you are signing yourself up for exploitation.
Like any career, if you get off the beaten path there are plenty of pretty okay jobs out there. Especially if you have a marketable skill. This is software, if you have a brain and functional hands - you already own the means of production!
I absolutely support unions - but you're going to personally be better off changing companies and working your career ladder and finding the spot for you than sticking around at an exploitative company just because they have a union.
> This write up sounds like it describes a very particular subset of companies
Indeed.
80 hours a week (or even 60): Never had to deal with that in over a decade across 3 jobs. In fact, I've never had to work a weekend (and if I did, it was either to fix my own screwup, or because I intentionally slacked off during the week and needed to make up for it).
Slack/email off work hours? Just ask up front in the interview: "I turn off my laptop at the end of my work day, and don't install any work related items on the phone. Is that OK?"
On call? Lots of jobs that either don't involve running an online/web service, or if it does is for some internal company tool where the cost of it being down is low. I've never had on call. However, I did interview at places that did, so the questions to ask in the interview:
"What is the on-call rotation look like?" Typically it's one week per person, rotated by the number of people in the team. Team has 4 people? That's once every 4 weeks (too much for me).
"How often are people called during on-call?" I interviewed in one place where they got 2 calls out of work hours in the whole year. I can live with that.
"What's the process of evaluating those calls?" Do they just expect you to take care of it and move on, or do they have a process to analyze and prevent it from happening again? Some teams move too fast and there will always be calls - they don't want the hit in fixing things.
Incredible idealism. If you work in infrastructure, even development, there's no such thing as shutting down at the end of the day or weekends. 'You never know' if someone senior gets agitated off hours because something is broken, and is expecting a big group on a zoom call
I do work in infrastructure and never had to work out of working hours unless I was oncall. Our on-call rotation is 12h a day for a week, because we have an oversea team taking over. I get oncall every 5 weeks.
You can absolutely find places with good working condition and with a good salary
In New York I am finding the expectations getting higher and the salaries stagnating, to the point that I'm considering taking the plunge into consulting.
There's not a lot of infrastructure job talk on HN as everyone is a software developer or academic type.
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.
> you're going to personally be better off changing companies
Job mobility for tech workers is a fluke of current economic conditions. If interest rates spike, or a recession happens, or a bubble bursts, this benefit would go away and you'd be stuck at that exploitative company or unemployed.
Unionization and labor laws can make workers less disposable without substantially affecting growth (see: European tech hubs).
> make workers less disposable without substantially affecting growth (see: European tech hubs).
Sorry, but you shot your argument in the foot with this example. The last two months of Europeans trying with great difficulty to replace US tech with local tech have shown just how little tech has grown in Europe relative to the US. Is that because of their labor laws? Unclear. But it's certainly not a shining example of success.
The effort to replace US tech is not anything similar to the European tech industry.
US technology has a hegemony because we were first to the party, our economy is larger, and our laws are hostile to newcomers (lack of interoperability requirements, lack of enforcement of anti-trust laws, strong defense of DMCA laws, non-competes, and trade secret laws).
I've worked in the EU tech sector. They have tons of startups that operate just like US startups: VC funded, hockey-stick growth, and hiring like crazy. Their stricter labor laws don't get in the way of that.
The hyper-growth, VC-funded startup model is itself quite exploitative, but if it's still possible with stricter labor laws, then fears about them impacting growth are unfounded.
>I've worked in the EU tech sector. They have tons of startups that operate just like US startups: VC funded, hockey-stick growth, and hiring like crazy.
Oh, we're talking about bubbly VC growth and not actual GDP growth or growth of sustainable businesses or new useful products. In that case, I suppose I concede.
Like any career, if you get off the beaten path there are plenty of pretty okay jobs out there. Especially if you have a marketable skill. This is software, if you have a brain and functional hands - you already own the means of production!
I absolutely support unions - but you're going to personally be better off changing companies and working your career ladder and finding the spot for you than sticking around at an exploitative company just because they have a union.