Not to mention the fact that I will spend the next two year learning front end frameworks and Docker ecosystem. I’m 45

That said, it sounds like you and I are both "cultivating" and "tending to" our profession. I think that's what it takes to stay competitive and have longevity imo.

I got into vicious codependent cycle with my job by the time I was 35. I didn’t know enough to be competitive and leave, I was bitter about my pay and they just kept me around because I knew where the bodies were buried. Since then, it’s all about optionality. If I go more than a month not enjoying my environment it’s time to leave.

Considering swinging the pendulum the other way to hands on technical again and let others do the BS work. Do you know anything about the north Atlanta market? Companies, salary range, culture? Or maybe ones to avoid...Thanks!

With today’s data privacy concerns and tough European regulations I don’t think this attitude is acceptable.

I hope the field makes a return to appreciating fundamentals.

That being said, I was on the hiring committee at my last job and personally, I found the best way to hire engineers is to just chat with them about previous projects. I'd usually run through one or two, "just confirming you can code" whiteboard questions and then ask them to tell me about a project they are proud of that they had a large part in. If you ask questions that dig into the project ("How did you do X?", "Why did you do Y?", "Now that it's over, what would you change?") you can usually get a pretty good idea of their skill level and knowledge as a developer as well as some great insights into their personality.

Obviously, that's much harder to scale and more subject to bias, but it worked for me.

Short of industry wide collaboration with some kind of longitudinal study, getting an idea of what does and doesn't work in terms of false negatives is nearly impossible.

1. are my false positives low?

2. is the time it takes to fill a position low?

