Over a month ago, I documented a Web3 remote recruitment experience that still makes me shudder in retrospect.

That time, the first half of the entire recruitment process looked perfectly normal:

• Someone reached out to me proactively on Telegram;
• The role matched my technical background;
• The first interview was conducted via Zoom;
• There was a real voice conversation;
• The other party could discuss the tech stack, the role, and the salary;
• After the interview, a second conversation was scheduled.

The problem occurred during the second interview.

The other party suddenly switched from Zoom to a platform called fyMeet, which I had never used before. When the web version failed to work properly, they sent me fyMeet.zip via Telegram.

I ran the fyMeet.exe inside it at the time.

The next day, multiple abnormal processes appeared on my computer, CPU usage exceeded 90%, and I ultimately chose to reinstall the operating system.

I documented the entire process in detail in my previous article:

《A Real Web3 Recruitment Trojan Experience: From a Zoom Interview to fyMeet.exe, Ultimately Discovering Abnormal Processes Planted on My Computer》

Unexpectedly, just over a month later, I encountered another very similar Web3 remote recruitment process.

The difference is:

This time, I did not proceed to the step of installing unfamiliar software.

And what happened afterwards made me increasingly glad that I stopped right then.

---

1. Another Web3 Recruitment Starting from Telegram

On the evening of July 21, 2026, I received a recruitment message on Telegram.

The sender claimed to be from a VC firm, hiring developers for a portfolio project, and asked if I was considering job opportunities in the Web3 / Crypto space.

They also left a domain name:

merklio.org

The next afternoon, I replied:

What area are you hiring for? I mainly specialize in backend, primarily using PHP and Go.

The other party replied quickly:

Backend is one of the key areas we are currently hiring for. Go being one of your primary languages is great—most of our backend roles use Go.

Some projects do use PHP, but the demand for Go is higher.

If it’s convenient, you can send over your resume, and I’ll check the match.

From this point, there was nothing obviously abnormal.

So, I sent over my backend engineer resume.

---

2. The Other Party’s Analysis of My Resume Was Even Quite Accurate

About 20 minutes later, the other party replied.

He said:

17 years of experience, PHP + Go, architect background, worked on e-commerce, live streaming, and command and dispatch systems.

This information indeed basically matched my resume.

Then, the other party asked a few very normal recruitment questions:

Which time zone are you currently in?

Are you looking for full-time or project-based collaboration?

What is your approximate salary expectation?

Have you been involved in development related to blockchain nodes, smart contracts, or wallets?

There was nothing wrong with these questions themselves.

So, I introduced my situation.

I am currently in China Standard Time UTC+8, can work remotely, and can also arrange for some time zone overlap based on the needs of European or North American teams.

Regarding working arrangements, both full-time and project-based are fine, but at this stage, I lean more towards:

• Backend development;
• System architecture;
• Core module development;
• Individual contributor roles.

Regarding salary, my expectation for a full-time remote position is:

USD 4,000–6,000/month.

As for Web3, I also explained honestly:

I do not have formal production project experience directly responsible for the underlying development of blockchain nodes, smart contracts, or wallets.

My strengths remain:

• Backend systems;
• APIs;
• Databases;
• Caching;
• Task scheduling;
• System stability;
• Third-party service integration.

If it involves exchange APIs, wallet or node service integration, on-chain data processing, backend systems, and related infrastructure, I can get up to speed with the business fairly quickly.

Smart contracts themselves are not my main focus at the moment.

This part of the communication was, by all accounts, very normal.

---

3. The Role Provided by the Other Party Also Had a Certain Degree of Match

Then, the other party further introduced the work responsibilities:

Responsible for the architecture design and development of off-chain services

Integrating with blockchain nodes, processing on-chain data

Collaborating with product and frontend teams to deliver features

Fully remote

From the job description, it didn’t require me to be directly responsible for smart contracts, but leaned more towards:

Off-chain backend services + blockchain node integration + on-chain data processing.

This actually had a certain degree of match with my technical background.

Therefore, when the other party suggested an online interview at 17:30 that day, I didn’t feel there was any obvious problem.

