A Tech Influencer's Resume Scandal Exposes Five Engineering Pitfalls That Kill Interviews

Jumping on a hot topic.

A couple of days ago, I saw news that the tech influencer "AsuCoding" (netizens call her Su Shen, or Goddess Su) was rumored to have landed a million-yuan annual salary, an L7/L8 level, and entered Meituan's Beidou Project—Meituan's top-tier talent program targeting the most hardcore technical roles.

Two days later, the reversal came. A group of former ByteDance employees came out to debunk it: your DeerFlow project was clearly just participating in some non-core modules during an internship. How did it become "project lead" and "personal graduation project" on your resume and in your videos?

I stared at that trending topic for a long time and sighed. Because this script is all too familiar from my career coaching sessions—the only difference is that when my students stumble, they don't make the trending searches; they just fail their own interviews.

I won't take sides on the truth of the online rumors, but the pitfalls in this resume are very real. Let's break them down one by one from an engineering perspective, and I'll tell you how to fix them.

Pitfall #1: Writing "Participated" as "Led"

Su Shen's core stumble point is right here. It's said she described DeerFlow as something she led, but the debunking former employees said she only participated in a few non-core modules during her internship.

This is the pitfall I see most often. Many students, when writing about projects, habitually change "I participated in XX" to "I led XX"—subconsciously thinking that if they don't write it aggressively, HR won't notice them.

But interviewers aren't stupid. If you write "participated," he asks "what specifically were you responsible for," and you just need to answer clearly. If you write "led," he defaults to assuming you have a thorough grasp of the big picture, from architecture, technology selection, pitfalls, to fallback strategies, digging all the way down. If you truly led it, you'll be in your element; if you only participated, you'll be exposed in three sentences.

How do you write it so it's both honest and impactful? Look at a failed version and a rewritten version:

❌ Failed version: Led the development of DeerFlow's multimodal Agent core module, responsible for architecture design and implementation. ✅ Anti-debunking version: As an intern, participated in the XX sub-module of DeerFlow (non-core), independently responsible for the integration testing and unit testing of the XX interface, covering 12 cases, reducing the module's integration testing time from 2 days to 4 hours.

The latter doesn't steal the credit of "leading," but clearly explains "what exactly you did and what results you achieved." This is ten times more valuable than a vague "led"—because it's true and can withstand questioning.

Pitfall #2: Writing Team Achievements as Your Own

Another stumble point for Su Shen was packaging the collective achievements of a team's open-source project as personal accomplishments.

Big tech background checks are not a formality, and you can't defend against "cross-referencing":

• Code Trails: Commit, PR, and review records on GitHub and internal repositories are public. How many lines you contributed, and whether it was a core module, can be checked at a glance.

• Former Colleagues: Su Shen was directly exposed by former colleagues and project insiders. You think you're packaging a resume, but you're actually packaging a persona that can be torn down by former colleagues at any moment.

• Tech Community Memory: Open-source project contributors all know each other. If you describe an edge module as something you led, insiders will recognize it instantly.

For team projects, clearly write two layers: what the team did + what you personally contributed + the impact of that contribution. This neither buries your own efforts nor steals others' credit.

Pitfall #3: A Resume That Can't Withstand Three Layers of Questioning

The first lesson in my interview prep is to have students do a "questioning test": the interviewer asks three consecutive layers of questions about every line on the resume—

Layer 1: What specifically did you do on this project? Layer 2: How was this feature implemented? What was the biggest pitfall? Layer 3: If concurrency increases tenfold, or data increases a hundredfold, will your solution still hold up? How would you modify it?

Fabricated experiences can't survive the second layer. Packaged experiences can't survive the third. Those who truly did the work answer all three layers easily, providing more and more detail as they go—that's authenticity, and it can't be hidden.

One ironclad rule: Every single word written on your resume must be something you can expand on and talk about for 5 minutes on the spot. If you can't, either make it more factual or delete it.

Pitfall #4: Falsifying Campus Recruitment Applications Costs You the Most

Many people think "a little exaggeration in campus recruitment is fine." Wrong. The cost of falsifying a campus recruitment application is actually the highest.

Background checks for campus recruitment are stricter than for experienced hires. Your "resume capital" consists of just those few internships and projects. Once exposed, it's not just losing one offer; it's being blacklisted, affecting your entire career starting point. Moreover, campus recruitment looks at potential and fundamentals, not packaged halos—interviewers would rather have a candidate with solid fundamentals who can clearly explain a small project than one with a shiny halo who can't answer any questions. The moment you change "participated" to "led," you're betting the interviewer won't dig deep, but campus recruitment interviewers love to dig deep.

Pitfall #5: In the Vibe Coding Era, "Faking It" Can't Survive the Whiteboard

What is Vibe Coding? You no longer write code line by line; you describe requirements in natural language and let AI write it, and you're responsible for the "vibe feeling right." The barrier to entry is low, the output is flashy, and you can "make" a runnable small project in a day.

That's exactly the problem: when "output" can be generated by AI with one click, "underlying engineering capability" becomes the only differentiator. Engineers who understand engineering know how many pitfalls a project faces when going live—performance, edge cases, exceptions, concurrency, security, maintainability. Those faking it can run a beautiful demo, but freeze when asked "how do you monitor, create fallbacks, and scale after launch?"

Big tech interviewers basically have three moves to identify fakers: deep-diving into project details, live/whiteboard coding, and pressure questioning. The debunkers in the Su Shen incident used the same logic, just changed to "former colleagues publicly questioning."

A word to backend engineers transitioning to the AI track: don't just learn the "vibe feeling right" of Vibe Coding. Round out your engineering capabilities—high concurrency, high availability, observability, incremental indexing, idempotency, security sandboxing. AI lowers the barrier to "output," but raises the barrier to "making AI run stably in a production environment." And this, precisely, is the moat for backend engineers.

Hot Topics Pass, But Your Resume Won't

The biggest revelation from the Su Shen incident for ordinary people isn't "don't package," but rather packaging has boundaries, and authenticity lasts the longest.

Polishing is okay: making colloquial language professional, organizing scattered points into STAR format, supplementing vague points with numbers. Fabrication is not: writing participation as leadership, team efforts as personal, things you didn't do as things you did—once cross-referenced, it's career credit bankruptcy.

The path for ordinary people to take is very simple: real projects (even small ones, done from start to finish by yourself), verifiable contributions (code in the repository, verifiable by former colleagues), quantified results (speak with numbers). A resume like this doesn't rely on a halo, but on solid confidence.

Before sending out your resume, run through these 7 checks yourself:

1. Every line can be expanded on and talked about for 5 minutes on the spot (the questioning test).

2. Strictly distinguish between "participated" and "led," and don't steal team credit.

3. For team projects, clearly write "what the team did + what I contributed + the impact of that contribution."

4. Every project has quantified results (numbers/ratios/time comparisons).

5. Technical actions are written concretely: what solution was used, what pitfalls were encountered, how they were solved.

6. Code/documentation has a trail, and former colleagues can verify your contributions.

7. Anything you can't explain or is vaguely exaggerated, either make it factual or delete it.

For more resume breakdowns and real project templates for backend-to-AI transitions, I continuously update on my personal site: https://wangzhongyang.com/