I don’t have the sort of expertise that makes me qualified to talk about the economy and market trends. I have, however, been in this industry for most of my adult life.
On the whole, technology-focused companies have switched from a rapid-growth model to a sustainment model. The headcount at large companies that have already had their layoff cycle will probably stay steady for a while. Startups are growing their teams slower than they were 3 years ago. This more conservative approach also means that companies are being more cautious about whom they hire. Hiring the wrong developer is extremely expensive and harms productivity more than being understaffed does.
What I am not saying is that only late-career (Senior) developers are being hired. A healthy engineering team is diverse in experience (although not evenly distributed). What it means is that there is more pressure to hire people who all members of the hiring committee have high confidence in. Their skills have to be solidly proven to be appropriate for the role and they have to demonstrate a communication and collaboration style that strengthens the existing team. When I’m on these interview comittees and it comes down to a final decision, usually we say “If it’s not a ‘hell yes’, then it’s a ‘no’.” And sometimes it’s a ‘no’ because an applicant is over qulified. Under-employed engineers don’t stick around and aren’t worth hiring.
Now let’s talk about application rates. Firstly, it doesn’t matter how many people apply - it matters how many people who are better qualified than you apply. Recruiting and interviewing is expensive, and people hate doing it. They aren’t going to interview 100 candidates just because they can. Usually we will be interviewing in batches of 2-5 at a time per open position and our hope is always to find a good fit in the first batch. If you’re new to the industry, you’ll be considered for entry-level positions. That means that you aren’t expected to have years of industry experience, but you are expected to have all of the foundational skills so that coworkers are mentoring you but not required to teach you anything.
I see this advice float around on the internet pretty often, and I hate it. There’s a weird mythos that all good developers are only good because they just love it so much. I’m in it for the money, and the fact that I get to “build things” makes it a much more satisfying way to earn money than my available alternatives.
“Senior” roles are going to people who are late in their career. Those jobs are harder to get right now than they were three years ago, but a competent and cooperative senior developer will find work.
“Mid level” roles are going to people with professional experience, but who aren’t ready for leadership responsibilities. This is the widest range of skillsets and are the largest part of an engineering team. Competent and cooperative developers in this category aren’t being promised as rapid of career growth as they were 3 years ago, but they can find work and progress their careers.
“Junior” roles are for people who are early on in their career. They have technical knowledge and usually a few years of experience as students or hobbyists. They don’t have the professional experience to be totally independent, but they don’t need baby-sitting or extensive teaching. Junior and entry-level developers are under increased pressure to show strong core competencies, appear capable of rapid growth, and demonstrate strong communication and collaboration skills.
I agree with this, and I honestly don’t think it has changed all that much in the last few years. I have seen amazing candidates who come out of a 6 month bootcamp and absolutely blow me away - but usually it takes a few years of learning for your skills to mature under real-world pressures.