Great environment and pay with no real downsides - Perception Engineer bei Rapyuta Robotics: Mitarbeiterbewertung

- Extremely nice, helpful, and knowledgeable peers - In charge of your own work / work is interesting - Some good benefits with vacation days/days off

- Highly dependent on what team you are on and which project you are working for. Engineering jobs tend to need some overtime and have more pressure - Relatively low-ish pay, but not too bad - Lacks leadership and organization higher up - Slow career trajectory as an engineer

Despite being a small office, Rapyuta Robotics US is a decent, well-run company. Payroll is always on time, the reimbursement and PTO processes are proper and professional, and the company will sponsor and support your work visa. On all the fundamentals, it does well. Working hours are flexible. The team is made up of genuinely kind people who are careful, thorough, and efficient at what they do.

One important thing: almost NONE of the following is actually caused by Rapyuta Robotics US itself — and for that same reason, the US office has no way to fix any of it. These are not management issues. This is not a "no leadership" or "poor leadership" situation. The US organization is entirely dependent on the Tokyo headquarters. Its sole function is to market Rapyuta's products in the US, deploy them at customer sites, and provide maintenance and support. That work offers little technical substance and is largely repetitive. Worse, when something breaks — and it breaks often — you usually can't fix it, because neither the software nor the hardware was designed or built here. All of that lives in Tokyo. You don't get to take part in design; at best you patch things on top of an existing framework. In short, the US office only executes. It cannot decide its own fate. On the technical side — and I'll admit my experience is limited though — I'm not optimistic about Rapyuta Robotics, neither the older product nor the newer one. Since joining, I spent my entire time maintaining and iterating on one part of the older product's software. After two and a half years of patching, I never developed any real sense of ownership over it, because the architecture itself almost forbids any fundamental change to the code. It is just as buggy as it was on my first day, and it only gets harder to read and modify over time. The codebase has hundreds of tightly interdependent features that will strangle any attempt at refactoring. The new product will very likely drift toward the same fate — it was built by the same people who built the old one, and almost all of them have since left.