Wish I could upvote more than once. Azure artifacts has some fucky authentication requirements (cleartextpassword is the dumbest field I’ve ever heard of - especially since it’s not clear text or a password, it’s a base64ed PAT) but there’s plenty of first party support to make it less painful, and it’s a problem you only have to ‘fix’ once.

Our prior solution was verdaccio for NPM and a shared drive location for Nuget, and….well, it beats the tar out of either of those. Being able to see exactly what’s in the feed, when it got there, who put it there….all grade a stuff. Handling SSO and such seamlessly is nice too, and being able to scope access with tons of granularity….well it seems like a rake waiting to be stepped on, honestly, but if you need to manage access it seems like a big win.

Public feeds - yes. Why reinvent the wheel? Will be easier to find and use if it’s on nuget.org.

If OP’s goal is to be able to source control all the public packages that their projects use, for security or peace of mind purposes (or to make it the sole source of packages to avoid dependency injection/confusion attacks)…there’s actually a feature of Azure Artifacts where you can pull packages from an ‘upstream’ like nuget.org and host public packages in a private feed. It’s got a gui, and it’s pretty convenient as far as such things go.

I watched it in Vim, mostly because I don’t hate myself enough.

Not to spoil the ending either, but the nuclear device goes off because Oppenheimer smashes a bunch of keys and then finally remembers :wq.

That sounds brutal man; do you mind if I ask what stack/language? What kind of company were you at before?

We’ve been hiring (for real) but only for more senior positions. Fintech.

Have you tried contracting? Especially if you’re asking them to consider you for junior level positions, that might be a good bridge into something more long term; keep the lights on and let you keep searching and in the meantime some company gets an amazing deal on your talent.

Good advice already in this thread, but I'd add: ask smart questions, and when you're engaging with a senior/mentor, build the picture for them. Everyone (including your mentor) expects you to have questions - they want you to ask questions, rather than just spinning your wheels for days and days. But they also want to know what you've tried and what you've looked at for resources. And despite appearances, they don't always have the entire code base committed to memory. :)

For instance - suppose you'd been asked to, using the UI, return a piece of information from an external API and display it within the UI.

Bad question: "Hey, so I tried to integrate that third party API, but I'm not getting a return."

"Okay - what kind of code are you getting? And what do the docs say?"

🤷‍♂️

Good question: "Hey, so I tried to integrate that third party API, but the return I'm getting from it is a 401 error. That should be an authentication error - but just in case, I pinged their server from our server, and they can reach each other. The documentation says that I have to use our key to get a JWT, but hitting the endpoint it says gives me a 401 error. I double checked our token; I've got the right one. And I'm sending it in the header as 'auth' like the documentation says. Where else should I look?"

"Oh yeah, that's a tricky one - you have to encode the token before you send it; let me see if I've got an example where you can see what that looks like....."

One of the things that will happen over time, based on the questions that more senior SDEs ask, you'll be able to 'rubber ducky' problem solve by asking yourself the questions that they would usually ask you, and it's shockingly effective to help you sort your own problems out and clear your own blockers.

I think you have an interesting background and potentially interesting technical skills, and I could totally see you catching on with someone and having a fantastic career. I could also see why it would be a weird or awkward fit, that you might be totally overwhelmed, and possibly even hate it. Let me qualify my answer(s) and see if that helps at all.

I feel like at its heart, being a DevOps is just being passionate about tinkering and technology. The best DevOps Engineers I know love nothing more than to nerd out about....well, all kinds of stuff. From K8s to Linux distros to build tools to code. DevOps is a practice, not a skill set - and that's reflected in the fact that there's no 'base' skill set for DevOps Engineers. I've known developers, sysadmins, even help desk type folks that found their way into the field and were successful. It just depends.

It kind of feels like you have the heart of a tinkerer, and the fact that you have a MS in a hard science suggests that you have the brainpower to hack it - maybe literally. :)

