The remote work conundrum

Everyone loves working from home. I certainly do. For context, I've been working remotely for over 15 years—way before it was trendy. The promise is simple: you get things done, produce measurable results, and people don't ask questions. That's how it's supposed to work in theory, at least. But lately, it's become more complicated.

This year we hired six new developers. We preferred local, in-office candidates, but we knew going in that most would likely be remote. Years of remote work have taught me that there are three stars that need to align, but realistically only two ever do: salary, location, and skills. It's like the old saying goes—pick any two.

Of the six hires, only one was local. The rest claimed to be remote across Canada. Or so they said. What we discovered through this hiring process was that five of the six people were running a work offloading scam.

Our hiring process requires standard information: Social Insurance Numbers, work permits, NDAs covering the projects they'd be working on—all the usual requirements. Nothing extraordinary, just paired with a couple rounds of interviews.

We split the hiring into two tranches of three people each to make onboarding easier. The first round seemed to go pretty smoothly. We got everyone set up on the project, helped them configure their local environments, and off to the races we went.

Since most of our team is remote, we hold a daily standup at 9am EST. The existing team and I are always on camera and ready. The new hires? Not so much. Only one ever joined by video. It was odd and a bit annoying, but I'm generally not one to complain about small things—people have their preferences and comfort levels.

By the end of the first week, actual work products started rolling in. Semantically, the code was fine, but it lacked awareness of the broader application context. It was fragmented and myopic—creating entirely new single-use methods instead of leveraging existing ones. And one developer was clearly using AI to generate commit messages.

That's when I noticed something. Let's say this person's name was Doug Jones. In his example data, he used a completely different name, like John Simpson. Strange. Later, while running sync tests on our development databases, I spotted that email: john.simpson@gmail.com. It struck me as odd that Doug would use that as a test email, especially since he was working on a registration flow where receiving emails would be critical.

My curiosity piqued, I dug into our mail logs and his commit logs. Neither were originating from Canada. They were coming from an Asian country.

I checked the logs for the other two new hires. One showed the exact same pattern—all logins and commits from an Asian country. The other geolocated to our city for everything. That was our local hire.

We discussed internally how to handle it. I scheduled separate video meetings with each of the remote hires, letting them know ahead of time that cameras would be required. In each meeting, I shared my concerns and asked one simple question: "Can you show me your laptop plug?"

The US and Canada use the same plug—different from those used in the EU and Asia. One person refused to show his plug; I think he knew where I was going. The other complied without realizing the significance. He maintained he was in Canada until I explained the discrepancy, then he admitted the truth.

I'm not sure what this scam is officially called, but here's what happened: A person in Canada had hired these overseas developers and submitted their own information to us as an intermediary. All the interviews were conducted with the Canadian intermediary—the person we thought we were hiring—but the work was being done by someone else entirely, in a different country. Presumably, they were hired at a fraction of our salary, allowing the intermediary to pocket the difference.

These are the kinds of schemes that are ruining remote work for everyone. Now I have to defend remote hires more vigorously than I ever did before.