Big Tech Director: How I Judge If Someone Can Actually Do the Job

Interviewee: Zhang (pseudonym), Engineering Director at a top-tier tech company, 15 years of technical management experience, led 100+ person teams, interviewed 2000+ candidates.

Opening

Zhang's office is in the quietest corner of the campus. Three monitors sit on his desk, code still running. He just finished a technical review meeting.

"I interview at least 5 people every week," he says, sipping tea. "After all these years, judging whether someone can actually do the job isn't that complicated."

We sat down and talked for two hours.

Q: What do you look for most in interviews?

Zhang: I don't look at degrees. I don't look at LeetCode counts. I look at three things.

Many people think Big Tech interviews are just about algorithms and system design, but those are just thresholds. What really determines hire or pass comes down to these three things: problem-solving ability, communication and collaboration, and learning ability.

A degree only shows what you've learned in the past, not what you can do in the future. LeetCode counts only show you've prepared, not that you truly understand.

I've seen too many people from top schools who've solved 500 LeetCode problems but can't actually do the work once they join a team. I've also seen people from second-tier schools who've never solved a single algorithm problem become core contributors within three months.

Q: What are these three things? Can you explain in detail?

Zhang: Sure, let me explain each one.

First: Problem-Solving Ability

This is the core. Technical work is essentially about solving problems—how to fix a downed system, how to optimize slow performance, how to refactor when requirements change.

In interviews, I ask a very specific question: "What's the trickiest technical problem you've solved recently?"

Then I keep digging:

How did you discover this problem?
What was your troubleshooting approach?
What solutions did you try? Why did they fail?
How did you finally solve it?
If you could do it again, what would you do differently?

If a candidate can clearly explain the thinking process at each step, it shows they genuinely have problem-solving ability. If they can only say "I used XX solution to solve it" but can't explain why they chose that solution, chances are they just followed documentation or were taught by someone else.

Second: Communication and Collaboration

Many people think technical skills are enough. Wrong.

In a team, your code needs to be maintained by others, your designs need to be reviewed by others, your progress is a dependency for others. Poor communication turns technical strength into a disaster.

I've seen a classic example: an engineer with excellent technical skills who never wrote documentation and barely commented code. After he left, it took the person taking over two months to understand the system he built. Is that strong ability? No, that's digging holes for others.

In interviews, I ask: "Have you ever had disagreements with product managers, designers, or other engineers? How did you resolve them?"

If a candidate says "no," I follow up: "Really, never?" If still no, either they haven't truly participated in team collaboration, or they avoid conflict—neither is what I want.

I want someone who can clearly express their own views, understand others' perspectives, and find solutions both sides can accept.

Third: Learning Ability

Technology evolves too fast. Hot technologies from three years ago might be obsolete now. Architectures from five years ago might no longer be suitable.

If someone lacks learning ability, no matter how strong their current technical skills are, they'll fall behind in two years.

In interviews, I ask: "What new technology have you learned recently? Why did you learn it? How did you learn it?"

I've heard many types of answers:

"The company needed it, so I learned it"—passive learning, not bad but not great
"I read a book/took a course"—shows learning awareness, but stays theoretical
"I built a side project, ran into XX problem, researched XX resources, and finally solved it"—this is what I want to hear

Active learning, hands-on practice, solving problems independently—that's real learning ability.

Q: How do you judge these things in interviews?

Zhang: I have several techniques.

Technique 1: Dig into Details

Many people prepare "standard answers" before interviews. But details can't be faked.

For example, if a candidate says "I led a system refactoring project," I ask:

What was the architecture before refactoring?
Why refactor? What were the pain points?
What problems did you encounter during refactoring?
How did you convince the team to support the refactoring?
What were the results after refactoring? Do you have data?

If the candidate actually did it, they can answer. If they made it up or were just participants rather than leaders, they'll start getting vague by the third level of questions.

Technique 2: Give Hints, Watch Reactions

When asking technical questions, if a candidate gets stuck, I give a hint.

Then I watch their reaction:

Some immediately grab the hint and continue thinking—this is good
Some wait for me to give more hints—this shows over-dependence
Some panic and start guessing randomly—this shows poor stress tolerance

I actually don't mind if candidates can't answer at first. What I mind is their attitude when facing difficulties.

Technique 3: Ask About Failures

"What's the most failed project you've worked on?"

This question reveals a lot:

If they say "I haven't had any failures"—either they haven't done challenging projects, or they're dishonest
If they can explain why they failed and what they learned—this is good
If they blame others—this is a red flag

I once had a candidate say his failed project was because "the product manager kept changing requirements." I followed up: "Did you try communicating with the product manager to understand why they were changing requirements?" He said no.

That shows poor communication and collaboration ability.

Q: What's the most surprising candidate you've hired?

Zhang: There's one I remember vividly.

Three years ago, we were hiring senior engineers. A candidate came in—second-tier school, four years at a small company I'd never heard of.

The resume looked very ordinary. But during the interview, I asked a system design question, and his answer caught my attention.

