Stop Over-Packaging Impact Metrics: The "Anti-Framework" Interview Lessons from AMD and Microsoft

Hi, I’m Aaron Wu. I’m writing this to share the "anti-playbook" interview lessons I learned the hard way while navigating the software engineering job market.

I’m writing this with a few different people in mind:

• If you are a hiring manager or recruiter: I hope this gives you a clear window into who I am, and my honest approach to technical details and project development.
• If you are early in your career or on a similar path: I hope this helps break the myth of "obsessively over-selling your resume" and helps you regain your authentic confidence in interviews.
• If I sent this to you directly: You might be reading this because you recently asked me about interview tips or resume prep. I want to use these raw, real-world reflections as a starting point for our conversation.

To Know What Managers Want to Hear, Know What They Are "Sick of Hearing"

You've definitely heard of the XYZ formula, or the mandatory STAR method for interviews. We are taught by countless tutorials to focus on the Result, to emphasize quantitative metrics. This was originally just a structural tool to help with expression, but nowadays, candidates seem to over-inflate the "impact" portion—especially those shiny numbers.

Why "Impact Metrics" Are Meaningless to Interviewers

Right before my internship at AMD ended, I set up a 1-on-1 meeting with my manager and asked him, "Why did you hire me?"

He didn't hesitate: "Because you could actually explain your code."

What did that mean?

He went on to complain that too many junior engineers today open their mouths and spout empty business value, thinking it makes them look professional. But when asked, "What parameters does this function take? Why did you design it this way?" they can't utter a single word. Those candidates are disqualified in the first five minutes. A holistic understanding of a project—from the high level down to the low level—proves your true dedication as a "software engineer" to your work. When hiring a junior dev, the ability to think critically and explain development and design choices is far more important than the final result of the project.

"But some projects really need numbers to show how successful they are, right? Doesn't that prove my capability and effort?" I asked.

"Let me ask you," he replied, "an accuracy rate improving from 80% to 95%—what does that number actually mean?"

"It brings value to the company and the team?" I offered tentatively.

"Does it explain anything about the developers behind it? Does it prove they are competent?" He shook his head. "Right, there's zero information beyond that."

He then broke down a harsh reality: "I don't care how much money your project made in production, how many users' problems it solved, or how much faster it became. Behind all those successes, there could be a problematic engineer who just happened to tweak the right API, or who used the wrong approach to reach the goal, hiding all the technical trade-offs. Conversely, behind many completely failed projects, there are truly excellent engineers—there are just too many uncontrollable external factors."

He paused, then summarized: "So, to a clear-headed hiring manager, metrics don't really mean anything when evaluating the specific candidate sitting in front of me."

"In contrast, you honestly analyzed what you knew and what you didn't know, because you had actively thought about the trade-offs you could and couldn't make within a limited timeframe during your previous internship in Taiwan. Your words were full of confidence, which made me genuinely feel you'd be a great candidate."

From this, we can see that in an era where AI can write a perfect resume for anyone—and where some even recommend fabricating data just to show you have an "eye for impact"—senior interviewers are already immune to empty impact metrics. Being able to calmly judge what I knew and didn't know within my specific development context, and talking about it with confidence, was the main reason I stood out.

My Rehearsed "Scripts" Crumbled Before a Microsoft Veteran

Let me share another story from an Applied Scientist internship interview at Microsoft shortly after. It was supposed to be a behavioral interview. But facing a 15-year industry veteran who fired off question after question, I realized that my prepared "communication framework" stories and my "self-taught to solve problems when no one in the team knew about agents" stories suddenly felt like cheap parlor tricks.

He skipped the small talk entirely. He directly asked exactly how much I successfully improved the agent's accuracy, and immediately grilled me on a project from six months ago: "What was the dataset size? What was the difficulty distribution? Where is the underlying test data?" Essentially, his entire line of questioning was: "How exactly did you achieve this accuracy rate?" Wow, this was remarkably similar to what my AMD manager told me, except he started with the impact and then peeled back the layers by constantly asking how and how do you know.

I took a deep breath, abandoned all the packaging, and honestly explained the underlying tests I ran privately back then, purely out of "curiosity." As a result, I actually managed to hold my ground using those long-forgotten details. Although I ultimately didn't get the offer (which I felt was completely fair, as my preparation for agent testing was genuinely insufficient), it taught me a vital lesson: The confidence I bring to an interview requires knowing clearly what I know, what I don't know, and why I did what I did—but it also requires a relentless technical curiosity.

Because they are not looking for a machine that knows how to pass a test; they are looking for a living, breathing person who digs into bottom-layer logic out of curiosity when they encounter a bug.

An Interview Isn't a Formula; It's Sharing Your "Expedition Log"

I realized that during an interview, sharing the treasure-hunt-like process of "finding a solution to a problem" feels incredible, almost like unpacking your thought process while being interviewed for a documentary. But it's too much to ask ourselves to thoroughly unpack our development experiences right before every single interview. Therefore, that technical curiosity has to exist during the actual development and testing phase. You have to constantly ask yourself "why" so you can have a better understanding of the situation and task. You need to treat your development projects with the same level of immersion as binge-watching a great TV show.

That way, even if we get stumped by a question, we can at least say, "I don't know, but..." The energy a person projects when they are honest and confident is incredibly powerful, and I believe this is what makes an interviewer think, "I want this person on my team."

So, this is the conclusion: Interviews shouldn't be treated like plugging numbers into a formula. You need to separate the work. Before the interview, actively immerse yourself in development and collect those "expedition stories." During the interview, your job is simply to figure out how to articulate that process (this is the true purpose of the STAR method, not a framework for making up stories or results—that’s completely backward). At that moment, your energy should be focused dynamically on noticing what the interviewer actually wants to talk about and what they are interested in, just like a normal person sharing a conversation.

I hope this article helps you out or gives you a sense of my approach to job hunting. I feel like not many people on the internet share this kind of brutal honesty, but many people have told me that these traits are exactly what they care about most when selecting a Junior. I believe the ultimately invincible weapon is "confident honesty," along with the clear understanding that what you are selling is yourself, not your past accomplishments.

If you think my mindset and approach would be a good fit for your team, I’d love to explore opportunities to work together. Or, if you just want to discuss tech or bounce some ideas around, my inbox is always open. Just shoot me an email at AaronWu.official@gmail.com — I’d love to chat!