When interviewing with a Japanese company, you’ll naturally want to know: “Is this a good place to work?” And while Glassdoor is the standard in English-speaking countries for employees leaving online reviews, the site is only rarely used in Japan, and then primarily by non-Japanese workers. Many countries have a culture that endorses directly reviewing employers in an open, public environment—Japan does not. However, there are still sites where you can find important information on your potential employer. What to watch out for In particular, you want to avoid signing on with a company that engages in exploitative practices—or as they’re known in Japan, a “black company” (ブラック企業, burakku kigyou). The Ministry of Health, Labor, and Welfare has a FAQ describing what defines these companies: Imposing extremely long working hours with high quotas. Recognition of workers’ rights is low throughout the company; unpaid overtime and/or workplace bullying (パワハラ, pawahara) are common. The company assigns shifts to workers without consent. The company discriminates among workers in the above circumstances. In a 2023 survey, those who had worked for such toxic companies listed high turnover rates as the most common sign that something was wrong, followed by long working hours and unpaid overtime. As you examine online review sites and other sources, look for clues such as: Turnover rate: how long do employees typically stay? Internal promotion: can you see employees rising in the ranks? Upper management: are there any non-Japanese employees in management positions? Recent company announcements: do they often make sudden pivots in their business policies? If you discover, for example, that the company can’t retain employees, shows no history of internal promotions, and has just issued a return-to-office order out of the blue, it’s safe to assume you don’t want to work there. OpenWork OpenWork, also known as Vorkers, hosts over 19 million company reviews. The reviews are represented in a radar chart for easy visual reference, and are also broken down into different categories, such as work-life balance, the ease of working for women, and reasons for considering quitting. In addition, applicants can post questions for employees to answer. If you don’t speak Japanese, the site is still readable with Google Translate. You’ll need to make a free account to see all of the information, but much of it is accessible even without an account. Other Japanese sites JobTalk and Engage Hyouban are other Japanese-language review sites. JobTalk contains 4.4 million reviews of around 230,000 different companies, and Engage Hyouban boasts 30 million reviews for 220,000 companies. Neither of these sites offer as much information on tech companies in Japan as OpenWork does. If you’re applying to a large company such as Rakuten, you may find some additional reviews there, but many of TokyoDev’s clients are smaller companies that aren’t listed at all. Google Maps Reviews An unusual but occasionally helpful place to find company reviews is on Google Maps. If you search for a business’s main corporate office location—usually in Tokyo—you will sometimes find reviews written by current or former employees. Whether these reviews are high-quality or trustworthy is another matter. Rakuten, for example, has reviews with a range of opinions. Cybozu, by contrast, mostly has reviews from those who would like to work for the company but currently don’t. Still, the reviews of its corporate office are consistently positive, so you can at least get an impression of the physical environment. LinkedIn “If you’re worried that a company might be a poor place to work, try contacting current or past employees via LinkedIn,” suggested Paul McMahon, founder of TokyoDev. “This probably works best if you’re late in the hiring process.” You can send a connect request saying, ‘I’ve received an offer from company X, and want to confirm what it’s really like to work there as an engineer. Mind if I ask you a couple of questions?’ Whether or not they respond, you can still glean good information from the profiles of past and current employees. Check to see if developers tend to leave the company quickly, for example, or how long the average employee goes before being promoted. You should keep in mind though that LinkedIn is not popular in Japan, for several good reasons. If you are applying to a primarily Japanese company, many of your future coworkers won’t be active there, which means you still may not be getting a complete picture. TokyoDev In 2020, TokyoDev began interviewing developers in order to provide a more complete, boots-on-the-ground picture of daily life at specific companies. Our Developer Stories feature interviews with developers at top Japanese tech companies, who share details about both their specific jobs and the general work environment. The goal is to give applicants a good sense of how a company operates on a day-to-day basis, from the perspective of those on the inside. So far, TokyoDev has interviewed developers from Mercari, PayPay, Givery, HENNGE, KOMOJU, and more. In addition, TokyoDev’s job board is a selective one, listing only companies that we feel good about sending applicants to. In the rare event that employees later reach out with poor reviews of a business, if those reports can be confirmed, then TokyoDev will end its relationship with that company. Conclusion In short, the answer to the question “Is there a Japanese equivalent to Glassdoor?” is, “Not really.” However, by combining some of the alternatives—OpenWork, LinkedIn, TokyoDev, and perhaps even Google Maps—you can gather enough information to decide whether you want to work with a particular Japanese company. You could also ask fellow developers in our Discord. Curious about working in Japan in general? See our articles on the subject, as well as moving to Japan, living in Japan, starting a business in Japan, and more.

