Once you have the interview, you can talk about your experiences, why you're a good fit, what you do in your spare time, etc -- they will not tally up years of experience or record your answers directly into an Excel spreadsheet.
Also, don't say you're "pivoting" your career. Just don't.
You need to work on meeting people in your field, at the companies where you want to work. It's not what you know, it's who you know. Go out to meetups. Be a friendly, helpful person. Make friends, lots of them. One of them will make the connection for you at some point.
I've got my first job in the states because a recruiter called me. Same for the second job. The third one was through being acquired. The fourth one, you could call networking if you call showing up for a recruiting event networking. 5th one? You guessed it, recruiter called. Sixth one? Yep. Exactly.
Before that, I worked in Germany. 1st job, applied cold. Second one, applied cold. 3rd one, applied cold. 4th one was working with a friend, so there's that. 5th one, applied cold for contract work, converted into a job. So half networked.
So, if we're generous, 2 out of 11 were networking.
As far as I'm concerned, work on the things you care about, build your skills, and when you switch jobs, make sure it propels you forward in some way. If you're a social person, by all means, enjoy meetups/meeting people because it's something that works for you. But don't force yourself to yet another meetup just because everybody says you should.
So I think part of the answer is clearly saying what you want. I don't know if that holds for positions like Director /VP at large tech companies - these are always somewhat political - but it seems to hold up to pretty much right before that.
YMMV, of course. For all I know, I accidentally have the right magic keywords in my LinkedIn or something. (I don't know. I only update it every few years, so I certainly am not paying enough attention to tell :)
That’s probably safer for them. IME many recruiters doesn’t really have enough knowledge about the role they are trying to recruit for, so it would probably be very risky for them to try to find a ”rough diamond” since they are not really able to make such a judgement call with high enough chance of succeeding.
Define "recruiter".
When I hire the first thing I do is also reach out to my personal network to see if anyone is looking for work or know anyone who is.
My wife did just manage to land a job with a cold application, though, so it's not like either way doesn't work.
I suspect that to be more the case in very large companies. Luckily I have never worked in one.
About half of my interviews started with an HR phone call where they spew their laundry list of technologies and ask me to disclose the years of experience and how do I rate my skills from 0 to 10 for each element in the list.
You can't call yourself anything lower than a 9 lest they move on.
I usually rate myself from 7 to 8. Probably 9 if I have 5+ years of experience or I would be confident consulting.
Once I rated my skills as 10 for a technology I know quite a lot about. I was then told that I was showing off and that I need to work on being more humble.
They absolutely will ask for the exact years and months if you haven't listed them, and they'll think you're hiding something if you prevaricate.
So hold off on start/end dates at jobs then? Since those could be used to figure out experience?
I tend to find such polemics unhelpful. Usually when someone tells me "just don't", I end up really wanting to know the mechanism behind what is causing such a stern warning.
For example, if I asked someone, "should I jump out of an airplane with no parachute",...
and someone says...
"just don't, because unless you have lots of luck and can defy lots of laws of physics, you will most likely be killed"...
then they have revealed a very clear and concrete reason, which strengthens their assertion of "just don't".
I see no such evidence for or against using the word "pivot", and I can imagine scenarios where the word even resonates with certain types of people.
Pivoting your career can be construed as having failed somewhere and needing to find something else.
In the context of a career, phrase it as evolving your skills to match market demand. The very people who "pivot" resonate with will immediately associate it with failure.
Yes, it's an overused term but it's NOT a sign of failure.
For me this is not something negative at all
When interviewees are asked "So why are you looking to move from your present job?". Saying that you need a new challenge sounds very different than "needing to pivot".
However, interview gives one a very limited time to impress. Better use it to discuss your strength and the future, not invite archeological queries.
There isn't anything more concrete than that. YMMV. In this particular case, it rings true to me.
Independent of that, I think using the word 'pivot' here is fine. We all know what he means. There might be a different word with a different connotation that some people may be more receptive to. But, pivot is well within the realm of reasonable words to use here.
Round an unsolicited job application down to a no-op; this is not how the majority of jobs get filled. Instead, you should find someone with decisionmaking authority in the company, talk to them, and get them interested in you.
The "N years of experience" thing not a requirement. It is a polite fiction. It was put there by someone who may not even be associated with the team that is doing the hiring. But if you come through the front door, there exists a team of people who will aggressively filter on that fiction because if they don't filter on it then the larger organization will ask "What is it, exactly, that you do here?"
Your mission, should you choose to accept it, is to only have these people involved to schedule the interview that a decisionmaker has already committed to giving you and/or collect the resume that they need for their records now that you're hired.
Senior engineers applying to junior roles are selected against fairly aggressively. This is an unfortunate shibboleth, but it is a widely used shibboleth.
Senior engineers should apply to senior roles; the vast majority of hammers swing in approximately similar fashions and as you get more senior you're not being hired to hammer in nails-per-hour. You're (hopefully) doing things like helping younger employees understand the difference between screws and nails, pushing back on the person who asked for 100k nails on a house that has been uninhabited for 6 years, developing processes to avoid wood rot around your nails, etc etc.
Incidentally: Serious software shops are largely aware of this. If a company thinks that a Pythonista with 5 years of Python experience cannot be a Rubyist in single-digit weeks, that company is probably not a great place for software people to be.
Do an initial project creating an app to do something for you. Use that to try to find another project/app you can create for someone in your network as a freelance project. Become active in the community for that framework. Blog, write tutorials, reach out to others in the community to build relationships.
When applying for jobs I would list your job title, company and years. Then have another section for the languages/technologies you have used. I never match them up one to one. They will ask how many years experience you have with what they are using. With new frameworks a year to a few years is good enough to get in the door.
Becoming active in the community is going to open more doors than resumes. Once someone knows you and that you are capable it's easier to land a position if they can recommend you.
Good luck with your pivot.
Just apply to jobs, and talk about what you've done, and how you did it.
If I see an interesting position, I just apply. I know I'll get better consideration if something on my resume resonates with the hiring manager/interviewers. But if you are any good you should be able to adapt what you know to a new programming environment with new constraints.
They are mostly worried they will get a bad hire, so they are looking at ways to eliminate potential negatives. They are in a risk reduction mentality. So it is safer to just eliminate candidates.
If I were hiring full time devs, I would take a chance but I would expect them to meet deadlines as if they were fluent in the stack - meaning if they have to work weekends or more than 40 hours a week to be just as efficient as someone who knows the stack, they should do it.
I put myself to the sane standards when I'm an FTE. If the company advertised they wanted a proficient React developer for instance and I was honest with them about my lack of experience and I convinced them that I was willing to learn, I would make sure I produced 35-40 hours worth of productive work even if it took me 60 hours to do it.
I'm not putting in extra hours necessarily for the company, I'm doing it to further my own career.
You'll miss out on people like me who refuse to play that game. I don't expect to be fully productive for the first few weeks on the job and I'm not working through the weekends to try to be. I also don't expect anyone I hire to be fully productive until they get familiar with our stack.
It's completely absurd to put the burden of training completely on the employee. Culturally we need to stop accepting this.
Why is that so absurd? Part of the culture in tech is that there is no loyalty on the side of the company or the employee -- I'm okay with that. The company can lay me off at anytime but I can also change jobs and take the skills I learned with me and probably earn a higher pay anytime. What incentive does a company have to train employees in that environment?
>What incentive does a company have to train employees in that environment?
The normal incentive is access to a larger employee pool and cost. You have access to a much larger group of applicants if you're not looking for 100% productivity on day 1.
Also if you are willing to spend a bit of time training your employees, they are less likely to leave. Give them raises equal to what they're worth on the open market and most of them have no reason to leave.
Reducing employee churn is worth a lot of money. No employee is anywhere close to 100% effective on day 1, and from experience, training goes a long way towards improving employee retention.
Not providing training because you're afraid an employee will leave sounds a bit like a shop owner who is so scared that someone is going to steal a few pieces of candy that he locks down his store so tight no one wants to shop there. Sure a few people will take your training and run, but that's just the cost of doing business.
Then if I get stuck at something I'll try to fix it first, then learn more about the stack to see if I'm missing something basic and finally ask for help. These go normally for free if it's because of my lack of knowlege; otherwise I'll charge for them ofc.
I've also found out it's quite important to explain this to whoever is hiring you. That way they don't feel cheated on (money) nor like you are slacking off and working only X hours instead of 2X per week.
PS, your comment sounded quite negative/exploiting, probably that's why the downvotes.
How is that "exploitive"? When I'm contracting I always get paid 10 -30% more than I could get as an FTE all in - even if I include the cost of benefits, paid time off, the gap between employment, etc.
When they want me to work more than 40 hours a week, they pay me for more than 40 hours a week.
Companies don't hire contractors over FTEs as software developers to save money per hour worked. They hire them because they need to ramp up development fast and need the flexibility of reducing head count fast. The only difference between an FTE and a contractor in today's economy is that the company is honest about your expendability. As a contractor, you should charge a premium.
From my experience (and quite a few people in a similar situation), as a foreign contractor I am making ~50% less money than FTE are making doing the exactly same job just because of the country I was born in.
I am not charging this learning time because I don't want/need to, but I would certainly not work with a company who would require me to do part of the job for free. However I am in a privileged situation where I can choose. Forcing an employee to do a not-in-the-contract learning for free is exploiting them (because they could have other needs to do in their own time, family, other jobs, etc). If they want to learn something on their own time that would improve their work that's great and definitely a plus, but not everyone can do that.
If I'm hired as a React developer to implement a set of business requirements, they are hiring me to learn and implement the business requirements. They are not hiring me to learn React. If they hired me with the knowledge that I'm not a seasoned React developer, the expectation is that they will not be expecting me to charge them for my learning React as billable time. How is that unfair? My React skills increase my marketability and I'm investing in myself by learning it.
If a person is not willing to sacrifice to learn skills on their own time, software development is not the field they should be in.
> If a person is not willing to sacrifice to learn skills on their own time
That's what I mean exactly. They might not have free time! That's why you're supposed to work 40h/week and any extra is a plus, not a requirement. The same argument could be applied to any field, so should someone without free time just not work? That's why it's unfair to require that employees spend large chunks of their free time to learn how to do the company's job.
If you don't have free time to learn to keep up your skills in the IT industry, you won't be employable for long. It's not about fairness.
Employers can bluster all they want; in the end, either they need to be happy hiring someone willing to work for the wages offered, increasing the wages offered and spending a lot more time looking (better wages gets you access to a larger pool, but it in no way chases away the incompetent, you still need to filter) or doing without the employee. As an interviewing worker, this means that you don't need to outrun the bear; you just need to be better than nothing, and better than anyone else willing to work for the same position. I've been working since '95 or'96, and personally don't feel I've actually been qualified to do any job I've had... but I'm better than nothing, and beating the competition is usually not very challenging.
As far as I can tell, the facts on the ground for contract work (which is to say, lower total comp than working as a FTE at one of the local big companies, lower job security, less respect, and generally slightly worse working conditions) means that when you are hiring contractors for a big company, you are hiring from a pool of people who are unable to get the same job at the same sort of company as a FTE.
Contractors making less and being less qualified aren't the facts on the ground at all in my neck of the woods. If you're making less as a contractor than the similarly skilled FTE, you're doing it wrong.
When I'm W2 contracting, I take what I think my yearly salary should be, divide by 1800 to allow for unpaid holidays, vacations, and 3 weeks to find a new gig and make that my hourly rate. I also add in a premium for the crap I know I'm going to put up with and the lack of benefits.
When you're contracting you get paid for every hour you work, if anything, being an FTE is more exploitive.
EDIT:
I guess I should add for context that I get benefits through my wife's very stable government job. That allows me to be more flexible with jumping back and forth between full time and contracting.
Also, it's much easier to shirk the "ownership" aspect of the products. FTE's typically handle the maintenance window in the middle of the night, the deployments, the firefighting. And they don't get paid for it. As a contractor, it's typically accepted when you say "I'm just a contractor, it's really not my product".
Yes, it's much more of a mercenary type arrangement. FTE's will oftentimes treat you as a second class citizen. But, you go home at 5pm.
But, what about job stability you say? Nobody has that. Working somewhere for 10 years and then suddenly getting put on the street is the worst case. You're hobbled. Finding a new gig every 1-3 years keeps you sharp.
This was actually the weird part for me, because I did some contracting around here in the aughts, and the pay was slightly better than fte work, but at that point, few of the FTEs I knew had significant bonus or stock grants. (You'd get options, just not RSUs) - as far as I can tell, this change to compensating developers with RSUs and bonuses is something that happened this decade; FTE comp went up dramatically due to bonus/stock, and contractor income remained competitive with base.
Of course, it's way different at smaller companies, or if you have the connections to avoid the body shops at larger companies, but smaller companies usually pay their full timers dramatically less anyhow, and if you have the kinds of connections required to go direct with the big players, being an individual contributor is probably not the highest value use of your time.
And I imagine things are different outside of silicon valley. Things are... very different and weird here.
Edit: oh also, 'similarly skilled' - I'm a contractor now, and yes, I get paid less than the FTEs I work alongside, I mean, I get slightly more than their base, but no bonus or stock. But... I'm also not similarly skilled. The FTEs doing my job are obviously better, at least by the standards by which we are evaluated. I'd give myself a 1 in 10 chance of passing a technical interview for a FTE job at the company where I contract now, and that is, uh, displaying confidence. My point wasn't that things are unfair; I don't think I'm being treated unfairly, aside from a few minor points, but that after the body shop takes a cut, there's just not enough left to pay enough to get people as good as what you get when you hire for the ridiculously well-compensated FTE positions at the larger and more prestigious companies in silicon valley. And the company matters; I interview often and just a few months back turned down a FTE position at a lesser company, for reasons having to do with pay, prestige, and trust.
Hell, even if you're using a framework that I'm intimately familiar with, most frameworks are flexible enough that it'll take a little while to get used to exactly how you're using it.
I invest in my staffs' intellectual equity too, but usually ask them to do their reading and learning on the clock.
1. Don't obsess over the specifics on an ad. See if the role is in line with what you have to offer, but don't worry if you don't have the exact number of years of experience they request or one of the many skills they added to what it's essentially their wishlist.
2. Provided you have a solid foundation with some standard skills like JavaScript, Python or Ruby, etc, specialize in a relatively new stack. No reasonable employer expects you to have 10 years of experience in Elixir or React.js. Note also that I used the word stack. You want to become competent enough to become useful to a team that adopts the same stack. Depending on where you live, you might go more or less niche in terms of the stack.
3. Start a blog and advertise the fact that you are looking for a junior position. Document your experience, post about what you are learning, what excites you, showcase your pet projects, etc.
4. Attend meetups. Let people know that you're available.
- You will bring people out of the woodwork who are in similar positions, but haven't taken the initiative to start such a group themselves.
- You'll gain contacts in your scene, both locally and in other cities.
- You'll gain experience and profile that will help you in a search for remote work, as you can point to community engagement activities that say a lot more about your dedication than a couple of udemy courses in some particular stack.
If you really don't want to start a local group (or if there's no nearby community large enough to support this) then look for user groups with active online communities (mailing lists definitely count) and try to make some occasional trips to other cities for meetups and conferences.
It won't make your city any less dead, but if you get online and help people with what you know, and learn from others, you'll certainly make friends.
One of the specific pieces of feedback I got was that my development style wasn't modern enough - with a recommendation that if 'your current employer isn't exposing you to best practices and new approaches you should attend some relevant meetups in [city]'.
My personal negative take on that was that meetups tend to concentrate on the latest fad. The interviewer could have gone to one meetup in a series and seen one talk/library/strategy that resonnated with him. I could have gone to the next one in the series, picked up something completely different, and still failed the interview?
Thoughts?
Or, in the case here in Seattle anymore, whatever the sponsor company is trying to promote.
2/3 of the meetups here anymore are mostly tech's version of timeshare seminars.
Engineering skills translate well between stacks and framework/library skills are only good for a couple years. Can you break down a complex problem into estimatable chunks that can potentially be delegated as well? Can you design a system that solves a business problem? Awesome! Nobody will ask you about framework du jour.
Honestly I’d say that if you’re talking at the level of which libraries/frameworks you know, you’ve already lost. That’s junior/midlevel engineer stuff.
Senior engineers solve problems. Junior engineers code in frameworks.
Most code that’s used in production has so much custom stuff anyway that it might well be its own framework.
Additionally I want someone who can be passionate about the tech stack and frameworks they are using or plan on using. Otherwise, I've got a code monkey who may get things done in the short term but their code and problem solving abilities actually has negative implications in the future when it comes time for maintenance and to add additional features to things.
I don't understand why people label others who care about their craft and the tools they use as junior/midlevel. I think that's lazy. Many times there really is a best way to solve a problem or a best framework for your particular situation or problem. All engineers should care about the tools and what is being used and why it's being used.
I guess its just not enough for me to have an answer so much as to understand why its the answer and under what conditions assumptions can fail. To me that is more valuable when hiring someone who is switching careers than being able to solve a problem in a generic sense.
Because we’ve gone through 10 different frameworks already.
I’m not a jQuery engineer or a Backbone engineer or an Angular engineer or a React engineer or a Redux engineer or a MobX engineer or a Node engineer or a Rails engineer or a PHP engineer or a Python engineer. Yes I’ve used all od those to deliver real world projects that made money for my clients/employers, but they’re just a tool I use. Many such tools have come and gone since I started building stuff for the web in the early 00’s and many more will come and go before I stop. I love building stuff and I have a deep understanding of the web, but tools are just tools, they don’t define me.
Yes you want a carpenter with a good understanding of hammers and nails and you need them to know which to use when, but do you really want to hire a carpenter who identifies themselves as “Expert hammerer of 5 inch nails”?
Ultimately, if you are looking for an expert hammerer of 5 inch nails, I am not a good fit. And that’s okay.
I usually lean towards the pro- side in arguments about passion for one's career but even I would have to say that's a rather dubious viewpoint. Tech-stacks/frameworks are the among the least important parts of a software engineering career; they're the means to accomplish the craft, not the craft itself. (And that's even if frameworks didn't go into and out of style almost as fast as the fashions in the clothing industry.) It would be like asking master chefs to be passionate about spatulas and whisks instead about creating great food.
Also, apply for jobs with different frameworks where you have experience solving their type of problems. That knowledge is much more valuable on a long term basis.
Ask questions like "are you actively making contributions to this framework?" If so, you probably want to know it. If not, just remind them that it will most likely take much longer to ramp up on their (non-public) codebase, but your skill is learning things and solving problems. If you're not employee #1, a lot of the framework plumbing is probably already done for you.
I had good luck with suggested resume format of company project I worked on description, and what I did for them on said project. I put together a "portfolio" of screenshots of things I worked on with a description of what I did as some projects were behind a login and the public didn't have access (I created this graph of power usage using highcharts......)
highlight the problem solving skills.
I have to sort through a lot of resumes at my current job and sometimes I honestly can't tell what they worked on. If I sense enthusiasm, and some experience with what we're looking for, they go on.
I'm definitely not a people person, and you don't need to be, you just need to keep up to date with what people in your network are doing. If there is anyone now in a management role, try to meet up with them for a coffee once a year just to chat. Maybe they are looking for someone with your skills (that's happened twice for me). I've also been in the situation where they aren't actively looking for someone, but knowing that I'm available and that I do good work they've made a position just for me.
I've only worked at smaller companies, so I'm not really sure how this would work at the scale of something like Facebook, but other than them having to navigate HR I don't see why it couldn't work.
http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
Patrick may have a skewed view of reality because of his experience but this (and his other posts) brings you in the right mindset.
Side projects which are basically a "hello world" in framework X are not impressive so don't waste time with polluting your Github with N hello world examples.
Instead create something more substantial, either contribute directly to the library/framework which is core of the new tech or build some useful new addition to the ecosystem.
Write some blog posts along the way as you learn and become more and more familiar with the technology and different edge cases.
This, from my experience will get you a lot of interviews.
Also, during the interviews, don't say things like you are pivoting, instead tell them that you are expanding your expertise in a new direction or making a next step in your career. Or that you want to work with this new tech on a daily basis and this job would allow you to do that.
Another method is find a company you want to work for, find where they keep open source projects, and work on them. When they have a job opening you'll be the one they contact usually. Databases, frameworks, Docker, ect are all good for this. Mailing lists and open source projects is how I usually get work and avoid the phone screen demanding X years of exp.
A broad technology such as having experience with "databases" or "functional programming" or whatever might be appropriate, but if an ad says "need N years experience with Framework-X" etc. then run away.
If your first contact with the company is a non technical HR person screening you for the appropriate buzzwords: also run away.
Specifically to get your foot in the door enough that they'll hear you out. If you're truly experienced and capable of picking things up quickly, it shows in an interview (at least when I'm the one doing the interviewing).
In terms of not lying on your resume. Side projects/join a company/team that uses both your stack and what you want to use. Remember, your new company does not actually know how specifically you spent your time at your previous jobs. Was it 50/50 or 95%/5%.
Remember you can learn things a lot faster than n-years experience. So, spread that out over a few years and you do have n-years experience.
When I did a small pivot in my career I basically had to start from scratch. So I sit by myself and start working on a project learning what I wanted to work for. Once I was a bit comfortable I apply to mid-level and junior positions.
Personally, I don't look at the years of experience someone has, but at the projects that the person worked on and how good that person is at answering some technical questions (to weed out people that lie about their experience and knowledge).
If you are good at what you do, then have some projects to show your expertise. And there are a few options to get them:
1. help a non-profit for a lower pay or even for free 2. contribute to open source projects 3. create a project of your own where you can show what you can do
> What did you do to get a response back from jobs you've submitted an application to?
When applying don't talk about years of experience, but about what projects you completed and how you managed to get them done.
What's wrong with projects from previous full-time jobs? My most complex and interesting projects were done during paid hours and since I usually was the only person working on these projects, I can proudly call them "mine", despite being owned by an employer. From the perspective of an employee, if you demanded to have non-paid projects I would thank you for an interview and say "goodbye", even though I have some of these.
I find it completely bizarre this has now become the standard in hiring software engineers.
If I may suggest that the title 'junior' or 'senior' is artificial and generally unhelpful in the sort of quest you are on. If that sounds harsh I apologize, when I see development resumes I don't see "levels" I see strengths and weaknesses.
A developer that can pick up a frame work quickly and be productive in it is "strong", one who continually re-factors the problem so that they can re-use the framework they already know is "weak." A developer who can discuss the trade-offs between multiple frameworks in terms of solving the needs of performance, manageability, or resource usage is "strong", one who only knows the trade-offs and pitfalls of the framework they are most familiar with is "weak." Developers who are working on improving their understanding and craft are "strong", developers who are don't understand why their particular framework does something the way it does are "weak."
That is a lot of admittedly contrived examples but I hope they illustrate the kind of developer I look for when I'm hiring. If you have 10 years writing code I want to see a wide understanding of a lot of different systems, if you have 2 years writing code I want to see you understand the key design elements of the systems you are using, and have some idea of why those design decisions were made. It is the difference between being able to code, and code fluency.
So to answer your question, if someone wants "years of experience in a stack" then they may be using that as a filtering mechanism to get rid of people who are unsure of their abilities. I remember reading advertisements in 1998 for people with "5 years experience in Java" when Java had really only been released (early alphas in 1995). I wondered if they were just trying to hire folks who were part of the original team (which went back to 1991 :-). Talking to recruiters though, they were really looking for people who were so excited about Java that they had done an in depth dive on their own. Perhaps you are seeing something similar.
My advice to you is to lead with your strengths. If you have examples that demonstrate those strengths or projects which demonstrated them put them in too. Be honest with yourself about your weaknesses and think about ways to you can eliminate them. Be the strongest developer you can be and always work one ways to develop additional strengths. The rest has, in my experience, taken care of itself.
One of the skills you have as a senior dev is that you can come quickly up to speed on a new stack in whatever your field is. You understand the underlying problems, learning the new incantation to make things work is comparatively trivial.
Note: If you entirely switch fields this does not necessarily apply.
In general, don't take job d requirements too literally. Research the job & the company and write a nice cover letter and I think you'd do fine. Worst case you don't get the job.
I run coderfit.com, a niche tech recruiting agency in Zurich, Switzerland. If you look for Bay Area salaries in Europe, shoot me a mail!
Any fancy wording will not hide the fact that you do not yet have work experience in the new stack. In fact, you should make your situation clear, to save you and employers time and effort. The sooner you find out you are not a match, the better. That's probably what has been happening. The companies you have been applying to are probably looking for specific experience, and you do not qualify. So they do not reply at all. Each non-response brings you one step closer to finding a match. You know another company which is not right for you right now.
Recruiters are paid by the company to bring in people with specific experience. With no work experience in a specific stack, recruiters are probably not the way for you to grab the bottom rung of the ladder.
You have to talk to people. Lots of people. Ask each one, " Do you know one company which is currently hiring junior people with little or no experience in a specific stack?"
Look for a company which WANTS a junior programmer with little or no experience in a specific stack. They are much harder to find, but they are out there. It's not easy, but it's possible.
If you have these skills you can apply them to different software stacks or technical problems. A high-level and decent understanding of the subject is sufficient.
Steve Jobs had no expertise building computers.
prove that you have experience with a topic rather than years.
build a portfolio of working stuff.
or
skunkworks something at a current job and if it is successful use that as a selling point in your resume.
and don't use the word pivot. ever.
I instead started a software dev side-company that specializes in minimum viable products for very early-stage entrepreneurs. I fish around Linkedin for clients who pay me anywhere between $1000 and $3000 (i honestly just eyeball the amount). For the most part, I pick the stack or look for clients who want a specific technology so i can learn it. This counts as professional experience since I got paid for it.
This is a seller's market. How much trouble are you having getting responses back?