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.

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.

I had to move and was getting killed in interviews for sr. positions, until I wasn't. I found a company that saw my value and gave me a chance. I contracted for them for a few months then landed a 6-figure job doing stuff I'd never done before.

I would encourage you to hold your head up, build some stuff in your spare time, and find a company that values what you are. If you are capable with JS in any capacity, double-down on that since it seems a lot of people are being hired from that. Plus you can show projects that can impress people of all backgrounds.

I would also encourage you to reach out to any past associates or linkedin connections.

Another resource I recommend for people is Mike Hartl's book(1) on Ruby on Rails. Yes, it does teach you that language/framework specifically, but it also shows you how the web and server-side applications work. You will be able to speak about REST, DB Associations, OO concepts, TDD, and several other buzzwords that impress employers.

I don't know your work of course, but from the sounds of it you have a better shot than you think! Go get 'em.

[1]https://www.railstutorial.org/book

I hope that I would at least stand out from most JS developers with stuff like this. I don't really have an interest in making a Twitter clone with a Bootstrap UI. I'm hoping someone takes a chance at my skills with my not so typical JS projects.

So you want to frame it differently. For example, provided this is true, you could emphasize that you've been the most senior person in your company, but that your company offered limited growth opportunities. Now you're just champing at the bit to work with people from whom you can learn and grow, and you're overflowing with energy to do so. Demonstrate why it's true, perhaps with examples of things you've been poking at on your own. Or something. You need your story to be true, and the above might not be. But you do need to have _a_ communicable story.

I'm assuming you build websites? Web developers don't typically deal with the sort of algorithmic problems that software engineers tend to deal with.

You're essentially switching to a new career path, which is not a deal-breaker.

Simply explain to companies that you are a senior level WEB developer, but a junior-level software engineer.

Software Engineers rarely deal with the sort of algorithmic problems you're thinking of. Engineering isn't about the basic fundamentals of CS. It's about thinking in systems. A person developing an individual component of a system may deal with algorithmic problems, but unless they're also contributing to the architecture and design of the system as a whole they aren't doing engineering, either.

No algorithmic problems, though, you're right about that. The closest thing I can think of relating to time complexity for web dev are when N+1 queries are used unnecessarily. I fix those, and change them into single queries.

For what it's worth, though, Amazon did reach out to me and I did two rounds of interviews with them. I bombed the tech on the second one.

Senior level web? Heh, even in web don't even think I'm that far. I have zero professional experience with anything but PHP which is going out of demand in newer positions.

On the JavaScript side I have done two React projects, all the companies I worked for had old-school JS though. Bunch of vanilla JS with jQUery strewn in, hundreds of files, no usage of Node nor modules.

What does that even mean?

Now web application development is very much alive, but that tends more to software development.

Less important than whether or not he is "junior", he needs to know what to call himself in order to correctly communicate the value proposition he's offering to the potential employer's HR department. The only way to know that is to figure out what people call what he wants to do in his market.

Maybe he's a "web developer", maybe he's a "software engineer", maybe he's something in between. But he should definitely A/B test terms to see whether his responses change and how.

For instance, my title for a web marketing agency was 'associate software engineer'. It was the typical job of setting up CMS sites, customizing plugins for them, or occasionally making a very static site from scratch.

I gradually got into doing more complex work like writing apps on MVC frameworks. But I think there may be indeed another career ladder I need to jump on if I want to actually do the "engineering" part correctly.

I wouldn't worry about "years" too much. It's very very easy to work a number of years and still be a "junior" skill level. I see it all the time. It's not even a criticism of the person at all; if your job is "perform minor fixes/improvements to this web app" and you do that for 5 years, for example, you're not likely to have technical skills beyond the junior level even though you've worked for many years. This is not a problem. It just means that if you want to move your career forward you will need to find a position in a more tech-oriented, forward-moving, mentorship-based organization.

A senior developer at a non-tech organization can easily translate into a junior or mid level developer at a major tech or tech startup.

Your job when applying for any position is to learn to sell your skill set and show what you can do for others. Learn to celebrate your success and tell other people what you can do, that is how you will make it to the next level. Sorry, it isn't all about perfect skill, it is about selling what skill you have.

My side projects are what swayed them. That and knowing some specifics to media of course. It wasn't solely the side projects, but they helped display a breadth of skill that I otherwise wouldn't have been able to with only work that I was paid by somebody else to do.

In the media company I now work for, my manager is pseudo-technical. He had an engineer sit in on the interview for any technicals. Outside of the side projects, one of the major points I scored with them was that I knew anything at all about Adobe DPS -- and I hardly knew a thing. Vague private interest in how modern publishing was being handled translated into a position in a company that does it. Downloading an outdated demo at one point to play around for an hour or so translated into talking points. The engineer relied more on general technical knowledge for his approval, and seemed to avoid the typical "programmer interview" questions.

So! I guess my point is that people shouldn't rule out play as valid experience! Isn't that how most of us started on this kind of work to begin with?

Do things, build things, break things (and then fix them)!

