Rakuten Reviews

English-nization is a lie. Business still works in only Japanese and even in engineering more than half the documents and meetings are in Japanese. New Japanese documents are still created every day despite official company policy that says work is to be done in English. Despite that many non-Japanese speakers came in expecting to be able to use English at work, which does not pan-out as expected. Some meetings end up taking double the time because somebody have to translate everything to the other language. Either that, or one side gets completely left-out when one language dominates. On the flip-side, good Japanese engineers who can't speak English either quit/don't get hired or hired as a part-time/contract staff to circumvent the policy, which defeats the purpose of the policy and seems unfair to the Japanese staff. Performance review is done purely top-down, with superiors giving performance evaluation to their members purely based on what the member claims they have done and what the manager sees (which is not much, especially if the team is big and a non-technical manager is reviewing technical members). There's no way to feedback regarding your own superior, causing no outlet to feedback on management practices that can be improved. 360 feedback was proposed but was repeatedly rejected and ignored. Recently some managers try to introduce nomination-based peer-review but not all managers are onboard with even this. Feedback regarding different aspects of the company are sometimes solicited but the response then disappears to thin-air, with the topic never to be heard of again. CEO likes to say that Rakuten is a "tech-company" but actually does not care about technology. Rakuten's own research department finds it very hard to do actual technical research with a longer time horizon because CEO insists on only doing project with short-term business impact (more profit or cost cutting). More focus on churning out services as fast as possible even if backed with fragile aging technology-hack, which causes problem in the long run. This attitude permeates down the command chain, with middle-managers refusing to learn and update tech as long as the current web of systems somehow barely works. "We don't know X so we don't want to consider doing X" is an actual excuse used to not do something. Teams are highly protective of their own systems, refusing collaboration from other teams ("don't touch my things" attitude), making team work very very difficult. Teams push responsibilities to each other and would rather sit on what they have instead of working together to solve a common problem. Technical design is just not done. Multiple copies of systems with very similar or even identical capabilities can be developed at the same time (partly due to the mentality above) and overall system architecture is not considered. Attempts to simplify/merge systems is met with resistance from teams refusing to let go of their own thing and work together with other teams. Renewal of old systems are done without thinking why the renewal was needed in the first place and just end up being a reimplementation of the old system on a different programming language or framework version, which defeats the purpose of the renewal efforts. Generally, not recommended for engineers who'd like to work on latest technology and challenge novel problems, unless you have the perseverance of breaking through all the inertia walls first and doing catch-up by building all the required infrastructure from scratch. There are a small group of people who are working on this, but there's still a mountain of things to do yet.