Yeesh I feel that way working at a FAANG (or MAGMA or whatever it’s called this week). I’m an expert at our internal systems and platforms, but that’s not a skill that’s transferable anywhere else.

This was probably the most surprising thing about working at a FAANG company (although in hindsight it shouldn't have been). What, you all don't use Jenkins, JIRA, Spring, insert-OSS-or-other-well-known-tool-here and instead have all this crazy internal stuff I've never heard of?

Question: Are the system you using open standards (e.g. RESTful APIs)? Do they have Data Models that follow some sort of sensible standard that allow for interop with other systems via sensible mechanism systems?

A lot of the hell that is enterprise software is how systems talk to each other. I'll give an example. Project is started to bring data from Vendor A Product into Product from Vendor B. Vendor A claims system is "open" but there is no documentation outside of some cryptic .NET examples. Even when a successful connection is made, the data and data model makes no sense and nearly impossible to map to what users see in UI.

Vendor A gets a call. Vendor A repeats "open" and brings an "SME" to explain data model. SME is really a Sales Engineer who concludes Vendor A has another product that will expose the data in usable way. Start evaluating this product, and it turns there is a lot overlap between features in Vendor A new product and Vendor B's product. Plus, you still need to use .NET and a proprietary connection to get data from A -> B. Plus,Vendor A's new product does data transformations in a black box..nobody knows what exactly.

Vendor A and B are pointing fingers and each trying to make a case for why their product needs to do X features. Nobody understands this .NET library, so a consulting company is used to build data pipeline from Vendor A -> B.

Granted, a lot of the above wouldn't be acceptable today and a lot of these types of systems are going away and being replaced by ones that are actually designed to be interoperable with other systems. This type of story is hopefully going away sooner than later.

I use a lot of proprietary systems in my current job at extra-big company, but at least they use stuff like SQL, RESTful APIs, etc. I can understand our Data and how it maps. Those are transferable skills.

I can only hope that FAANG isn't building systems where everything is proprietary and make no sense to anybody outside of the Eng team that built them.

I have never worked at FAANG but have had coworkers + have friends that have.

I'm under the impression that gRPC is popular, and in some places GraphQL.

I prefer AAA - Amazon, Alphabet and Apple. Netflix is irrelevant, while Facebook is too evil.

It's kind of funny: I dealt with more garbage proprietary stuff (NetSuite for example) at my previous job at a tech company, but use almost all open-source stuff at my current job at a manufacturing company.

Manufacturing is in an interesting space right now. There's a lot of hype around Industrial IoT (IIoT) and IoT 4.0. A lot of companies are using that hype to ask for budget to migrate their systems to open source and systems which are more open.

That being said, companies like GE, Siemens, and PTC are trying desperately to capture that space as well with their Saas/PaaS.. I won't say they are crap, but it's just more lock-in under the guide of "open." One of them has already gone the way of Watson.

YMML will vary in manufacturing. If you can jump to one of these companies that is on their journey from legacy systems to more open ones, you can definitely land in a good spot. Just ask the right questions when you interview there.

I've worked with such niche enterprise software before. It only pigeon-holes you if you let it. One I worked with was, at the time, a VB6 based application for trading bank debt built on a combination of SQL Server/Access (SQL Server was the source of truth, but entire data sets would be pulled into a local Access database for reporting...). It had no integration points to speak of, not even a reliable report runner (had to run reports manually through a GUI). Over the years, they were doing a piecemeal transition to .Net, but I never saw a .Net only implementation while I worked with it (I left the company in 2012).

A lot of my Python expertise on Windows comes from working with that system. I used Python because 1) I already knew it, 2) I could easily run parts on either Windows or Linux and 3) all of the internal APIs I needed access to had Python wrappers available (or I could easily write one in Boost Python at the time). I forget exactly which Python libraries I used, but there was some Win32 COM going on, some ctypes and other Python based GUI automation, as well as a lot of process management (reports tended to hang quite a bit needing killing/restarting) and ETL work.

I spent roughly 7 of my 9 years at that company working in part on maintaining the integrations of that 3rd party system with our own internal systems. Yes, a significant chunk of my time at the company, but what software it was is just a footnote on my CV. Instead all of the interesting integration work I did and the efficiencies gained are elaborated upon (e.g. with 8 hours of development effort, I was able to automate away a previously 8-hour manual task that had to be done monthly).

You are describing my positions today. FML

Thanks, it's so reassuring to hear this.