Do you have any recommendations on how best to sell yourself from such a position? I have a significant C99-era/close-to-the-assembly fundamentals background, but I see a lot of “if you haven't already AWS'd all the AWS at your last company in production at scale, then there's someone behind you who has”, and that kind of thing has both been a notable lacuna in my experience and something that's notably less fixable independently than e.g. “plow through a React tutorial to familiarize yourself with the basics”. In particular, it seems like in the heavily external-service-integrating style of development, a lot of experience comes in along the lines of “remembering the pitfalls you ran into with particular vendors under particular loads” and the fundamentals don't get you as far. But I hear a lot of conflicting things about this.

I'm someone who's (supposedly) quite good underneath but has stagnated a lot over the last few years (and on and off before that, sadly) as other issues drained away my ability to work. I'm gradually stabilizing things and trying to find the best way to maneuver, and I'm pretty worried that everything's going to pass me by because my experience isn't of the right kind and I'm not legible enough. The people who are getting the jobs with all the traits I want are the ones who got a Real (that is, close to culturally archetypical) Job in 2018 and did their time in the salt mines with the three verifiable contiguous recent years of experience.

If what you say is true, then it's possible what I mostly have is a marketing problem, and it may be that e.g. some of the “actual demonstration of ability” is more readily solvable with “pull some stuff out into public repositories and freshen it up” than I've been imagining.

Write a script that deploys something to a fresh ec2 instance.. then you can say you used aws for your side project.

Aws is like 800 services, but under it all is ec2 and s3 -- just get familiar with those and the rest are conveniences.

This is not an unreasonable point, but I will note that I was partly using “AWS” metonymically to refer to a whole cluster of technology decisions surrounding the current wave of “cloud” everything, and I was also partially referring to the purer “have you been part of a full-scale service deployment with real users” aspect—there's a bigger difference between “operating a service when there's hundreds of thousands of requests from real people hitting you and they really count” and “operating a service for a random who-cares project” than there is between, say, “having a precise understanding of how Ruby behaves in a business-critical backend” and “having a precise understanding of how Ruby behaves on your laptop”. Lacking experience or even just lacking legibility of experience on the former seems to close a lot of doors, and that means you run into the “need experience to get experience” cyclic dependency on a critical subset of what's needed, regardless of how good your other skills are.

I recently had a job for exactly a week before the company decided I wasn't working out. One of the things they had me doing was logging in to Azure and trying to debug something - even though Azure never came up during the interview process, only AWS. It seems they didn't recognize there was any difference between them.

Hey, by stagnating I mean I’ve barely written code in over a year, and haven’t done any significant greenfield work my whole career. The work I have done has been mostly in legacy or obsolete technologies, and by that I mean mostly old version of stuff that’s still out there.

So by stagnating I don’t only mean not up on all the new hype tech, but also the caricature of a “code monkey”. Certainly on paper at least.

> you're not going to agitate for infecting my systems with Kubernetes specifically because I now need to orchestrate ten times more production machines to run the ensuing inefficient bloatware.

Sadly this seems to be the sort of thing that most employers want.

  I’ve barely written code in over a year, and haven’t done any significant greenfield work my whole career. The work I have done has been mostly in legacy or obsolete technologies, and by that I mean mostly old version of stuff that’s still out there.

There are heaps of legacy code out there needing to be maintained, and it seems like all the cool kids just want to do green field dev because fixing somebody else's insane code isn't "fun". You're likely more qualified than you think, you just need to market your strengths.

Get on with a contracting firm. They will place you on a dev project and have you coding in no time.

A lot of companies are not allowed to interview the contractors (since they are not employees) and the contract firms can swap anyone into a spot after they get the contract signed. (Granted there is a lot of wink and nod stuff that goes on)

Horrid pay, not allowed to say you worked for (GE, Microsoft, whoever...) and crap benefits but you get real world experience and may even get lucky. You can say..."while at Microsoft I..."

Nobody writes tools that only work on brownfield code, and there are plenty of tools that only work if you start a new project using their tools.

Green field code is easy-mode, not hard mode. Nothing is in your way, nobody expects anything from you (yet) because they have no basis of comparison. The real reason people want to do rewrites is that they want that greenfield experience without having to quit. It almost never works.

Start a new project on the side, using the skills you’d like to develop.

How do you balance this on the resume. I got plenty of cool project ideas, but outside of entry level, it just seems odd to list them on the resume (which I presume is the only way they’ll be seen by anyone giving the consensus on LinkedIn and personal sites). o feel it’d just look weird when you have projects and skills that seemingly have no relevance to your work experience especially when applying to roles that are mid level or senior.

It seems that a lot of things are just no possible to learn on the side as well. For example, doing anything at a large scale. That could be HPC stuff or just designing and building systems that need to handle high throughput without slowing or failing. I can’t afford to have the sort of projects that would allow me to learn those things.

The exception I can imagine is working on high visibility OSS projects and is a huge time sink and might as well be a second job.

Too negative an outlook, imho. You do the research and add the keywords, maybe project to your resume. If grilled you say I have some experience but am not an expert.

Also, you’d be surprised how much you can get done on a modern PC with vms or containers, it isn’t the nineties or aughts any longer. We used to run a full vfx company on what amounts to a single souped $10k PC today.

Or, rent a heavy-duty cloud vm for $100 a month, small investment but clock ticking will get you motivated.

While there’s truth to this, I’m gonna guess it’s a minority viewpoint.

>If you're an old school C programmer who knows how pointer arithmetic and memory allocation works

bonus points if you created a vuln or two :)

Well, the thing is, the people you described are the ones doing the technical interview. They hire people similar to them.