Hacker News new | past | comments | ask | show | jobs | submit login

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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: