If you honestly think being asked those 2 simple questions is not being treated well. You're going to have a hard life.
IMO this is absolutely crucial to understand about our industry, for programmers too, not just IT.
We're paid well because they can't avoid paying us well. But they don't want to let us in The Club of the actual professional or upper-middle class, in terms of perks and status (and, actually, pay in most of the industry, even in the US, doesn't quite rise to that level—$200k+ for mid-career-or-earlier isn't what most programmers see).
Frequent monitoring and things like open floorplan offices are part of that. High-status gets very little monitoring, and an office. There are tons of little things like this.
I think it may also be a minor reason our interviews are so god-awful (but I think the main reason is the huge players trying to reduce turnover to suppress the rate of wage increases).
When companies want a fully algorithmic way to filter for signal, it’s not because we think it’s a great process, but because it’s one of the only viable processes.
PLEASE explain to me what value leetcode-type questions provide over what good of a software engineer someone is!
Here's simple task that I ask on interviews: write JavaScript function which works like setTimeout and uses setTimeout internally but provides a Promise result so it can be awaited. Very few people can write that kind of code. They actually have no idea what Promise is. They want to get in frontend position. How can you write frontend code if you have no idea what Promise is.
Would that piece of information be helpful to you as you consider which candidates to invite to the first round of interviews? That is why companies do it.
A candidate who got 2 or 3 solved in 90 minutes is very likely to do much better on the rest of the interview and on the job than someone who couldn't solve any.
(I think a lot of people who can write code have a difficult time imagining just how many people both can't write code and apply for seemingly every posted SWE job listing.)
Haha. Hiring people is a job in and of itself. It needs a good eye for detail and intuition.
People are weird. Some days they write great code and hardly any serious bugs. Other days they need to look up a for-loop on MDN.
Get some perspective ffs. This is the easiest, cushiest job I've ever had, and the only one where people with masters degrees often consider me their peer despite my 11th grade education.
Stop whining and join a union or something seriously. These are all minor and solvable problems.
Please get some perspective not everyone is in your situation.
Many IT jobs are paid hourly, don’t get health insurance, and some even get paid minimum wage. That said, I have had plenty of people describe their retail jobs as cushy because it’s low physical labor, inside with AC, and they don’t have to think.
Long hours and little respect probably will vary from one employer to the next. However, I've been working as a developer for about ~10 years - most of it with a mid-size insurance company but the last couple with a large bank. I work longer hours than most of my colleagues, but I've rarely put in more than 50 hours in a week, and my average is probably closer to 45. And my non-engineering colleagues have always treated my fellow engineers and me with respect and an appreciation for the difficulty of what we do. If anything, they've usually been a bit too deferential.
YMMV, but I think our profession is probably among the best in the world for workers. If my child were about to enter the working world and had the ability + interest, I'd absolutely recommend this as a career.
However, being on call is representative of something. Your electric company has linemen ready to respond at 2AM because they provide a service which needs to be available 24/7. However, good luck trying to contact your dermatologist, accountant, physical trainer etc at 2AM.
For all practical purposes, above a certain level of management, you are implicitly on call all the time. However, the bar to clear to engage you gets higher the further up the leadership layers you go. A manager of a handful of teams comprising about 100 staff gets engaged for less serious fires than the CEO, but both are "on call". It might take the board of directors chartering a helicopter to get to the CEO's fly fishing cabin during the CEO's vacation if a situation warranting such presents itself, but the CEO is absolutely on call 24x7x365.
The complexity of what engages the on call person I suspect is what connotes status. Called for clearing out disk space: low status. Called for application outage that has stumped multiple technical teams: higher status. Called for a production outage impacting the next day's C-level reports that requires engaging other management: higher status. Called for heading off a shareholder proxy battle: even higher status.
Note here complexity doesn't solely reside in the technical realm, but frequently is rather a blend of technical factors, social factors, and quickly making impactful decisions in low-information situations.
I can't wait for low-code to get good. It's going to throw back in real time the obliqueness of the request:
"Validating most likely candidate solution..."
8 hrs later
"Solution failed to validate ... please try rephrasing request."
It may not be indicative of the industry at large, but most engineers I know get away with this by changing the framing "I'm working on a doc" or "I'm scoping this feature" etc. Obviously this does not work with sufficiently bad management.
Care to outline it for me?
They're even busier in public hosptials btw