Our battle with Apple over their gangster attempt to extort 30% of our HEY revenues was one of the defining moments of my career. It was the kind of test that calls you to account for what you believe and asks what you're willing to risk to see it through. Well, we risked everything, but also secured a four-year truce, and now near-total victory is at hand: HEY is finally for sale on the iPhone in the US! Credit for this amazing turn of events goes to Epic Games founders Tim Sweeney and Mark Rein, who did what no small developer like us could ever dream of doing: they spent over $100 million to sue Apple in court. And while the first round yielded very little progress, Apple's (possibly criminal) contempt of court is what ultimately delivered the resolution. Thanks to their fight for Fortnite, app developers everywhere are now allowed to link out of apps to their own web-based payment system in the US store (but, sadly, nowhere else yet). This is all we ever wanted from Apple: to have a way to distribute our iPhone apps and keep the customer relationship by billing directly. The 30% toll gets all the attention, and it is ludicrously egregious, but to us, it's just as much about retaining that direct customer relationship, so we can help folks with refunds, so they don't tie their billing for a multi-platform email system to a single manufacturer. Apple always claims to put the needs of the users first, and that whatever hardship developers have to carry is justified by their customer-focused obsession. But in this case, it's clear that the obsession was with collecting the easiest billions Apple has ever made, by taking an obscene cut of all software and subscription sales on the platform. This obsession with squeezing every last dollar from developers has produced countless customer-hostile experiences on the iPhone. Like how you couldn't buy a book in the Kindle app before this (now you can!). Or sign up for a Netflix subscription (now you can!). Before, users would hunt in vain for an explanation inside these apps, and thanks to Apple's gag orders, developers were not even allowed to explain the confusing situation. It's been the same deal with HEY. While we successfully fought off Apple's attempt to extort us into using their in-app payment system (IAP), we've been stuck with an awkward user experience ever since. One that prevented new customers from signing up for a real email address in the application, and instead sent them down this bizarre burner-account setup. All so the app would "do something", in order to please an argument that App Store chief Phil Schiller made up on the fly in an interview. That's what we can now get rid of. No more weird burner accounts. Now you can sign up directly for a real email address in HEY, and if you like what we have to offer (and I think you will!), you'll be able to pay the $99/year for a subscription via a web-based flow that it's now kosher to link to from the app itself. What a journey, and what a needless torching of the developer relationship from Apple's side. We've always been happy to pay Apple for hosting our application on the App Store, as all developers have always needed to do via the $99/year developer fee. But being forced to hand over 30% of the business, as well as the direct customer relationship, was always an unacceptable overreach. Now that's been arrested by Judge Yvonne Gonzalez Rogers from the United States District Court of Northern California, who has delivered app developers the only real relief that we've seen in this whole sordid monopoly affair that's been boiling since 2020. It's a beautiful thing. It also offers Apple an opportunity to bury the hatchet with developers. They can choose to accept the court's decision in full and worldwide. Allow developers everywhere the right to link to their own billing flow, so they can retain their own customer relationship, and so business models that can't carry a 30% toll can flourish. Besides, Apple's own offering will likely still have plenty of pull. I'm sure many small developers would continue to consider IAP to avoid having to worry about international taxes or even direct customer service. Nobody is taking that away from Apple or those developers. All Judge Rogers is demanding is that Apple compete fairly with alternative arrangements. In case Apple doesn't accept the court's decision — and there's sadly some evidence to that — I hope the European antitrust regulators watch the simple yet powerful mechanism that Judge Rogers has imposed on Apple. While I'd love side loading as much as the next sovereign techie who wants to own the hardware I buy, I think we can get the lion's share of independence by simply being allowed to link out of the apps, just like has been so ordered by this District Court. I do hope, though, that Apple does accept the court's decision. Both because it would be a stain on their reputation to get convicted of criminal contempt of court, but also because I really want Apple to return to being a shining city on the hill. To show that you can win in the market merely by making better products. Something Apple never used to be afraid of doing. That they don't need these gangster extortion techniques to make the numbers that Cook has promised Wall Street. Despite moving on to Linux and Android, I have a real soft spot for Apple's taste, aesthetics, and engineering prowess. They've lost their way and moral compass over the last half decade or so, but that's only one leadership pivot away from being found again. That won't win back all the trust and good faith that was squandered right away, but they'll at least be on the long road to recovery. Who knows, maybe developers would even be inclined to assist Apple next time they need help launching a new device in need of third-party software to succeed.

