Mfcttrf

I wrote this review of a company that I'm going to post on glassdoor and similar websites, and I'd like to know whether this is wrong from a professional standpoint. I'd like to be fair with what I wrote. I'm angry at the company as it's a harsh review (and this is obvious from the review), but I still want it to be a fair and professional review of what I saw there.

I worked at CompanyName for a couple of years. I'm a C++ developer, and this review is to help those seeking to know whether CompanyName is the right environment for them. This is the first time I write a review.

CompanyName, in their branch in Germany, has two primary divisions. First works with C++ primarily, which is about simulations of different space related hardware, and the second is Java related. I'm not in authority to speak about Java, so I'll focus on C++. The reason why I joined CompanyName is that they list in their ads that they work on "mission critical" stuff. This sounded very intriguing to me since I'm obsessed about quality, so I joined.

You can split the employees who work with C++ in CompanyName into seniors and juniors (I'll talk about management later). There are around 35-40 persons in that branch who are separated from the main company in almost everything. The number of seniors is like 3-5.

Seniors basically work with C++ of 15 years ago. Boost is very intimidating to them at all levels. Their knowledge of C++ is embarrassing, and any modern C++ is seemingly very intimidating to them, to the point that they push out anyone who advocates for it, including myself. Seniors, up to this day in 2019, still use "new" to allocate memory manually, and "delete" to delete it manually (and yes, they use exceptions in their code). Zero use of smart pointers exists, because they don't know how to do it. RAII? Forget it. They still allocate arrays manually with "new[]" and "delete[]". They don't know how/want to use std::vector or std::array to avoid memory leaks and have range protection in debug mode. This leads constantly to horrible bugs (which sometimes show up years later when reusing code... we all know what undefined behavior means), because they reuse code a lot, but they use Valgrind to solve these problems (just like the 2000s), which doesn't always work. If you're an advanced C++ developer, you'd know that Valgrind is almost never used nowadays, especially when you have good practises that are agreed upon in the whole C++ community in the world, that we constantly see everywhere in every forum, including cppcon, etc.

Besides all this, how about the senior who doesn't know what a functor is? Or the senior who doesn't know the difference between auto and auto_ptr? Or the senior who thinks it's OK to use auto_ptr in 2019? Or the senior who doesn't know that templates should all be defined in all in header files and why?

Don't even think about the real cool modern stuff, like type_traits, fold-expressions, SFINAE, etc. That's absolutely never gonna happen.

Ignorance is not usually the problem. We're all learners after all in this field. The problem is the huge ego and disinterest in learning anything new. It's frustrating.

So seniors there code with C++ to make the software compile and get the tests to pass through lego-like copy-pasting code. There's almost no understanding of the risks associated with doing what they're doing, and there's no will to change or learn at all.

Once I saw a junior coming to a senior and telling them in some context "I'm using new to allocate this array but Valgrind is crashing at that point... what do I do?", and no facepalming in the world could've cut it in my head. When that junior left, I asked the senior (with a pokerface) "Why aren't we using vectors for memory safety?" and he was convinced that it's OK to allocate and delete arrays manually in order not to write a function to define how to serialize a vector, and creating excuses for it. This was two years ago, and still remains to be the case.

In 2019, using a vector or a smart pointer to do safe memory work was called "textbook approach" by the same senior... another facepalm I lived there. Apparently coding safe C++ is extraordinary or something. I don't really know what to say.

Of course, this means that their code is infested with all kinds of memory corruption, both stack and heap. The last disaster I lived through was some code that crashes when quitting, which happened because of tons of these practices, including (but not limited to) allocating arrays manually and writing to wrong indices in these arrays. Of course, every experienced C++ developer knows that STL containers would protect from such problems since they fire asserts at invalid element access in debug mode. But CompanyName's seniors prefer to have these bugs over learning how to do correct C++.

To be fair, there is one senior who knows what he's doing there. He's the only one I'm really happy to have worked with (both on the professional and ethical level), and I learned a lot from him. But every other senior... If you're an experienced C++ developer, you can imagine the frustration.

Juniors: They're usually like a sponge. They want to learn and thirsty for it, and they believe that those seniors know what they're doing. Some of them realize what a disaster working in CompanyName is for C++ developers, and they leave in relatively short time. Others grow to seniors by conforming to these standards at CompanyName, and life continues.

To add to the stories: Once there was a junior who told me, that another senior (who worked there for like 20 years, and who I didn't have real work with) told him that "allocating memory is dangerous, because cleaning it up can be hard", and prevented him from doing it... and that was in 2018. How hard is it to use your own custom RAII wrapper? Who knows...

But how does such a company survive? They survive because they're contractors. They get the SRS (Software Requirement Specifications), and they follow it. The "quality" specifications come from the customer, which can be described as nothing but laughable. "Quality" there means that you run Valgrind and it doesn't give "lots" of memory leaks. But in my eyes, nothing matters if your code is infested with undefined behavior due to negligence and deliberate ignorance. Maybe I'm paranoid and crazy?

But how can the customer accept this? Because the customer is... a governmental institution. It's the only reason a company like CompanyName survives. As we all know, the public sector doesn't care about modern standards of quality that much. They have "quality standards" that are 20-year old.

Management: They ask you to innovate and be creative, but if you ever disobey seniors, they'll blame you for not being obedient. They also have standards imprinted in their brains that if ever broken, they frown at you. For example, if you write your own implementation of something for a good reason, they blame you in a condescending tone without a discussion, obviously because "writing your own implementation is bad"... with absolutely no context... it's just bad (the implementation I wrote was like 100 lines of code to avoid using a huge GPL library that needs 3 hours to compile, so you judge, and it wasn't even discussed, just blame was thrown). That's the mentality there. They completely fail at understanding how being obedient and being innovative are mutually exclusive. That's how I exited the company. It was hopeless to convince management that anything those seniors are doing is wrong, and it was impossible to have a constructive discussion on any decision that I made.

Why? Because the management loves those seniors, because those seniors understand the game. They know how to write proposals and get more contracts (nothing wrong with that). But... the idea is, If you want to join CompanyName to learn how to be a good coder, this should be the least of your hopes.

Pay: Expect 70%-80% of the standard market salaries. This is because this company deals with the government, and as we know, the public sector doesn't pay much.

Conclusion: CompanyName knows how to make money by utilizing the market very well. But it's not suited for enthusiasts.

Is CompanyName for you?

• If you're looking for a stable job where you absolutely don't care about quality or upgrading your knowledge (except in their field, which is only used in a handful of companies) and are looking for mediocre, stable pay by following orders; then CompanyName is definitely for you. I understand that some people want that because work is just work; with no enthusiasm; nothing wrong with that; people are different.




• Also, if you're a new graduate who wants to add 1-2 years of experience to their CV before going to real private companies that have real quality standards where you can make real skills, also CompanyName can be a good start, since it's very easy to be hired there and no one outside cares about the quality standards in other companies. CompanyName loves juniors, because they get very low pay.




• But, if you're a senior who pays attention to detail and wants to create beautiful code that runs for years and focus on improving yourself, then CompanyName is absolutely not for you. Every senior there will fight everything you do until they get you out, and management will applaud.

Advice to management: Maybe let your seniors get off their high horses, and read some C++ book that's not 15 years old.

EDIT about possible duplicate: This is not about bad-mouthing in interviews, which is obviously not in my interest. This info never goes into interviews. This is going to anonymous glassdoor or similar services. Also I would love to make this as "not" bad-mouthing. It's bad-mouthing in a way, but I would love it to be as objective as possible.