Pros: - Good work-life balance - Interesting problems to work on

Cons: Benefits provided can be better.

Pros: I have been working at Grab, and it is a great place to work, learn, and grow. You will feel proud of your work, as the Grab app is used by literally everyone. Also, most technologies used here are new, and there are almost no (too) legacy systems. So, it is a great opportunity to learn technical skills. A lot of focus is put on scalability, availability, and maintainability, which is great. A lot of automation tools are also in place as well.

Cons: Some teammates are not competent enough.

Pros: Grab offers reasonable compensation in SE Asia and has some employee-friendly policies. A few of the engineers are technically competent, helpful, and demonstrate a collaborative attitude.

Cons: The primary driver of Grab's growth was the abundance of VC funds, which facilitated promotions and marketing campaigns targeted at driver-partners and customers. Grab acquired Uber's SE Asia operations because of Softbank's support, and they were the principal investor in both companies. Uber's technology platform is superior, and its operations management methodology is better than Grab by many orders of magnitude. Browse the public GitHub repos of Uber and Grab to get a better idea. The work environment in Grab remains very politically charged. There are hordes of engineers who are incompetent but get promoted to G5 or G6 solely based on "good relations" with their reporting managers. During my stint at Grab, I encountered multiple instances in which a team of engineers would attempt to reinvent the wheel. One group built a documentation microsite using Hugo instead of using an existing system like Confluence (Wiki). There was yet another group that developed a mock-server, instead of using WireMock or MounteBank. Furthermore, the Engineering Lead was blissfully unaware of these open-source tools. Finally, this custom mock-server was buggy, painful to use, and did not have a single useful feature. The application codebase is bloated and is full of unsound, if not outrightly bad, engineering practices. The situation is so dire that Android Studio is unable to load the application codebase. The official recommendation on one of the documentation microsites is to use an alternate code editor (vi or vscode). Furthermore, you won't be able to build the codebase on your local machine, and the only way you can test your code is to use CI or to use remote infrastructure using Mainframer. The processes that are in place make engineering teams feel worthless and actively infantilize engineers and individual contributors. A manager has to approve almost each and every thing, even something as trivial as internally publishing a code-labs (guided tutorial) or a video presentation on a component that you have designed and developed.