Interviewee: Alex (pseudonym), Senior Software Engineer at Google, 5 years as technical interviewer, conducted 500+ interviews.

Q: How many people have you interviewed?

A: Probably 500+. Honestly, I can remember fewer than 10 of them.

It's not that they weren't good—many candidates had strong technical skills. But the ones who stick in my memory are the "different" ones.

Q: Why? What did they do wrong?

A: They got the right answer, but it wasn't the answer I wanted.

Sounds contradictory, right? But that's the problem with many candidates: they treat interviews like exams, thinking getting the question right is enough.

I've seen this scenario too many times: a candidate grinds 200 LeetCode problems, memorizes standard solutions, and then perfectly reproduces them in front of me. The code runs, all test cases pass, time complexity is optimal.

But when I ask "why did you write it this way," they start stumbling.

Q: What do you mean? Isn't the right answer enough?

A: The right answer is just the baseline, not a bonus.

After 5 years as a Google interviewer, I can tell you clearly: we don't want answer machines, we want people who can think, communicate, and learn.

Let me break it down:

Thinking Process - I need to see your thought path. How do you understand the problem? What difficulties did you encounter? Why did you choose this solution over another? A candidate who can clearly explain their thought process is more valuable than someone who just produces the optimal solution.

Communication Skills - You'll collaborate with teams, explain technical decisions to non-technical people, and persuade colleagues in code reviews. During interviews, whether you can explain complex things simply is key.

Learning Ability - I often deliberately give a "wrong" hint to see how candidates react. Some blindly accept it, some question it, some think and then offer their own perspective. The last type is who we want.

Real Example: Once, I gave a dynamic programming problem. Candidate A used the optimal solution, code was perfect, but didn't speak throughout. When I asked why use DP, he said "because this type of problem uses DP." Candidate B started with a brute force solution, then discovered the performance issue himself, proactively said "I think we can optimize this," and we discussed together until he derived the DP solution.

Guess who I hired? B. Even though his initial answer was "wrong."

Q: Can you give me an example?

A: Let me tell you two real stories.

Case 1: Got it right, but no hire

Candidate C, top CS master's program, 400+ LeetCode problems. I gave him a medium array problem, he finished in 3 minutes, code perfect, all edge cases covered.

Then I asked: "What if the array is too large to fit in memory?"

He froze. Then said: "The standard solution is this way."

I asked again: "What real-world scenarios do you think this problem applies to?"

He answered: "This is an interview question, probably no real application."

Throughout the interview, his code was all correct, but I gave no hire. Because I don't want a memorization machine, I want someone who can think about real problems.

Case 2: Got it wrong, but hired

Candidate D, average work experience, but an interesting project on his resume. I gave him a system design problem, his initial solution had obvious issues.

But he talked while drawing, clearly explaining each component's responsibility, data flow, potential bottlenecks. I said "what if QPS increases 10x," he immediately recognized the problem, proactively said "my earlier design has issues, let me fix it," then gave a better solution.

Although his final answer wasn't perfect either, I hired him. Because he demonstrated:

Ability to spot problems
Ability to quickly adjust
Habit of systematic thinking

This kind of person, once in the company, can figure out new problems themselves without hand-holding.

Q: One piece of advice for candidates?

A: Don't just give me the answer, give me your thinking.

Specifically:

Think out loud - Talk while you think, let me hear your brain working. Even "I'm thinking whether to use a hash table or array" is better than silence for 3 minutes then writing code directly.

Ask questions - If the problem isn't clear, ask. If boundary conditions are uncertain, confirm. This isn't "not understanding," this is being professional.

Admit when you don't know - When you encounter something unfamiliar, just say "I'm not familiar with this, but let me try to analyze it," then show your thinking process. Way better than making things up.

Focus on "why" - Don't just memorize "how," understand "why." Interviewers often ask the latter.

Treat interviews as conversations - Not exams, but two engineers discussing a problem. Relax, show the real you.

Q: What's your take on AI tools?

A: I'm very open-minded. The key is knowing how to use them.

Many candidates now use ChatGPT or Claude for practice and interview prep, that's fine. I use AI for coding assistance myself.

But there are two ways to use them:

First type: Use AI to memorize answers - Throw the problem at AI, memorize the answer, reproduce in interviews. I can spot these people immediately because their code doesn't match their explanation.

Second type: Use AI to learn approaches - Use AI to understand the pros and cons of different solutions, learn why one approach is better, then internalize it as your own knowledge. These people can apply what they learn to new problems in interviews.

I won't ban "AI thinking" in interviews—on the contrary, if a candidate can say "this problem reminds me of an approach I learned from GPT," then clearly explain it, I'll think they're honest and good at learning.

AI is a tool, just like Google and Stack Overflow. People who can use tools are more valuable than those who can't.

But remember: AI can give you answers, but it can't give you thinking ability. Thinking ability is what interviewers really want to see.

Final Words

Interviews aren't exams, interviewers aren't examiners.

We're not looking for "right answers," we're looking for "the right people"—people who can think, communicate, learn, and grow.

So next time you interview, don't just prepare answers. Prepare your thinking, your stories, your unique perspective as an engineer.

Because what I want has never been the right answer.

Preparing for technical interviews? Interview AiBox helps you simulate real interview scenarios, practice thinking out loud, and show your best self in interviews.

Start Practicing →

Related Articles:

Interview AiBoxInterview AiBox — Interview Copilot