[was_boring]

I don't want to be argumentative at all. I find what passes at one company doesn't at another and it's generally an interpretation of style that can be conformed to. For example, I am of the leaning that one line should do one thing only, and should be explicit -- which is different then many modern practices. Another example is array manipulation which, depending on the operation modifies in place and I reassign for clarity.

Does that make me a bad engineer? No. It makes me experienced. If any of those things aren't wanted at a future employer I can change to match the style.

To reject based upon that when the style isn't defined by tooling is weeding out great people who may not confirm but have the ability to.

[austhrow743]

As long as they weed out a high percentage of not very good people, companies accept weeding out some great people as a cost worth paying.

[was_boring]

Very true. I have been working at startups for a while as a hiring manager and one of the skill sets I've had to develop is finding good people who have been passed on by FAANG or who come from a non traditional background and never would make it past there filters. Simply because we can't afford the salaries, but still pay six figures to non bay area employees. It's been interesting watching the "I should work for a startup" to "I should work for FAANG" over the past decade.

[mooreds]

> It's been interesting watching the "I should work for a startup" to "I should work for FAANG" over the past decade.

I would be interested in your thoughts on this. Is it because of salary, opportunity or security?

I am outside the Bay area.

[was_boring]

I think it's do to two reasons: 1) salary at FAANG can be 2-3x what a startup can offer, granted that's in the Bay Area; and 2) there's been more then a few examples of equity not being structured in a way that is beneficial to early employees. Sam Altman even has a blog post that says startup equity needs a revamp.

[CaptainZapp]

For example, I am of the leaning that one line should do one thing only, and should be explicit

I agree. And this is actually the very reason why I can dig into a 5 year old, reasonably complex bash script of mine and successfully maintain it.