Some people are doing the exact same thing they were doing years ago and have no depth. Your challenge will be to paint a different picture. Which is easily possible. It sounds like you are interviewing but maybe not doing well face to face. Maybe you just need more prep and its not a deep issue?

Generally it means that the person being discussed hasn't spent those years acquiring skills that are specifically useful to the interviewer. So the years spent acquiring different skills don't count.

The intent is probably to say that the interviewee has spent 7 continuous years doing a job that can be done as easily by a person with one year of experience as someone with more, and therefore does not provide the necessary challenges to stimulate development in the employee. But again, it is still summarily dismissing actual experience just because it didn't happen in the right place, and is a variant of "not invented here" syndrome.

The people who say things like that should likely not be discussing "years of experience" at all, as their focus seems to be on breadth and depth of skillsets. The "seven years of experience" guy likely knows how to do X, Y, and Z, while the "one year of experience 7 times" guy likely only knows how to do X. In that case, talk about X, Y, and Z, instead of T.

There are people that either via the jobs they choose or the long tenure at a company haven't built a strong case that they can tackle anything other then a small domain of problems.

I had an interview once who had 15 years of managing scientific data (he wrote a parser then changed it when the data set had format changes a few times a year) that parser and platform remained unchanged for 15 years and he had no other duty.

Another interviewee had only built WordPress sites for 4 years. He had no other projects (hobby or professional) to illustrate he could do more.

I see your point regarding a skill set that is maybe just not useful to the interviewer, certainly in 7 years there should be more. People can and do spend time working on very narrow problems though.

Time is a limited resource, and it belongs to the individual. You can't reasonably expect that someone will spend it making themselves more valuable to you when you aren't paying them, or even holding out a reasonable prospect of paying them in the future. By happy coincidence, there are plenty of people out there that will make themselves more valuable to 10000 interviewers just like you, by acquiring skills that seem to be popular or becoming popular, but there are many more that won't live their lives for other people on the off chance that it might be rewarded someday.

You can't really measure skills by how long someone has done something. Some people can learn a new skill and be better at it after two weeks than someone who has done it for ten years. And there are also people who can practice a skill for ten years and be 100000 times better at it than the guy who just learned it two weeks ago. To make those judgments, you have to be able to measure aptitude, rather than just read timespans off a resume.

And right there, with the WordPress guy, you're implying that he wasted 4 years of his time because he didn't spend any of it preemptively learning any of the things you find valuable. Why should he? He hadn't even met you yet. How long had your job posting been open, declaiming that your company would need someone with M years of experience in skill X when it starts hiring for that in N years? (Yes, I know that's not how it works.) Did you even try to gauge how skilled he was able to become at WordPress site development after four years? Did you wonder why it took him 4 long years of doing just that before wanting to move on to something else? Or did you preemptively strike him off your list for having no prior "years of experience" in skill X?

My point is that I would very much prefer it if the industry hired for general aptitude rather than specific skills. If that doesn't happen, I would still prefer it if interviewing companies used a different metric for measuring the skills they find valuable than the total time spent practicing them. The glib comparison between "N years of experience" and "1 year of experience, N times" just presses all of my rage buttons at once. It almost perfectly highlights the gross disrespect that potential employers have towards job-seekers whom they perceive as unfit to serve them. It is part of the arrogance that prevents companies from critically examining their own hiring processes.

Adding features to the average business CRUD app on a LAMP stack for seven years straight is a lot different than applying your skills and energy to things like distributed systems, bigger scale projects, learning better abstractions and design patterns, etc.

I think this is very real. So how do you correct this problem and sell the perception that you are able to do well?

Interview prep, like Pramp? I did get some feedback from TripleByte at least.

Ultimately having confidence and being able to demonstrate how your history makes you a good fit is going to combat that perception.

When you tell people about your work history - does it sound mostly like the same kind of problems/tasks? How can you show you did more than that?

Any outside projects you have that show diversity in experience?

Regarding your statement about Pramp - are you failing on the coding part of interviews? Not to get into the validity of white board exercises as a method for filtering candidates - I personally don't think putting people on the spot is a skill set that you actually need to do the work.

Is it possible you are stuck in a rut due to troublesome interviews? As I said above lack of confidence to sell yourself can be sabotaging you.

[1] https://davidwalsh.name/impostor-syndrome

I have a very similar history in terms of starting my career as the only developer in my first few jobs. When I finally joined a few (small!) teams in a row that a) included other seniors; b) used mature processes; and c) included code review on every pull request, I caught up very quickly.

A capable manager or VPE/CTO who's committed to helping their reports grow is also invaluable to a senior developer.

And yes, it sounds like you may need to work on your interview technique.

Pick something that you find interesting, and go really deep in it (read books on the topic, develop OSS oriented around it). For a mid or senior level engineer, companies want someone with a broad enough set of skills that they can tackle most problems given to them, but also has a deep knowledge of one or more areas (which adds to the collective group of talents among the engineering team).

Hit me up through kevin@mattermark.com