That said - what would worry me if I were considering hiring you is that you don't really have any exposure to Software Development Lifecycle concepts. Maybe I'm too stupid to understand all the acronyms above, but in my (limited) experience, having a good handle on SDLC is sort of the beating heart of DevOps - at least in part because being able to have the infrastructure ready to mate up with the code at the right time and right place is like, 80% of my gig. Too early is a security vulnerability (potentially), too late and the dev team misses all their sprint targets. You don't have to write code, exactly (although I wish I wrote more), but you have to be able to 'follow along' with the dev team. Especially when you're troubleshooting.

For SRE particularly - you have a lot of nice sysadmin-y type background skills, but particularly understanding design patterns and telemetry would be the thing I'd be most nervous about for you. Scalability as well - although that's hard for almost everybody. But for an SRE to improve reliability, you have to be able to really hone in on what's breaking - and once you've gotten the big pieces sorted, being able to understand resource usage, and all of that points towards good instrumentation (and good instrumentation practices).

I joke that reading logs is my superpower - both because my devs, bless them, don't do it, and also because if we've done a good job building the application, build/deploy pipelines, and infrastructure, your alerts and instrumentation will tell you exactly where any pain points are happening, and make it a lot easier to figure out where and how to focus your efforts moving forward.

So, after that wall of text - I'd point you towards the cloud. AWS is the largest/most widely known, but arguably kind of opinionated in terms of implementation. Still, AWS Solutions Architect is a pretty good 'gold standard' type certification. If you're more familiar with GCP or Azure, do the 'associate' level certs there.

Another obvious thing that I didn't see in your background - VCS. Git gud, as it were. I'm a big fan of hanging pretty much all your personal projects on GitHub. Mine is atrocious since I got hired, but before that I had a full year straight of commits. Sometimes it was impressive stuff, most of the time it was just messing around with code - but all the companies that gave me an offer letter mentioned it. Ymmv.

Finally - you might expand your search a little wider (SysOps instead of SRE off the bat? DevOps as well? Maybe going straight stick software dev, with your background, at a company where your science background would be a real value add is something to look at) and also be prepared to 'take a step back' if you do jump. I'd definitely hire you to see how things go, but I'd want you to come in as a Junior, and based on what you wrote above, that's probably a bit of a paycut for you.

TL;DR - Do cloud certs, practice on GitHub so employers can see what you're working on, consider SysOps/DevOps as well as SRE.

Best of luck to you!

There's probably a bit of a disparity, but it's not nearly as much as you're making it out to be.

In the US it depends greatly on the industry and company - I don't know anybody making 200k-400k in software development (CTO? sure. Devs writing code? Nah), but I also don't know or work with anybody that's in FAANG world. Those are the companies paying $100k+ for a junior.

I live and work in a lower cost of living area, for a company that's not 'software first' and our juniors come in between $50k-75K. And that's not the lowest I've seen for junior engineers starting out.

That said - it's also not unusual for mid-career folks to be in the $100-150k range, and seniors/leads moving up from there.

So with all that in mind - some of it is market forces (are there more devs and/or fewer dev jobs in Europe than in the US? Potentially less mobility?) but one of the bigger causes (I'd guess, anyway) is the lack of FANG type "Master of the Universe" companies. Part of the reason juniors and seniors command that kind of pay in the US is because the rates that the FANGs pay tend to 'trickle down'. The average senior/mid career dev may not be interested (or capable!) of working at a FANG - but if the other people in their hiring pool are, they're still going to command that kind of salary.

As a point of comparison - my understanding is that financial services is sort of the same thing. Most Euro bankers/stockbrokers/finance bro types are pretty heavily underpaid compared to their US counterparts. Some of that is regulatory, but a lot of it is that there are more higher paying jobs in the US, mostly at the big multinantional conglomerates you can think of off the top of your head (Goldman Sachs, Bank of America, Citibank, JP Morgan), and that tends to drag the scale up throughout the whole system. A rising tide raises all boats.

Anyway - I don't have any research or statistics to back any of these suggestions up - hopefully Cunningham's Law gets us a 'real' answer. :)