If the answer to both of those questions is "yes" then the system is great for me (and I've seen the system described above provide affirmative answers to both these questions in a startup setting).

Determining whether a hiring system is locally good is significantly easier than determining if it's good in general.

The problem is that you don't know the cost of the false negatives; you don't know whether the people you didn't hire would have greatly improved your processes / code / business

It’s probably not the stuff you know how to do that makes or breaks your company. Either someone else does it, or you “figure it out” and hopefully you know if you did it right before it’s too late.

How do you hire someone to be good at stuff you aren’t already good at? There’s gonna be a lot of those in the false negatives pile.

Realistically if a dev gets a leetcode interview they don't want to do, most of them can just cancel and likely get an interview with someone else next week if they're actively applying to jobs.

Better outcomes, better industry productivity, sure. But ‘hiring fairness’?

The (open) question is, can we do better?

But, why did we get through? Maybe the process really is capable of separating wheat from the chaff. Maybe the process works 85% of the time, and the 1 time it didn’t work in recent memory is someone who has already left the company. Maybe only capable people self select into the process for some reason. Maybe we’ve been phenomenally lucky.

The point is, just because a filter allows the right people through doesn’t mean it’s necessarily any good.

I define “good” and “right people” to be that which produces efficiency, quality, innovation in the business. So a good filter to me is good wrt these outcomes.

The industry is starving for ‘good people’ and ‘good outcomes’ and we should work to optimize this imo.

Any other measure divorced from outcome to me seems... weird.

Triplebyte claims the industry average onsite pass rate is in the neighborhood of 30% (https://triplebyte.com/blog/12-000-engineers-evaluated). I suspect that the huge majority of those who fail onsites get jobs. Is that efficient?

What I’m saying is that the notion of ‘fairness’ should have little relevance to improving this side of things.

To that end, I'm 43 and last on the market a few months back, accepted an offer within a week of looking, had 3 pending final/onsites (including Amazon Seattle) and at least another half dozen in earlier stages that I shut down.

I do nothing to hide my age on my resume. Since turning 40 I've been on the market 3 times now, each time interviewing w/ 10-20 companies, and only once did I get the sense that agism was at play.

- Whenever I need to hop into a code share w/ a co-worker (I'm remote FWIW) the ability to quickly suss out an idea has greatly improved from having a decent aptitude with those types of exercises.

- Any non-trivial PR usually has at least a few portions that could be extricated to challenges like these. Being able to slice through issues like these in 15-30 minutes vs. say hours helps w/ my cadence. It lets me focus on the issues that are unique to the business.

The 30 minute pairing challenge we give during our interview (which I took myself) was something that was pulled and simplified from our source. I ended up having to implement something very similar just weeks after I started.

Of course being good are things like this isn't necessary to being an effective sr. developer, nor is it sufficient (even for an entry-level). But I do very much see it as a skill that is helpful and worth getting good at.

Part of the reason is because I hadn't spent as much effort on this earlier in my career; now with the concern of agism, every time I'm on the market I try to level up my skillset.

So, trust me when I say I don't object in the slightest to being asked to study and learn things. LeetCode-style problems look like one form of recreation to me.

And yet, I still think this comment is shortsighted because:

* I'd guess a lot of what's on LeetCode isn't exactly untrodden territory for any developer that got their start before 1995.

* Distinguishing oneself can work in the individual case, but it generalizes poorly. Imagine employers and would-be job-seekers alike internalize LeetCode knowledge as a standard distinguishing mark. Like college degrees, distinguishing points often over time become standard expectations. The likely outcome is that about as many devs in their 20s & 30s can brandish the same "distinction" that devs 40+ can and the incentives to prefer youth perform about the same.

Individual efforts to improve ones lot are a good place to start, but they rarely solve systemic problems.

Most developers are doing CRUD apps or at most apps where the complexity is in the business rules and process.

Absolutely. Unless you're working on a greenfield project or refactoring code for extreme performance, understanding the operational side of the business will get you more points towards the mythical 10x programmer status than algorithms.

I can't count the times I've seen scope creep and deadline slippage because the developer didn't really understand the need & use case and built something other than what was required.

But why is there this assumption that if someone studies Leetcode and algorithms then it means that they can't do anything else? Why is there this all or nothing mentality?

If someone studies Leetcode and algorithms, wouldn't one assume they know other things as well in the software engineering realm? I have plenty of friends in the Bay Area who are thriving at FAANG who studied algorithms and Leetcode intensely.

And I've seen developers come from doing Node green field APIs at Netflix to waist deep in a 15 year old Java application with Spring MVC and some underlying Struts yet to be removed and don't understand why debugger stopped going any deeper and they lost where they start 10 classes ago from shared modules.

Then they don't understand how refactoring a core message for alerting customer across the sight has tight coupling, wanted to something fancy and broke the key business features, try to argue it's better but a business unit just list functionality of it's product. Instead of researching, and coming up a plan with a team to refactor using TTD and Strangle Vine method from the legacy tightly coupled code, to a separate module with better testing and following SOLID principles.

Welcome to multiple Fortune 500 companies.

If they were told a web page was slow would they know enough architecturally to know how to find the bottleneck and no the solution for solving it? No the answer is not based on finding the o(n) complexity of reversing a binary tree.

Of course not, the main purpose of the leetcode is to ace the interview.

Doesn't mean they do not know any of those questions you mentioned above.

I, for example, did all you mentioned above and also practicing leetcode.

I am having very difficult time getting the offers (duh, when performing like this). Did you always get to receiving offers? I seem to always get the, we decided to go with another candidate... line after my onsite.

I've only had 2 company's fly me out so far and the only companies that I have gotten offers at don't do LeetCode. It's extremely frustrating or maybe I'm just not prepared well enough yet and need to be more consistent with my study and practice (and don't pay as much either) or maybe I'm just not smart enough. I feel stuck.

Will it ever end or am I stuck grinding for the rest of my career (life)? Will I ever be able just breathe and relax again? I'm not on the West coast, but interviewing on the West Coast. I'll rent out my condo or keep it around as a home away from home if I ever get an opportunity.

This happens to me too.

> Will it ever end or am I stuck grinding for the rest of my career (life)? Will I ever be able just breathe and relax again? I'm not on the West coast, but interviewing on the West Coast. I'll rent out my condo or keep it around as a home away from home if I ever get an opportunity.

Dude just try for companies on the west coast. Why is this the end all be all? Atlanta, Chicago, Dallas, Austin, Houston, Charlotte, Raleigh, Colorado Springs. . . So many cities with low CoL and six figure salaries for Developers, Security Engineers, Linux Admins, Infrastructure Engineers.

You even have Denver, DC, NYC, Charlotte, Arlington, Seattle, Tampa, Minneapolis, so many options. Stop limiting yourself San Francisco when there are so many great cities, with awesome opportunities.

That said, doubling my salary a Big-N for a few years and getting experience at a larger tech company is what I'm mostly chasing at the moment. I want the experience, I want to see what it's like for myself. I can just rent out the condo I have now easily, pack a bag of clothes and go.

I don't feel comfortable saying here, but the Blind app is an excellent resource for finding what total compensation (TC) you can expect for different companies and years of experience (YOE).

That said, there are plenty of resources that have been helpful to me:

1) http://highscalability.com/

2) http://shop.oreilly.com/product/0636920032175.do