The only issue was:

The timing was quite sudden.

It was already 16:38.

There was less than an hour until the interview.

So I asked:

Is today at 17:30 an initial chat or a technical interview?

If it’s an initial chat, I can attend on time; if it involves a more in-depth technical discussion, since the timing is quite last minute, I’d like to move it to tomorrow at 17:30 to ensure we have a more thorough conversation.

The other party replied:

The first interview won’t involve technical details; it’s mainly to get to know each other and discuss your experience and our project.

In that case, having an initial chat that day was fine.

So I agreed.

---

4. What Really Alerted Me Was the Meeting Link

At 17:18, I noticed the other party hadn’t sent the meeting link yet, so I proactively asked:

I’m ready, please send the meeting link for today at 17:30, thank you.

At 17:23, the other party finally sent the meeting invitation.

The meeting name was:

王强 & Merklio VC meeting

The meeting time was listed as:

July 22, 2026, 17:25

But the meeting platform was not one I was familiar with:

• Zoom;
• Google Meet;
• Microsoft Teams;
• Tencent Meeting.

Instead, it was:

Relay.

I then entered the meeting page.

The other party indicated there was no need to turn on video.

At this point, I still didn’t immediately assume there was a problem.

After all, remote teams using collaboration software they are accustomed to doesn’t inherently mean anything.

The real problem occurred next.

---

5. The Browser Could Not Connect to Relay’s Media Server

After entering the meeting page, I found that the browser could not properly connect to Relay’s media server.

The other party was still asking:

Can you hear us?

But on my end, I couldn’t establish a proper voice connection.

At this moment, I suddenly thought of the experience from over a month ago.

Back then, it was also:

The web meeting failed to work properly.

And then it step-by-step developed into:

Unfamiliar meeting platform
↓
Web version unusable
↓
Suggested to download client
↓
Client download failed
↓
ZIP sent privately via Telegram
↓
Ran EXE
↓
System showed abnormal processes

Precisely because I had already experienced this once, this time I didn’t think:

“Maybe it’ll be fine if I just install the client?”

Instead, I stopped immediately.

---

6. This Time I Did Not Install Any Unfamiliar Client

At 17:38, I sent a message to the other party:

My browser cannot connect to Relay’s media server. For device security reasons, I am not comfortable downloading and installing a new meeting client.

Could we switch to Zoom, Google Meet, Teams, Tencent Meeting, or just communicate via Telegram voice?

Please also send the meeting invitation via an email from the merklio.org company domain, thank you for understanding.

This message actually contained two layers of verification.

First layer:

Do not install unfamiliar meeting clients.

Second layer:

Require the meeting invitation to be sent via a company domain email.

I did not refuse the interview.

On the contrary, I provided several alternative solutions at once:

Zoom, Google Meet, Teams, Tencent Meeting, or even Telegram voice were all fine.

That is to say:

If the goal was truly to complete the interview, continuing the conversation would have been very easy.

---

7. The Other Party Agreed to Switch to Google Meet

The other party replied quickly:

ok

Then stated:

I will send you the gmeet invitation in 10 minutes.

I replied:

Okay.

Then added:

Thank you, I’ll wait for your Google Meet invitation.

At this point, I actually thought the issue was resolved.

Since Relay wasn’t working properly, switching to Google Meet would allow us to continue and finish the interview.

However:

10 minutes passed.

No invitation.

20 minutes passed.

Still no invitation.

---

8. I Proactively Followed Up Two More Times

At 18:01, I sent another message:

Has the Google Meet invitation been sent yet? I haven’t received it on my end yet, and I’m worried I might have missed the message or email.

Still no reply.

At 18:20, I sent one final message:

I’m still available for the interview tonight. If it’s inconvenient to coordinate on short notice, we can also reschedule for a time that works for both of us; just let me know once it’s confirmed.

I had actually made the conditions very flexible.

It could be:

• Continuing that night;
• Switching to Google Meet;
• Switching to another mainstream meeting tool;
• A direct Telegram voice call;
• Or rescheduling.

But the result was:

The other party did not read any of the subsequent messages.