Explore Remix's new React Server Components (RSC) preview in react-router! Learn usage, different approaches, and trade-offs.

Have you thought about doing the opposite of whatever you're doing or considering? It's a really helpful way to test your assumptions and your values. What does the opposite look like, how would it work? It's so easy to get stuck in a groove of what works, what you believe to be right. But helpful assumptions have a half-life, just like facts. And it's ever so easy to miss the shift when circumstances change, if you're not regularly stress-testing your core beliefs. That doesn't mean you're just a flag in the wind, blowing whichever way. But it does mean having enough intellectual humility and creative flexibility to consider that what you believe to be true about your business, about your team, about your technology might not be so. We did this a while back with full-time managers. We'd been working for nearly two decades without any, but exactly because it'd been so long, we were drawn to try the opposite, just to see what we might have missed. So we did. Hired a few full-time managers to help us test that assumption for a few years. In the end, we decided that our managers-of-one culture worked better, but it wasn't a given at the outset. To try the opposite, you really have to believe that you might have been wrong. Because you're wrong about something. I guarantee it. We all are.

I’ve spent so much time, had so many headaches, and encountered so much complexity from what, in my estimation, boils down to this: trying to get something to work on multiple computers. It might be time to just go back to having one computer — a personal laptop — do everything. No more commit, push, and let the cloud build and deploy. No more making it possible to do a task on my phone and tablet too. No more striving to make it possible to do anything from anywhere. Instead, I should accept the constraint of doing specific kinds of tasks when I’m at my laptop. No laptop? Don’t do it. Save it for later. Is it really that important? I think I’d save myself a lot of time and headache with that constraint. No more continuous over-investment of my time in making it possible to do some particular task across multiple computers. It’s a subtle, but fundamental, shift in thinking about my approach to computing tasks. Today, my default posture is to defer control of tasks to cloud computing platforms. Let them do the work, and I can access and monitor that work from any device. Like, for example, publishing a version of my website: git commit, push, and let the cloud build and deploy it. But beware, there be possible dragons! The build fails. It’s not clear why, but it “works on my machine”. Something is different between my computer and the computer in the cloud. Now I’m troubleshooting an issue unrelated to my website itself. I’m troubleshooting an issue with the build and deployment of my website across multiple computers. It’s easy to say: build works on my machine, deploy it! It’s deceivingly time-consuming to take that one more step and say: let another computer build it and deploy it. So rather than taking the default posture of “cloud-first”, i.e. push to the cloud and let it handle everything, I’d rather take a “local-first” approach where I choose one primary device to do tasks on, and ensure I can do them from there. Everything else beyond that, i.e. getting it to work on multiple computers, is a “progressive enhancement” in my workflow. I can invest the time, if I want to, but I don’t have to. This stands in contrast to where I am today which is if a build fails in the cloud, I have to invest the time because that’s how I’ve setup my workflow. I can only deploy via the cloud. So I have to figure out how to get the cloud’s computer to build my site, even when my laptop is doing it just fine. It’s hard to make things work identically across multiple computers. I get it, that’s a program not software. And that’s the work. But sometimes a program is just fine. Wisdom is knowing the difference. Email · Mastodon · Bluesky