3) https://github.com/donnemartin/system-design-primer

Hope this helps!

Mid 40s myself, stayed in one tech stack for too long but have been redeeming myself in the past few years with .net core, AWS, Docker and trying to get into React.

I find myself struggling most with the front end bits, but it's just a question of staying with it.

Have always loved tech, and highly passionate about it. Having a family with a kid on the ASD has really restricted available hours to tinker though, that's my main challenge.

Anyway I found what you and others here wrote quite motivational, so thanks again.

One thing that I'd like to mention that I didn't before is that the interview process can be taxing, draining, and it can be an emotional roller-coaster. Try to stay positive and keep at it. Good things will come!

And yes can confirm that when I had to go through the process, and was less prepared, it was certainly very draining. So spending time learning/staying on top of things in peace time will certainly help during "war". :)

Staying physically healthy, lifting weights etc is another thing that hasn't been raised so far, so would just like to put that in. Can always adjust perception through that, and also it is something we truly need to be doing now that we're getting older. It also helps for mental health.

The part that is missing from nearly all interviews are an opportunity for the company to sell itself to the interviewee. So as the interviewee, I'd like to say that if you make me jump thru some hoops because you feel like I should go through the same hazing process you went thru when interviewing, I am going to think that you are only focused on what I can do for you.

How about this, as an interviewer, say something like... "This design question is gonna suck because I don't know how to ask it better, but if you can just hang in there long enough to help me understand you can think about something non-trivial, that'd be fabulous. We both know you're smart, and I just need to imagine working with you in something complex."

My last three jobs I was hired as the “adult supervision” as either an individual contributor who was more equal than others or as an official dev lead. I was specifically asked by the director those types of questions and how would I rewrite a 20 year old PowerBuilder app that had been maintained by two “developers” who had been their for 20 and 13 years.

I went through the training process they would go through, setting up source control, setting up development, QA environments, automated testing, and CI/CD.

Then he was shocked when I said that I wouldn’t rewrite it from the ground up. I would upgrade to a newer version of PowerBuilder that supported COM, concert the whole app to a COM object, put a C#/WebAPI wrapper around it, write some automated integration reads and contract out some front end developers to put a web interface on it.

Then slowly move the PB logic to C# and keep the stored procedures after upgrading to the latest version of sql server.

Finally move the stored procs to code.

All this to say, that’s what’s wrong with some “senior developers”. They’ve spent their entire career at large companies where they haven’t had a chance to work up and down the entire stack. If you spent your entire career “coding” at a large company, you’re not that much more valuable to most companies than someone with 5 years of experience b

At that job we had to hire some overpriced/clueless “AWS consultants” since I didn’t know AWS at the time. Now I could manage that. I still wouldn’t try doing anything on the front end. There are people much better than me.