The sad truth of hiring is that you can't afford to interview everyone, and have to keep in mind that prospective employees are showing you a different version of themselves than they'll actually bring to work.

Especially in a small company where your hiring manager may also be busy with development and sales, and not have an HR department to run the process for them, you're much better off interviewing candidates you are 50% sure of being a good fit vs 5%. Personally I prefer interviewing candidates coming from FAANG-ish companies and often make exceptions for candidates that demonstrate exceptional skill/interest, but when you can only interview 1-10% of your applicants you have to prioritize those who are likely to succeed at your company (keeping in mind implicit bias and such).

> filtering based on random signals like this is not useful.

In aggregate it most likely is useful for those companies.

> And I’ve heard just as many horror stories about companies hiring from small companies that the engineers haven’t kept up with engineering, culture and practices and are coding like it’s 2004.

Big cos can afford to onboard their engineers for months, sometimes years. Startups usually can not

The problem is that many smaller companies have hired people from FAANG, and had them quite after a short tenure, so they're unwilling to try their luck again, as it's just not worth it. You may be different, but they've heard that story before, and had it not work out.

> I’m tired of the FAANG mentality personally.

As someone that never had a desire nor ever made an attempt to work at any of those companies, do you mind elaborating on the mentality of such places?

I'm just your boring below-average to average dev, so I know I'm not cut for those types of places, but it never truly bothered me anyway. Any reason that I can personally think as to why I would work for such a company would either be due to my own egotistical desires or for monetary reasons, but those were never strong enough to actually compel me.

I am just mainly curious about two things:

1. Is working at those places all it's cracked up to be?

2. Assuming one had to work hard to get into such companies, was the juice worth the squeeze?

I've often wondered if one's experiences for these companies is often something akin to the old advice of, "Don't meet your heroes." In other words, was the conflicting dyad of expectations vs. reality present?

Sure, but in this context, your FAANG experience is a negative signal for people who don't know you well yet. It's unfortunate for you, but a genuine factor you now need to account for.

Your path through will probably look like having the luck of breaking in at one of these kinds of companies, and then staying for several years to demonstrate earnest commitment/fit while building a new network of connections, and then leveraging those connections to get more opportunities if it becomes necessary to do so. If you have connection from your previous non-FAANG work, that's probably your best route.

It won't happen overnight and you'll always be at a disadvantage when you find yourself applying through resume portals. Good luck!

>"And most refused to look at anybody deviating from their ideal background in my experience."

This is often because the culture of job-hopping for better pay every 18 months has eroded the willingness to pay for training or adaptation. Why pay for someone to learn if they're just gonna leave soon; the pre-trained person is a better deal if you'll have to pay to retain anyway.

My understanding is even in the early 2000s it was pretty much just firmware versus desktop software with a small niche for Mac developers.

Edit: my point was not that specialized software applications didn’t exist. It was that people were expected to be able to jump from stack to stack when they change roles in a way that has disappeared from modern job applications.

I've had both I've had ones that only tell you what the next interview looks like. Unless you specifically prior it out of the recruiter's hands.

The only way to test actual work is to do actual work, should be obvious but here we are.