In Interviews, Influence Isn't About Authority—It's About Getting People to Move with You

In behavioral interviews, you often get questions like:

“Tell me about a time you influenced someone without authority.”

Many people panic when they hear this.

I'm not a tech lead, and I'm not the project owner—what influence do I have?

But real influence is exactly what shows up when you have no title and no authority.

When you have a title, people listen because of your role; when you don't, people choosing to work with you is the real skill.

Influence isn't about “persuading someone” or “getting support.” It's about whether you design a path that makes the other person willing, able to understand, and confident enough to move forward.

It's not about being a great talker—it's about the other person being willing to act.

Cross-team, cross-timezone, no title—but you can still push collaboration forward

I was involved in a financial system migration project.

Our goal was to migrate a core calculation service from a legacy platform to a cloud-native system. The underlying logic handled foreign exchange hedging calculations for billions of dollars in assets.

Right after the interface integration was done, testing revealed a problem: data inconsistencies between the new and old systems.

These inconsistencies were easily labeled as bugs in the new system. On top of that, the two data sources were owned by a US team, and our team had no responsibility for any upstream data, nor any product or technical ownership.

In short: when something went wrong, we couldn't change their code; if we didn't change it, our system couldn't go live.

At the time, nobody wanted to take on this mess. But I knew that regardless of whose responsibility it was, if nobody pushed it forward, the whole system would stall.

I started with the smallest part: reproducing the scenario.

First, I synced production data and verified the new system's own calculation logic to make sure it wasn't being wrongly blamed. Then I wrote an automated comparison tool that structurally compared the outputs of the new and old systems by field, source system, and difference type.

For every mismatch, we cross-checked screenshots, payloads, and raw logs one by one, proving in the most indisputable way whether it was a bug or an expected difference.

We didn't just send a message saying “your system has a bug.” Instead, we organized the evidence into clearly structured comparison tables, with screenshots, text, and annotations, categorized by field level, and sent them over. No blame, only transparency.

Some issues were on the other system's side, some were due to our previous misunderstanding of the processing logic, and one was very subtle: the precision of the FX rate calculation had changed from a multiplication formula to a division formula. The precision difference was in the seventh or eighth decimal place, but at a scale of billions in funds, it could cause differences of tens of thousands of dollars.

I explained this issue in a structured way, reproduced the scenario, cross-referenced the mathematical formula with compliance documents, and sent it to the business side for confirmation.

They quickly realized this wasn't an engineering detail—it was a compliance risk.

Throughout the process, I had no title and no authority, but I pushed it forward because I did three things:

1. Used reasoning instead of giving orders. Not “we need you to change this,” but “here's the data, here's the logic, why is this happening?”
2. Used structure to lower the cognitive barrier. Instead of making others investigate the problem themselves, I organized everything for them, allowing them to decide without friction.
3. Used relationship rhythm to maintain collaboration warmth. We had fixed weekly syncs, no pushing or arguing; when the other side completed a fix, we wrote thanks and followed up with regression testing.

This isn't just communication skill—it's influence: you don't stand in a high position, yet you can pull things forward; you don't wear a hat, yet you can make people believe what you're saying is worth doing.

When you're not empowered, how do you gradually build trust?

Once, I had just joined a new project team when an internal roadmap adjustment came up. Our team was assigned to maintain a low-priority component with many cross-team dependencies.

It wasn't technically hard, but nobody wanted to take it on because it had no direct output, little visibility, and was easy to get blamed for by other teams: “You didn't maintain it well.”

I observed and found that the problem wasn't that people couldn't do it—it was that nobody cared even if they did.

I wasn't a TL or a project lead. But I compiled three months of incidents, delay records, and feedback from relevant people for this component, and created a risk trend chart.

I didn't use this chart to ask for resources. Instead, I sent it to two senior members of the team to see how they viewed the problem.

One of them read it and privately said to me: “I feel like someone should systematically follow up on this, but you're not trying to push it onto me, are you?”

I said no, I was hoping we could think together about where the responsibility boundary for this component should fall, rather than our team taking the hit every time there's an incident.

Later, the three of us worked together to create a responsibility split table, and pulled in another team to review three recent cases together. The other side had previously been the type to shift blame, but after that review, they said: “Actually, we also feel this component has no standards, and a certain part of it is indeed related to our team.”

At that moment, I didn't say anything, but I knew trust had been built, and there was hope for this matter.

I didn't use “we must” or “you should,” but I created a rhythm that allowed the other party to see the problem under low tension, and then spontaneously make a choice.

This is influence that doesn't rely on role or tone, but gradually builds trust.

How does AI help me reflect on the structure of influence?

When preparing for these interview stories, I use a specific set of prompts to have AI help me break down: am I talking about execution, or influence?

You can also try these prompts (works with ChatGPT or Claude):

I’m preparing for a behavioral interview. Here’s a story where I influenced others without authority: [paste] Please help me: – Highlight moments where I guided decisions through reasoning, not power – Point out any vague areas that could be strengthened with clearer influence patterns – Ask 3 follow-up questions an interviewer might use to test my influence depth

Sometimes I also ask it to help me summarize the “decision path map” of such stories:

• Where was the initial disagreement?
• Who was the target of influence? What was their original resistance?
• Did my actions reduce resistance, or did I just do more work?
• At what moment did the other person start to change? Why?

These aren't meant to fit interview stories into the STAR framework, but to help me articulate the process where I didn't give orders, but decisions were moving.

Real influence is when you're present, but you don't stand in front

Looking back at the projects I'm most proud of, many times I wasn't the name written in the report.

But at every key moment when someone caught the rhythm, nodded, and agreed to keep going, I knew: I was there, and I participated in building that rhythm.

Behavioral interviews about influence aren't about how well you talk—they're about how, when you weren't empowered, you made people automatically choose to walk the path you laid out.

Influence isn't about making others listen to you; it's about making others believe that what you're saying is worth doing.

Public account comments: Totally agree, learning from Sister Hammer! 👍 Sharing a bit of my own experience, though the difficulty is far below Sister Hammer's.

I've been working from home alone in Australia for over three years. When I joined, I faced hundreds of Slack messages every day, and my manager assigned tasks one by one on schedule. In the first three months, I organized common failures into tables; after six months, I built a POC environment to demonstrate the efficiency and cost-effectiveness of a stateless architecture. As a result, customer data sync time dropped from 4+ hours to 30 minutes, and expensive instance runtime went from 24x7 to 4x5, saving over $10,000 per month. A year later, the system was successfully migrated to the new architecture. Previously, I was busy 8x5 every week; after the adjustment, only 3x4 😛. As the team member who joined last and knew the least about multiple systems, I gradually won recognition from my manager and cross-departmental teams through data collection, performance comparison, and demos, and steadily pushed the architecture adjustment to implementation.

Actually, the optimization wasn't technically complex. The original architecture relied on multiple servers to process data, using rsync to distribute hundreds of GB of data to over 100 clients worldwide. After optimization, it changed to a server → S3 → clients flow, improving data processing and distribution efficiency several times over. Before building the POC environment, I communicated repeatedly with my manager. He verbally agreed but didn't explicitly support it. After I independently completed the POC environment, the performance improvement was obvious, and my manager immediately gave strong support, pushing forward the data distribution architecture optimization.

-==== Once HR asked me to tell a story about overcoming a technical challenge. I talked about how I was the first to break through, built team confidence, and then taught others—even my leader learned to do the task. After finishing the story, I concluded: It's not about skill, it's about influence.