He didn't immediately give a solution. Instead, he asked me many questions:

What's the user scale for this system?
What are the latency requirements?
How important is data consistency?
How large is the team? What's the tech stack?

I said, "Why ask so much? Just give me a solution."

He said, "The optimal solution varies completely in different scenarios. If I don't understand the scenario, the solution I give might be wrong."

I immediately felt this person had experience.

Later, I asked him to describe a system he'd built. He talked about a very small feature—a configuration management system. But he explained it so clearly:

Why build this system
What problems were encountered
What solutions were tried
Why this particular solution was chosen
How it performed after going live

The entire answer was logically clear with solid details. I could feel he had genuinely thought through every decision.

In the end, I gave a hire, and rated him one level higher than his resume suggested.

Now this person is already a tech lead in our team, leading a group of ten. Facts proved my judgment was right.

Q: What's the most regrettable candidate you've passed on?

Zhang: There's one of those too.

That person had very strong technical ability. Solved algorithm problems instantly, explained system design flawlessly, and had a beautiful resume—top school graduate, worked at Big Tech, built several core projects.

But I asked one question in the interview: "Have you ever had conflicts with colleagues? How did you resolve them?"

He said: "Yes. I argued with a product manager before. He thought my technical solution was too complex, I thought he didn't understand technology. Finally I went directly to the boss to make the call, and the boss supported me."

I followed up: "How was your relationship with that product manager afterward?"

He said: "We don't really talk. Anyway, the project got done."

I felt something was wrong right then.

Later I asked: "How would you describe your coding style?"

He said: "I think my code is well-written, but people often leave comments during reviews. I think they're not skilled enough to understand my code."

That's the problem.

Strong technical ability, but poor communication and collaboration skills, plus lack of self-reflection. This type of person might produce a lot in the short term, but will create many problems long-term—code others can't understand, tense relationships with colleagues, unwillingness to accept feedback.

In the end, I gave a pass.

My boss asked me why I passed. I said: "This person is technically strong, but will be trouble in the team." Boss said: "Are you sure?" I said: "I'm sure."

Later I heard he went to another company and left after six months. The reason: "didn't fit with the team."

Q: Any advice for job seekers?

Zhang: Don't prepare answers. Prepare stories.

Many people memorize "standard answers" before interviews:

"What's your greatest strength?"—memorize one
"What's your greatest weakness?"—memorize one
"Why do you want to join our company?"—memorize one

But interviewers aren't stupid. You can hear the difference between memorized answers and real experiences.

My advice:

Prepare 5-10 real project experiences, each clearly explaining background, problem, action, results
Each experience should withstand follow-up questions, details should be solid
Don't just talk about successes, talk about failures too, but explain what you learned
Don't just talk about technology, talk about collaboration, how you worked with others

Interviews aren't exams where you pass by answering correctly. Interviews are about letting the interviewer understand you as a person—what you've done, what you can do, what kind of person you are.

Showing through stories is much more effective than showing through answers.

FAQ

Q: Does Big Tech really not care about degrees?

Zhang: Saying they don't care at all would be false. Degrees are a screening threshold, but not a deciding factor.

During resume screening, degree is a reference point. But once in the interview stage, degree doesn't matter. I've seen too many people from top schools who can't perform, and people from ordinary schools who are very strong.

So if your degree isn't great, don't be discouraged. Focus on improving your abilities, and prove yourself through project experience and interview performance.

Q: Should I practice LeetCode or not?

Zhang: Yes, but don't just practice.

Algorithm questions are a threshold—many companies will test them. But the purpose of practicing isn't to memorize answers, it's to understand approaches.

I suggest:

Solve 100-200 classic problems, understand common algorithms and data structures
Don't just memorize answers, understand why it's solved this way
During interviews, focus on explaining your thought process, don't just give code

Q: What if I get nervous in interviews?

Zhang: Nervousness is normal. I get nervous during interviews too.

My advice:

Treat the interview as a technical exchange, not an exam
The interviewer isn't your enemy; they just want to understand you
It's normal not to know an answer; you can say "I can't think of it right now, could you give me a hint?"
Don't panic, don't guess randomly, stay calm

Q: What if the interviewer asks questions that are too easy/too hard?

Zhang:

If the question is too easy, don't show disdain. Answer seriously, then add "This question could also be considered from XX perspective."
If the question is too hard, say "I haven't encountered this problem before, let me try to analyze it." Then explain your thinking process. Interviewers actually care more about the thinking process than the final answer.

Closing

Zhang said one last thing: "Interviews aren't about finding perfect people. They're about finding the right people."

Technical skills can be developed, but attitude and mindset are hard to change. So in interviews, he doesn't look at how many technologies you know, but at you as a person—how you think, how you communicate, how you face difficulties.

If you're preparing for interviews, remember Zhang's words: Don't prepare answers. Prepare stories.

Want AI-powered real-time feedback to practice telling your stories well? Try Interview AiBox.