Or maybe you were just one of the lucky few.

The problem is when you have to go in cold and pass a google-style interview just to get considered for any job, even at a greeting card company. The now ubiquitous position where "we only hire the top 1%."

With that much competition, being old puts you at a definite disadvantage. Especially when tech interviews focus on CS trivia rather than engineering design and experience, to the benefit of those fresh out of college.

Not every place is a startup of course, but the cargo-culting of interview "best practices" has spread far and wide as stodgy companies yearn to look cool.

Over a decade later, when I really started taking my career seriously again, I made the same calculation. I had two choices, I could accept an offer that was paying more but using a technology that I didn’t see having a future or taking a job paying only little bit more but was clearly a better long term play technologically. I’m aggressive about keeping up and having a competitive resume.

I respond to every local recruiting company that reaches out to me. I keep them in the loop, I’ve met a few recruiters for lunch and I refer my favorite ones when I know someone is looking. I’ve also done hiring through recruiters.

The problem is when you have to go in cold and pass a google-style interview just to get considered for any job, even at a greeting card company. The now ubiquitous position where "we only hire the top 1%." With that much competition, being old puts you at a definite disadvantage. Especially when tech interviews focus on CS trivia rather than engineering design and experience, benefiting those fresh out of college.

I am still hands on. But, I had to elevate myself above being seen as “just a Developer”. I’ve been asked simple technical questions to determine whether I had basic competence, but all of my interviews over the past few years have been along the lines of “draw out an architecture” or “describe how you would solve these $hairy_problems we are having. I have never been asked a leetCode type question. The closest I’ve gotten was writing a merge sort on the board - I did, got an offer but I was so turned off by the entire process that I took another job instead.

Namely staying at one company too long, not keeping up with changes in technology, not building soft skills and having no network.

All I’ve done is kept my skills current, lived in a place where there are a lot of corporations who need developers, learned how to interview well (not leetCode interviews just general interviewing) and kept a warm network.

What has been your strategy to "keep up"?

I ask this because I recently left a job I started in 2014 where the people were great but the technology was old, not modern at all.

In the time I was working there Docker, React, Vue, Serverless, GraphQL, Kubernetes, gRPC have all become a thing.

