Just like competition requires 5+ similarly sized entities for a healthy marketplace of companies, my informal opinion is that unions probably similarly shouldn't have overwhelming market share. However my feeling on contracts between unions and corporations is that the contract should be negotiated between multiple companies and multiple unions to produce the most level playing field possible.
I like that software engineering doesnt require/encourage unions, contrary to other big industries.
As unions mature they protect the employment of their members, not prospective members who are unemployed applying for jobs.
One great thing about being a dev in the US, u dont need a degree, learn a lot, can apply and get a great job.
Ive previpusly been in a union for a company and the experience did not encourage a competitive working environment. When layoffs came, Jr employees get sacked before more senior union members (not neccesarily the best technical staff just becuase they worked there long time).
I have family/friends in unions (non software devs) that have had similar experiences to mine.
Millions upon millions of ppl at every income level have experienced working in and around unions and not all of them came away with a positive experience.
By itself that's not a meaningful observation.
The disagreement then was “I’ve heard that argument before.” - “ok that doesn’t make it wrong” <— that last sentence is what you’re replying to.
These criticisms of unions are always pulled out but then never equally applied to corporations.
Unions, especially failing ones, don't inherently provide any net benefit to society. They may as well be engaged in little more than self-preservation and zero-sum games.
Therefore, I believe unions deserve a different type of scrutiny than corporations.
unions restrict the supply of labor and this results in (price increase) better wages for the union's members. However, overall the total dollar amount transferred from employers to labor goes down (employment decrease), so the "class" of all workers (employed and unemployed) see their per capita wages go down. and if that's not enough, the industry grows more slowly so the problem only gets worse for everyone in the future (trickle down) this is the underlying reason for europe's lower year over year economic growth compared to the US
is the reason. it's not a moral or ethical or even income distribution issue, it's just how markets operate.
Some other ramblings from me.
Management at companies generally dont want to unionize because it generally makes the company less nimble/competitive (its obvious 99% management doesnt want to pay more for labor so i dont feel need to argue that). So yes, if u are lucky enough to be in the union when it gets created, your benifits/salary is negotiated which is cool, less variability in your future, but youll only get paid if your business manages to continue to out compete competitors.
A union example of this i had was installing robots in factories (most of the factories were unionized) (to replace some transportation of goods inside giant factories). My team and I would work with factory management/engineers to come up with plan to automate some process. Before trying to impliment it, we would need to give our plans to a union rep for approval/feedback (who wasnt an engineer). So that factory's competitors didnt have to wait for an additional approval, we would need to wait for a non technical persons feedback to BEGIN a project, your competitor might be finished with project before union approval is done.
Common story of the american factory. Company unionizes, slowly becomes less competitive, a while later goes out of business. This is why so many companies resist (legally) unionization, as in some industries it means certain death.
And on the other side, you can have a degree and experience and still not get a job due to the wild criteria and games that get played in various interviews.
Most IT work now, whether dev or admin side, is not rocket science. It’s mostly approachable work and no one should settle for being abused by employers for some outdated, ingrained, cultural baggage.
This is true in the same way that it’s true that all democracies turn into the majority oppressing everyone else, or get captured by oligarchs, or vote to raise taxes to fund social until the economy collapses, etc. – which is to say not at all. Unions CAN fail that way but it’s not a given. We shouldn’t give up on a useful tool because it can be failed, we should talk about how to keep it healthy.
For example, I’ve seen the no-degree route you talk about made easier by unions because it forced merit hiring rather than hiring more dudes with social ties from certain colleges. Again, that’s not guaranteed – you’d be forgiven for wondering if the Teamsters were a deep cover operation to discredit the concept of unions – but social institutions aren’t magic: they work to the extent that we make them work.
We've actually been automating away our job since the beginning of software. Compilers have been thing for like 80 years now. We've had auto-complete, static analysis, automated testing tools etc. for decades. What about the poor assembly programmers? What about the people who were bit banging serial protocols for a living?
For example, Amazon warehouse are also mostly automated. Still, workers who move boxes around and scan barcodes are the bottom of the totem pole of the operation. They're the people manually making Amazon work. You can't get any lower, otherwise then you'd become a machine.
> What about the poor assembly programmers? What about the people who were bit banging serial protocols for a living?
Those jobs are mostly obsolesced, so the totem pole has "moved up", but we're still at the bottom.
You have to ask the question, who is manually making the product and putting it together piece by piece? For factories, it's assembly line workers. For McDonald's, it's the burger flippers and the board worker. For software, it's us.
We have a misconception that since we are educated and relatively well-paid we are not like that. In terms of our business function, what we actually do for products and companies, our roles are of the same type. That's not a bad thing - this can serve as a gentle reminder to curb any delusions of grandeur.
Good luck then.
Can't say I have much sympathy for American devs after what they've done with the place.
They are fine, but struggle with remote work in general because fundamentally the leverage the union has is a monopoly on labor, which is compromised by a global labor force.
Or they’re applying as international remote workers, where you wouldn’t expect them to be members of your country’s union anyway.
Widespread union membership with verifications wouldn’t solve anything.
- 30 minute recruiter call
- 30-60 minute manager call
- 2x 60 minute leetcode easy/medium
- 1x 60 minute STAR behavioral
- 1x 60 minute systems design or maybe doubling up on a previous category
I'm not sure if we are experiencing different processes, or we have different opinions about what kind of time / reward tradeoff is reasonable.
You just need to ask a couple of open-ended questions about the candidate's preferred programming language and/or some technical details of a past project they've worked on to get an idea of whether they are reasonably competent or not. It shouldn't take more than 10-15 minutes to go through. The majority of rest of the meeting can consist of the candidate asking you questions and/or chit-chatting to make sure the vibes aren't off.
What you are trying to judge is whether or not they can do the job, which you can really only tell once they are actually doing the job anyways. So you pay extra attention to what they do for the first couple of days/weeks after you've hired them and if it's obvious things are not going to work out you let them go. Most places have laws that are amenable to hiring someone on an initial trial period before stronger employee protections kick in.
In general, most of the pathologies of the hiring process can be solved by treating it as a satisfier problem instead of an optimizer problem.
I would be interested to explore a "quick hire, quick fire" philosophy, but I'm not sure it would lead to overall greater satisfaction. Employers don't like to fire people and employees don't like to be fired.
> It’s typically 2 medium/hard problems solved optimally in 20 minutes each with no errors if I want to beat the competition.
I have also definitely made errors in interviews, and gotten hired. If I had to guess, it is a lot more about how you handle those. (To a degree. E.g., in one question, which was a coding challenge, I could solve it, but I was pretty sure my solution was not efficient. I voiced that, voiced why my gut was thinking it could probably be better, but I didn't ever get the full solution. In another one, I was just asked for past experience; I didn't think I had much to offer, voiced what I did have. I still to this day like the question, because it was a tough question, and the person who asked it really pressed me — in a good way, in that I could see that she took her own role/work seriously — on why I thought I was qualified.)
I've also had a call where me & the interview were definitely not connecting, at all. That wasn't going to work out, so nothing was lost?
As an interviewer,
> It’s typically 2 medium/hard problems solved optimally in 20 minutes each
… add 5 min for entry pleasantries and padding, 10 for questions for you at the end, and that's an hour, which is often all the time the recruiter schedules. And honestly, that's usually enough.
I don't ask hard problems. Easy ones sift out candidates. Where I ask coding questions, the first is almost always designed around "can the candidate write a for loop?" and the second is around basic datastructure comprehension. (Can you recognize situations that require a hashtable? a queue? and apply those to the problem.) Often a parsing question. Essentially CS 201, or easier, though I do not care if you know big-oh notation.
Most interviews I've been a part of fit that MO, and I've done interviewing with startups and with FAANG-sized companies.
> each with no errors if I want to beat the competition.
It's not about beating the competition. SWE hiring IME is never zero-sum. Two phenomenal candidates are two hires.
Because, let's be real, not a lot of us are writing leetcode type solutions in our shitty web devs jobs where we center a div. So we need to practice, and more importantly, memorize. Companies don't want a solution, they don't even want a good solution, they want one particular solution. That requires memorization.
You just need to have a US citizen's SSN and birthday to beat the I-9 verification. And "beat" is a strong word. I-9 is just a form that the employer asks the employees to submit, there's no requirement for the employer to do anything with it.
So you can just say that your SSN is 555-55-5555 and your birthday is 01-01-2001 and you'll "pass" the verification. It'll be detected only when the employer submits the Form-944.
There's E-Verify that requires a picture ID and more information, but it's not mandatory.
You’d lose out on people who don’t live near an interview center and potentially have legal issues if people had disabilities that impacted their ability to travel to an interview center but not their ability to do the job.
Not sure if it's feasible, but it's definitely something to consider.
If North Korea is just as bad, at least they're smart enough to not let me see evidence that invades my dreams.
It's a very profound statement (perhaps unintentionally so). Most of us wouldn't even be doing the work we do if we did not have to pay ransom money to our rulers. And then there are unwanted children and all of that...
You don’t understand. These people are working for the state.
They’re not getting nice remote jobs to support their families. Infiltrating these companies is their job from the state of North Korea.
I also don't hold people's place of birth against them, but there are some very reasonable limits to that.