As of when I compiled this experience, I still had not received any further interview arrangements.

---

9. I Cannot Prove This Was a Scam, but There Was No Need to Keep Taking Risks

I feel a specific point needs to be clarified here.

I do not intend to assert, based solely on this one experience, that:

Merklio is a scam website.

Similarly, just because a Relay meeting failed to establish properly, it doesn’t mean there is a problem with Relay itself.

Even many of the other party’s behaviors beforehand looked very much like normal recruitment:

• They could read my resume;
• They could accurately summarize my work experience;
• They asked about the time zone;
• They asked about the working arrangement;
• They asked about salary;
• They asked about Web3 technical experience;
• The role provided had a certain degree of match with my technical background;
• They were willing to schedule an online interview.

The problem did not lie in any single isolated detail.

What really made me decide to stop investing more time was the entire chain of behavior:

Unfamiliar contact reaches out proactively

↓

Invites to a sudden interview

↓

Uses a meeting environment I haven’t used before

↓

Browser cannot establish a proper voice connection

↓

I refuse to download and install a new client

↓

I request to switch to a mainstream tool like Google Meet

↓

I request the invitation to be sent via a company domain email

↓

The other party agrees to send Google Meet in 10 minutes

↓

The invitation never appears

↓

Two subsequent messages are left unread

Looking at any single step in isolation doesn’t necessarily indicate a scam.

But from a risk control perspective:

At this point, I had no reason whatsoever to lower my device’s security standards just to complete a remote interview with an unverified identity.

---

10. The Biggest Difference from Last Time: I Finally Stopped Before Installing the Software

This is actually the most important reason I wrote this article.

During the previous Web3 recruitment experience, I was faced with:

The web version not working properly.

My approach at the time was:

Try to resolve the meeting issue.

So:

Download the client.

After the client download failed, accepting the compressed file sent via Telegram.

Finally running an unfamiliar EXE.

Resulting in abnormal processes on my computer.

But this time, facing a very similar scenario:

The web meeting not working properly.

My first reaction had become:

Do not install.

Then request:

Switch platforms.

And further request:

Verify identity using a corporate domain email.

These two processes seem to differ by only a few steps.

But the outcomes are completely different.

Last time:

Unfamiliar software entered my development machine.

This time:

Things stopped within the browser.

No installer.

No ZIP.

No EXE.

No local execution opportunity given to unfamiliar programs.

This is already the biggest difference.

---

11. Why Developers Especially Need to Be Wary of Software Installation During Remote Recruitment

After experiencing these two incidents, I increasingly feel that:

Developers might be a highly valuable target in remote recruitment attacks.

Because a development machine might simultaneously contain:

• GitHub login state;
• Git credentials;
• SSH Keys;
• Cloud server access;
• API Tokens;
• Database connection details;
• Docker configurations;
• Browser cookies;
• WordPress admin backend login state;
• Third-party platform accounts;
• Cloud service consoles;
• And even cryptocurrency wallets.

If an attacker can trick a developer into proactively running a program, the potential value gained could be much higher than from a regular office computer.

And “remote interview software” is a very suitable excuse for software installation.

Because normal remote work inherently requires:

• Zoom;
• Teams;
• Slack;
• Discord;
• Telegram;
• Various project collaboration tools.

So when an interviewer says:

Our team uses this software.

Many people’s first reaction isn’t suspicion.

But rather:

Okay, I’ll install it.

This might precisely be the highest-risk step.

---

12. After These Two Experiences, I Have Now Set a Few Rules for Myself

Having learned the lesson from actually running an unfamiliar EXE last time, I now have a very simple set of rules for remote recruitment.

1. Try to use mainstream meeting platforms for interviews

For example:

• Zoom;
• Google Meet;
• Microsoft Teams;
• Tencent Meeting.

Telegram voice itself can also accomplish the most basic initial chat.

A normal first recruitment conversation usually doesn’t require installing a team’s internal specialized software to be completed.

---

2. An unfamiliar meeting website not working doesn’t mean I have to install a client

This point is especially important to me.