I didn't have a chance in my work life to use any of them and it was my first job, so I couldn't easily change (it's different now I suppose).

In my experience it takes between 300 ~ 500 hours of solving new problems and challenges before you're really proficient with a technology and have gained a certain mastery over it.

It also seems to be the case that a technology lasts about 5 years (roughly speaking).

So this then presents me with a scenario that I need to spend 40 hours working a job where the tech stack will most probably not contain all the new hotness. Then after family duties at home it's now 9pm and I'm free. If I were to get 8 hours sleep I want to sleep between 11pm and midnight. This leaves me a window of 2~hours a day. If I need to spend 300 ~ 500 hours to gain proficiency in a technology that's then I need to spend my two hours from 9pm to 11pm either learning two technologies to a reasonable level or one technology really deeply.

Surely that just isn't sustainable?

Now, obviously that's the brute Force strategy and it can be improved a great deal.

I'm very, very interested to hear what your strategies have been!

I want to able to do this without killing myself. I love tech, I aspire to be in a similar position as you. Good stable work, working with stuff that's fresh and being a high value, high level, hands on contributor.

Some optimizations that come to mind (and chime in with your thoughts on these, so I know if I'm on the right track!) are that I should choose my working environment carefully to optimize for working with the technologies that are going to matter so I can do a good deal of learning on the job. Second I should pick what I'm going to say no to and drop the mental load of having to care about those things. Three I could work 30 hours a week and study for 10 giving me a great balance of doing what I love by contributing to a team but also doing what I love by exploratory learning.

Anyway, very keen to hear your reply.

- you nailed it. Pick jobs where you are learning new technology. Usually you can get a job where you can get your foot in the door based on the “must haves” that also have “nice to have” requirements. I’ll learn just enough about the nice to have technology once I get my foot in the door, and then volunteer for small items using the new to me technology and usually end up putting twice the amount of work in that someone who knew what they were doing.

- once you’ve been in technology long enough, there is nothing new under the sun. You don’t have to be an expert at everything just good enough to get through the door and you can usually figure things out.

- when I start talking about my professional experience and going for “architect” level positions, I can usually avoid the techno trivia type of interviews. I’m asked to speak about higher level architecture.

Once I start telling people that “first and foremost I am a life long geek. No matter what my titles were in companies. I started programming in 6th grade in assembly language and I’ve been interested in technology ever since”.

Even though I say ageism is not a big deal. Why would I take the chance? I remove the year graduated reference from my resume, I wear a bald head anyway so no one sees gray hair and before an interview I’m clean shaven.

My former manager said he thought I was no older than early thirties. (His words not mine). “That’s one thing Black guys have going for you. If you cut all your hair off it’s hard for us to tell how old you are”. Yeah it wasn’t PC but we had that kind of blunt conversation. I thought it was funny.

Did you forget to finish this thought or can you expand on it? I'm guessing it softens people's view towards you?

>Usually you can get a job where you can get your foot in the door based on the “must haves” that also have “nice to have” requirements.

Sometimes those "nice to haves" feel like "must haves". I try and get projects out to demonstrate competency with a tool/platform/framework, but as the parent suggests it's an absolute time and effort sink (lately I've been trying to wrap my head around a specific k8s configuration I want on AWS). On occasion I'll mention what I'm learning in my first email if its relevant for their interests but I've never felt it mattered and it never gets brought up.

>I’ll learn just enough about the nice to have technology once I get my foot in the door

In this case is your foot in the door first getting into talks with the employer (so you're prepared to talk about it during e.g., negotiations) or is it landing the position? It sounds like the latter, but just making sure.

Thanks for all your posts in this thread. I've been trying to start my career and appreciate you sharing your experience.

Some people maybe weary of hiring an older dev because they think that either we really want to be managers and are just accepting a dev role or that we are old and stuck in our ways and not willing to learn the latest technology.

I try to come off as someone who is just computer nerd who isn’t trying to move up to management or who doesn’t think these “kids” are dumb.

On occasion I'll mention what I'm learning in my first email if its relevant for their interests but I've never felt it mattered and it never gets brought up.

I don’t send out blind emails or submit resumes blindly. I have a network of local recruiters I’ve cultivated over the years. They usually put my resume at the top of the pile and push for me. I’ve done so many interviews on both the hiring side and the employment side and have usually been successful, the recruiters think of me as easy money. The recruiters also know salary ranges, the interview process, what you need to focus on etc and they can tell you what other people interviewing struggled with.

In this case is your foot in the door first getting into talks with the employer (so you're prepared to talk about it during e.g., negotiations) or is it landing the position? It sounds like the latter, but just making sure.

My first job out of college was a computer operator based on an internship I did the year before. I got in, got lucky that they needed a fairly complicated data entry system written and I was the only one who could program. It was C.

Next job was through a recruiter based on my knowledge of C. I knew the C standard in an out, spent a lot of time on comp.lang.c (Usenet).

The next company I went to almost a decade later wanted my VB6 experience of all things and they were transistioning to C# (where I wanted to be).

Next job wanted a backend c# developer who had experience with c# and Windows Mobile (the “must have”) and front end Jquery experience and MVC, Entity Framewo and unit testing (“the nice to have”)

Next job wanted someone all of those skills and the nice to haves were Bootstrap and Angular.

I didn’t have any of the “nice to have skills” at any of the jobs when I started.

Finally, I got a job as a first time dev lead based on the accumulated experience and a lot of reading (Clean Code, Domain Driven Design, Enterprise Architect Patterns, Gang of Four Design Patterns, anything by Martin Fowler).

That’s where I discover AWS and that helped me get my next job. I knew .Net, had some knowledge about AWS but hadn’t used it extensively.

So now I’m starting down the road of being an “AWS Consultant” more focused on the software/Devops side than the networking side (they are a dime a dozen) and at the same time I have a chance to fill in some other gaps like being at least a competent front end developer and Linux.

Thanks for all your posts in this thread. I've been trying to start my career and appreciate you sharing your experience. No problem,

I try to bring a non SV viewpoint to software development. But one thing I don’t have any experience with is being a “junior developer”. My first job was designing a system that was used by an entire new line of business for a company.

Now I do have experience with being an “expert beginner”.

https://daedtech.com/how-developers-stop-learning-rise-of-th...

I really appreciate the responses here. Some very useful insights indeed!

I would like to think that if it ever came to it, I would always choose technology over money. Every month that you keep using older technology you’re accumulating technical debt in your own career.

"we are all developing on top of either AWS or Azure and are actually using the technologies they provide and not just hosting a bunch of VMs"

I didn’t know the first thing about AWS and neither did anyone else - including the infrastructure guys. So we hired some “consultants”. I did a PowerPoint slide of my architecture with the consultants for thier guidance for best practices.

Basically they just set up some VMs, security groups, a VPC etc and they treated AWS like an overpriced colo.

I spent the next few months designing and architecting everything like I would have done on prem:

- 7 servers for Hashicorp’s Consul (1 in Dev,QA, UAT, and a cluster in production). They were used for configuration, service discovery, internal load balancing (with Fabio), and health checks.

- 7 servers for Nomad (same as above) used for orchestration and to schedule jobs. Think Kubernetes but with the flexibility of using raw executables and not just Docker containers.

- 7 servers for Mongo (same as above)

- 12 always running app servers.

- 2 build servers orchestrated with Visual Studio Online and local build agents.

Of course all of these machines had Microsoft agents (?) on them for deployments, Consul agents, and the app servers had Nomad agents.

This would have all been perfectly well architected for an on prem environment. But anyone who knows anything about AWS (and I didn’t then) would know that’s a dumb, overpriced, hard to maintain design and we weren’t taking advantsge of AWS services.

If I were doing that now. I would:

- get rid of all of the Consul servers and use AWS’s Parameter Store for configuration. Use internal AWS application load balancers and route 53 for services along with autoscaling and health checks.

- instead of Nomad, I would have used CloudWatch Events and done a combination of lambda, step functions and Docker. That would have cut out 7 more servers.

- I would have used AWS CodeBuild that basically let’s you use either prebuilt Docker containers for builds or create your own. Cutting down on 2 more servers.

- Today, I would use AWS’s hosted ElasticSearch solution instead of Mongo. But given the needs of the project, I would have used Mlab’s (?) managed offerings.

Of course I would use CloudFormation to manage all of this including the configuration key/values instead of my own bespoked app to source control configuration changes.

I've been curious to learn some of this stuff.

Even if you try to avoid lock-in. It’s usually not worth the risk of regressions and downtime to change your underlying infrastructure once you build on top of it.

The chances of AWS or Azure going out of business in the grand scheme of things is not worth the trade off.

1. Being able to do this would mean lots of work to abstract and polyfill the discrepancies between providers.

2. If AWS or Azure goes down globally, everyone else would be too busy freaking out about their own problems than be worried about the downtime of your SaaS.