Software is a team sport.

[1] https://en.wikipedia.org/wiki/Shaolin_Soccer

It takes a lot of different skills to run a company. Even at a tech company, tech isn't the only skill that matters.

That's really not true. You don't need to find a Linus or Ken Thompson for that enterprise system. All you need is developers with sufficient maturity to not be distracted by shiny objects, who are proud to build reliable secure systems with the most boring technology applicable (complexity is the enemy of everything, including security, availability and maintainability). These people are easy to find. Yes, you still have to treat them humanely and pay fairly, but finding them is easy.

One factor that may seem to make them difficult to find is the current interviewing landscape. If your hiring process is laser focused on hiring leetcode ninjas, you will staff teams full of leetcode ninjas. I will say the union between the sets (leetcode ninjas) and (maturity to favor stable solutions) isn't super huge.

If for anyone who is doing leetcode hiring (not specifically leetcode, but that mindset) and finding hiring competent people difficult, I can suggest to change your hiring practices and your world will change dramatically.

(Or don't, leaving even more competent developers for me to find even easier.)

How many departments are asked to check in every single day with what you did yesterday and what you plan on doing today?

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!

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.

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.

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.

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.

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.

Please get some perspective not everyone is in your situation.

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

I am a disorganized guy who hates authority and interruptions, and even so I have grudgingly come to realize that (strictly) 15-minute morning standups actually do increase my productivity.

What you really want is developers who understand your solution and your stack, and actively want to contribute.

And for that, you need a good team mentality, easy-to-read code, and a good onboarding. And avoid crunch time as much as possible, especially when a new hire arrive, because you want him to ask dumb questions asap.

[useless personnal anecdote because i feel great about my new workplace removed]

Why is a single dev able to take down your entire system without intention?

>They can write quicksort but have no idea

So don't use quicksort or identical questions and ask them more.

Your entire anecdote can just as well be held as testament of how a company's process is completely fragile. Which is at least a yellow flag as to what else it is hiding.

IT departments love this, because it's not their problem and they don't have to do anything except press reload in the third party's ticketing system.