After the web version fails, my current solution is:

Switch meeting tools.

Not:

Install meeting tools.

There is no need to grant local execution permissions to unfamiliar programs just to attend a first interview with an unverified identity.

---

3. Do not accept installation packages sent privately via chat software

Especially:

ZIP
↓
EXE

In this format.

I have already reinstalled my computer once because of this issue.

This rule will not be broken again.

---

4. When proactively recruited, you can request company email verification

If the other party claims to be from a certain company, you can request:

Using the company’s official domain email to send:

• Interview invitations;
• Calendar invites;
• Job descriptions;
• HR contact emails.

A corporate email certainly cannot prove safety one hundred percent.

But it at least adds a layer of verification cost.

Especially when the entire recruitment process exists only on Telegram and there is never any corporate email, I will be even more cautious.

---

5. The other party’s unwillingness to switch meeting tools is itself a signal worth noting

Assuming the goal is truly just to have a 30-minute initial chat, then:

Google Meet, Zoom, Teams, Telegram voice…

Can all actually accomplish this.

So I now ask myself a very simple question:

Why must this interview be conducted through this specific software?

If there is no reasonable answer, I would rather pass up a job opportunity.

---

13. One Job Opportunity Is Not Worth Gambling Your Entire Development Environment

When job hunting in the past, I might have been more susceptible to a certain mindset:

We’ve already talked for so long.

The role is a pretty good match.

The interview is about to start.

It seems a bit of a shame to miss the opportunity over a software issue.

But after experiencing the previous incident, my current mindset is completely different.

Assuming a development machine contains:

Code repositories, SSH Keys, servers, API Tokens, backend accounts…

Then its value far exceeds that of a job opportunity whose authenticity has yet to be confirmed.

Even if that job ultimately proves to be completely real, and I miss out on it due to security requirements, the most I lose is:

One interview opportunity.

But if I run malware for the sake of this opportunity, the worst-case scenario could be:

Servers, code, accounts, credentials, and even assets being compromised all at once.

The two aren’t even on the same risk level.

---

14. Fortunately, the Lesson from Last Time Was Not in Vain

Looking at the outcome, nothing actually happened this time.

I didn’t install any software.

The computer had no abnormalities.

No accounts were stolen.

No system reinstall was needed.

The other party simply stopped contacting me.

But precisely because “nothing happened,” I feel it’s worth documenting.

Because security experience is truly valuable not when:

You know how to handle things after falling for a trap.

But rather:

The next time you face a similar situation, you can stop before things actually go wrong.

In June 2026, I only realized the risk after running fyMeet.exe and discovering abnormal processes.

In July 2026, I chose to stop installing software the moment the browser couldn’t connect to the unfamiliar meeting platform.

Just over a month.

Same Web3.

Same remote recruitment.

Same Telegram contact.

Same seemingly highly matched role for my technical background.

Even encountered the same meeting tool issue.

But this time:

The story ends here.

No Trojan.

No abnormal processes.

No 90% CPU usage.

And no reinstalling the computer again.

---

Conclusion

I still cannot confirm the true identity of the person who contacted me this time.

Nor can I assert that this was a recruitment scam solely based on the other party ultimately not replying.

Perhaps it was just:

The interview was canceled at the last minute.

Or perhaps:

There was an internal coordination issue on the recruiter’s side.

It’s also possible:

They later decided not to consider this candidate.

All these scenarios are possible.

But from a personal security perspective, I don’t need to prove the other party is a scammer before I’m qualified to refuse installing software I don’t trust.

This is perhaps my biggest conceptual change after going through the previous incident:

Security judgments don’t need to wait until “scam evidence” is found to begin.

When a remote recruitment requires me to:

Lower my system security standards, run unfamiliar programs, or ignore obvious abnormalities,

I can absolutely just stop.

And ask the other party to switch to a normal communication method.

Genuinely normal recruitment opportunities can withstand this most basic security requirement most of the time.

And if an opportunity disappears just because **”I am unwilling to install unfamiliar software”**,

Then at least for me:

The cost of losing this opportunity is far lower than losing another development environment.

系列导航