You've provided a good example of why using the grouping "IT Job" is worse than useless.

On the one hand, you have companies struggling to hire software developers because of massive shortages in certain geographic or skill areas. On the other, cloud hosting technologies with decent tools for bringing up and connecting servers (think AWS) have reduced the need for whole classes of jobs, leading to network engineers and sysadmins seeing opportunities disappearing.

Talking about "IT Jobs" just leads to a lot of people shouting past each other.

If it isn't prying, what are your skills? Speaking out of my own experience, I run an engineering group, and it's ridiculously hard for me to find good people. We aren't biased against Americans (nor, and you may not like this, are we biased for them), and we take a lot of trouble to make sure that the compensation we offer is in line with (or higher than) the rest of the industry. But, honestly, it's pretty rare for a top-notch person at any level of skill ... even relatively junior ... to respond to our job postings or recruiter, and then it's even more rare for us to manage to hire them away from the dozens of other great offers they're getting. When I talk to other hiring managers in the area, I hear the same thing over and over. Too many jobs chasing too few good (or even not-good-but-could-be-mentored) candidates. Thus my curiosity about your skillset. (As an aside, I want to say that we do hire H1-B candidates, and that it's a point of pride for me that we pay them fairly and in line with anyone else who would have that job. I don't want to use their immigration situation to wring every last dollar from them. I'd rather that they were happy, and kept working for me because they liked it or were learning something.)

I have to say, you'd really hate trying to get a job if I were the hiring manager; I always give two rounds of technical questions.

The first is a take-home test, where you can use whatever resources the world and its internet provide to you. I email it to you, I expect you to email it back in an hour. It's a wide range of questions from simple coding exercises to complex problems that can't be solved in an hour. Getting some measurement of technical skill (and your ability to research) is only one part of what I'm trying to do here. More critically, I want to see if you can triage work, and identify what you can and can't accomplish in an hour; that skill is as valuable as knowing any language.

I'm also looking to see if the harder problems interest you. I think they're mildly cool, I'd like to hire someone who does too.

At this point, about 2/3 of the interviewees disappear from the process. They reply saying that they decided they were unqualified, they reply saying they didn't have time. Once, they replied that they were insulted that I would question their resume. In any case, without even spent 60 seconds of my time on a phone screen, I've narrowed the field to people who at least have basic coding skills and aren't offended that we might feel they should prove themselves.

Then, when the person comes in for an interview, I like to have them write some code on a whiteboard. I start with a simple problem, and start adding requirements as they go along. I want to understand what they're like to work with, how they handle changes in requirements, how they write code to be change-tolerant. I also want to see what they're like under stress; do they seem like a culture fit? Are they enjoying the challenge?

At the end, I will know a lot more about a person than if they have basic skills or not. I will have seen them in action, gotten a sense for how they solve problems, and understand a bit how they might work with me and other people on their potential new team.

You may not like the fact that I want to know these things, but they're important to me.