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 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.

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.

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.

Refresh yourself on the skills they're asking for. Not as a way to fake it, but as a way to make sure those topics are fresh in your mind.

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.

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.