If you have 7 years of experience, you almost certainly have important, non-junior level skills of value.
But companies do not hire people based on how good of a developer they are, they hire you based on how good you are at interviewing. These are corrolated, but not equivalent skills.
What you need to do is get better at interviewing.
Interviewing is a skill that needs to be practiced.
That means you need to get better at programming silly algorithms on a whiteboard.
Fortunately, this is a skill that can be practiced. There are loads of resources out there that will teach you exactly the stuff you need to know to become good at interviewing.
+1 .. Plus a lot of interviewing skills are just common people skills that you can screw up without thinking about it. Just keep interviewing and pay attention and review things afterwards. Simple things can make a difference. I had a job that I really hated and tended to bad-talk the company in interviews. I went for months without an offer as it, not surprisingly, turns out that people don't respond well to this. Once I stopped doing it I had 2 offers within a few weeks.
Getting better at interviewing is cynical and not good advice.
The OP isn't looking for how to land a job, they are looking for how to actually become a better software engineer. People that are better at interviewing than they are at engineering are not doing anyone a favor.
It takes a lot of courage and insight for the OP to recognize their predicament and come to the solution of applying for a junior position.
I have over two decades professional experience across many organizations and I contend that is an absolute truth that one can spend years (even seven) with little to no mentoring and advance in skills less than an equally adept person who had one or two years on a team that really helped them grow. I've seen it happen and I've had it happen to me early on when I saw an engineer I used to mentor (but I had none myself at the time) leap frog me in capabilities when he went to another job that had even better mentors.
Getting better at interviewing is not going to help as much as getting a job at a company that gives them better support. If it takes a junior position to find that environment, so be it. But expect to advance extremely quickly, so set that expectation with the employer that they will support the promotions as they are earned.
For me I think the best strategy to take in being more employable (and hence having an easier time advancing to a more ideal position) is to start building up desirable experience in the next job I take.
It's been a while since I have been gainfully employed (my ex-boss gives me freelance work at least) so right now in downtime I apply for jobs and set up interviews. I've been fortunate enough to get detailed feedback from a few places.
In particular with TripleByte. They've been very helpful in finding holes in my interviewing style, and knowledge base. Even though they couldn't find a targeted job match for me they run down in detail what I did wrong and what I could do to improve. And I do feel like it's hitting home.
I feel like I've "Peter Principal" myself to a junior role. Most of the companies I've been with are on the smallish side, with small tech departments. A marketing agency that outsources to India, shows little care on the craft, no basis on testing, integration, or automation.
Another one, a magazine company where I was the one man band when it comes to programming. Nobody else knew how to code. I had to deal with putting out fires working with a legacy code base and had to cowboy-code my way out of problems.
These experiences have made somewhat of a self-starter, but I need more structure. I need to know how to apply TDD principles, figure out the best way to solve an algorithm, or depending on the company, pair program with someone.
It's like competitive games. I can't get really good unless I can practice alongside someone that can consistently kick my ass. Eventually I may be able to kick theirs more consistently. Craft my own problem solving approach that I can call my own, use it as a selling point.
Granted, I'm only just about one decade into my career, so I'm not that late in the game.
The "one year of experience" phenomena is too real. I'd like to read some articles not just that show examples of it, but also teach effective methods to correct it. I don't find a lot on dealing with the latter.
If you have 7 years of experience, you almost certainly have important, non-junior level skills of value.
If only that were true. There is a difference between having 7 years of experience and 1 year of experience 7 times. If he hasn't had a mentor and been in a bubble, it's possible that his skill set is not as high as it "should be" based on the number of years he's been working.
I found myself in a similar situation around 2008. I started programming in 1986 when I was 12 in AppleSoft Basic and assembly, went to college, got a degree in CS in 1996 and spent the first 12 years of my career being a solid C++ "programmer", who dabbled in other languages.
During those 12 years, I was also the only programmer at the company without a mentor. I could write clean code, bit twiddle with the best of them, but hadn't been exposed to sound engineering practices.
In 2008, at the age of 34, I humbled myself, got a job as what I would consider a junior "software engineer" (making about the same thing as I was already making) and spent the next 8 years, learning from others, studying, and job hopping my way between 4 jobs and becoming what I consider a pretty good architect.
Coincidentally, I'm age 34 right now. So at that point where you were at a crossroads you turned things around. Did you work at large companies to correct that? Do you think development team size make an impact on your career growth?
Being at a large company isn't what made the difference. Even though I didn't realize it at the time, I think it is more important to work at a company that sells software and sees software development as a profit center and not a cost center.
There are some requirements I would look for:
1. Do they have automated tests?
2. Do they enforce code reviews?
3. Do they use some type of continuos integration system?
4. Do they use source control - preferable Git?
5. For the server side, do they use a statically type language - Java, C#, or even NodeJS/TypeScript
6. Do they have organized training sessions like lunch and learns?
I'm at a point in my career now where I'm pretty confident in what I know and I'm the only architect at my company. I ask for advice a lot from some of my former more experienced coworkers on a private Slack channel that we still use.
To all those questions I can answer 'no' to all of them, besides no. 4 because I do use Git. Damn. Now if only I can get offers from companies that have the other qualities.
We are the same age and have about the same length of experience.
I totally get where you are coming from because I began to feel I wasn't learning anything new and just repeating the same processes. So I left after 3 1/2 years.
Since then every job I've had I try to work for people I can learn from and grow.
Having people who can mentor or just being around smart people and seeing how they work and implement processes can be really helpful.
To add to this, study everything on your resume. I hate interviewing people who say they "know DSP" but can't tell me why one might use a filter before down-sampling.
Also most companies won't give you honest feedback on what you did wrong in the interview, especially w.r.t. soft skills.
Join an interview prep class or mock interview workshop and try to get someone else to identify what you're weak on. It could pay off majorly and help land your dream job.
I've been lucky enough to have collected feedback from at least a handful of companies. I've also interviewed with TripleByte. They didn't match me with a job but they are detailed on what I did wrong in the interview. They also said I sounded a bit nervous. I don't stutter or shake my voice so I'll have to figure out what are other signs of nervousness that I might be showing.
Most of the non-generic feedback I got on tech skills followed the same theme- I have breadth in knowledge, but not depth. I'm not as "T-shaped" as I thought I was.
I agree with the parent. I think you are selling yourself short. Who says every dev needs to be deep? A lot of us get to very senior positions by being very broad. I suck at interviewing but have always managed to find amazing jobs where people looked up to my breadth.
If you have 7 years of experience, you almost certainly have important, non-junior level skills of value.
But companies do not hire people based on how good of a developer they are, they hire you based on how good you are at interviewing. These are corrolated, but not equivalent skills.
What you need to do is get better at interviewing.
Interviewing is a skill that needs to be practiced.
That means you need to get better at programming silly algorithms on a whiteboard.
Fortunately, this is a skill that can be practiced. There are loads of resources out there that will teach you exactly the stuff you need to know to become good at interviewing.