The Ordinary Student’s Interview Advantage: One Project Interviewers Can’t Ignore

In the interview room, the interviewer turns to page two of your resume and stops at a line in small print: “Used AI to revise resumes for 30 classmates; 11 retained; reason for failure: insufficient trust.” He looks up and asks, “Why did those 11 stay?”

Your answer begins there.

What interviewers look for: a chain of evidence

Many students treat potential as a personality trait: quick answers, confident delivery, steady eye contact. Those signals are hard to judge in half an hour. Interviewers can judge a chain: the problem you found, the solution you built, the feedback you got, the trade-off you made, and the version you shipped next.

Kuai Dao Qingyi once told a story. A student made an AI product that helped college students customize, revise, and submit resumes for a specific job at a specific company. After the event, he stopped Kuai Dao Qingyi and asked how the product could be iterated. They talked, and he got an offer. Kuai Dao Qingyi later said he did not know the student’s school. He did not know the student’s earlier record. He saw three things: the student had identified a need he could name, built an initial solution, gotten some early results, and continued to iterate.

That is the bet. The interviewer wants to know whether you can do something, answer follow-up questions about it, and keep going after the first version.

So do not just write “proficient in AI” on your resume. Write what you built with AI, what problem it solved, and what still needed work. Interviewers ask follow-up questions when they see evidence. They believe you when you can answer those questions.

Exam thinking will pull you off course

In an exam, someone else writes the question, someone else owns the answer, and you move toward the answer. Your classmates are competitors. You learn to wait for the prompt, wait for the rubric, wait for a grade. You also learn to believe you must know everything yourself.

Work rarely works that way. The problem is often unclear. Your manager may not have an answer, or may not have defined the problem. You have to decide who hurts, whether the work matters, and what result counts.

Here is a small example. The project needs software installed. You are bad at software. You spend three days fighting it. Exam thinking says you must solve it yourself. A better move: check Taobao or Xianyu, pay 15 yuan, and spend the saved hours on the core validation. Doing everything yourself may look diligent. It may also mean you never calculated the input-output ratio.

Cost works the same way. A component has two metrics, A and B. Option one improves A and hurts B. Option two improves B and hurts A. If the scenario cares more about A, pick option one. If it cares more about B, pick option two. You can say you want both. Implementation forces a choice.

When an interviewer asks what problems you hit, this is the answer he wants: how you thought, where you looked, who you asked, and what you gave up. He cares about your reasoning. He does not care how many terms you memorized.

Performative potential falls apart under follow-up questions

One: jargon. A candidate says closed loop, empowerment, underlying logic, AI-native. Ask who the user is, where the data came from, and what the candidate personally did. The answer stops.

Two: results without process. The numbers look strong. The candidate cannot explain the baseline, the definition, or their own contribution. Sometimes the team’s work becomes their work. One question about the data exposes it.

Three: a polished deck with no validation. The need came from the candidate’s imagination. No user interview. No MVP. No launch. Only a forecast.

Four: leadership inflation. The candidate did odd jobs and calls it leading strategy. Ask how they handled a conflict or coordinated resources. The answer turns abstract.

Five: standard answers. Every question gets a smooth response. No judgment, no trade-off. Open questions make the candidate wait for a rubric.

Six: success only. No failure, no trade-off, no review. That story sounds fake because real projects leave marks.

Seven: proving yourself by putting others down. The candidate blames teammates or attacks prestigious schools. Both lose points.

Eight: proficient in everything, evidence of nothing. The resume says proficient in AI. No product, no problem solved, no user.

Nine: pleasing the interviewer. No questions, no disagreement, no independent judgment. The interviewer is hiring a worker, not a fan.

All nine share a problem: they prove the candidate is impressive. They do not prove the candidate can solve a problem.

Five moves for an ordinary background

Step one: prepare one main project and tell it through a chain of evidence

Do not prepare ten vague stories. Prepare one project that can survive follow-up questions. It does not need to be famous. It needs to be real, closed-loop, and tested. Use this framework:

I found that [who] had [what problem] in [what scenario]. The existing solution fell short here. I built [MVP]. I showed it to [number] users and got [feedback]. I hit [trade-off or failure]. I chose [action]. I iterated to [version]. [Problem] remains. This ability transfers to the role because [reason].

For example, if you made a campus second-hand trading tool, do not just say “I made a mini-program.” Say: When student clubs changed leadership, textbooks and equipment moved slowly. Group messages flooded. Information did not accumulate. I made a minimal registration and classification page and got 30 classmates to try it. They cared more about same-city face-to-face transactions, so I cut the delivery module. Retention stayed low because the trust problem was not solved. I tried campus verification, but the cost was too high. I used same-building pickup to reduce risk. The project was small. It had a problem users had, validation, trade-offs, and iteration.

Step two: map the project to the role

Break down the job description before the interview. Does the role need data analysis, user insight, cross-team coordination, cost control, or fast learning? Prepare one project detail for each ability. With an ordinary school name, business interviews matter more than HR screens. Referrals, portfolio links, and direct conversations with business leads can get you past part of the resume filter. Apply to roles that value hands-on work. Do not only apply to roles that look prestigious.

Step three: put evidence on the resume, not adjectives

Do not write “strong communication skills.” Write “coordinated 3 student clubs and 2 print shops, reducing event material costs by 20%.” Do not write “strong learning ability.” Write “learned Figma from scratch in two weeks, completed a clickable demo, and received 15 pieces of user feedback.” A resume is an index of evidence. It is not a self-evaluation form.

Step four: show workplace thinking in the interview

Before you answer, confirm the boundary: “What hurts most in this role right now, conversion or delivery efficiency?” “Is the potential you mean more business or technical?” Use paper or screen share to draw the breakdown: users, scenario, metrics, constraints, solution, validation. When you get stuck, say: “I do not know this part. I would check X, ask Y, and test Z with the smallest experiment.” Honesty plus a path beats a made-up answer.

Step five: choose a better battlefield

Small and midsize companies, fast-growing teams, and roles that value portfolios and hands-on work are more likely to bet on someone who can do the job. Prepare a portfolio link, a one-page project summary, and a demo video. Apply to large companies too, but do not put all your hope on resume screening.

Three small moves in the interview room

First, confirm the question before you answer. Do not recite.

Second, draw the breakdown. Break the problem into users, scenario, metrics, constraints, solution, validation. A drawing gives the interviewer something to follow.

Third, when you are stuck, give a validation path. Example: “I do not have this data. I would run ten user interviews, read one week of behavior logs, and test a minimal version.”

After the interview, if you still have ideas, turn the discussion into a one-page proposal and send it. Make it useful. Do not send it to prove you exist.

Ending

The interview ends. You hand the resume back. A QR code sits in the upper right corner. The back says: one-page project summary inside. The interviewer scans it and puts it in the folder.

You walk out. Your phone still holds screenshots from the 11 users who stayed. Ten minutes before the interview, you looked at them again. Your next interview is in three days. You plan to add a new line after “reason for failure: insufficient trust”: same-building pickup, retention rose from 11 to 17. You open the one-page summary and add the number.