Most coding interviews test for the wrong things.

This post is about what I actually care about when I interview engineers, and why.

What the Interview Actually Is

At a surface level, my interview usually starts with a programming problem that looks fairly straightforward. Underneath that surface, there are almost always edge cases, tradeoffs, or constraints that complicate things.

That is deliberate.

I am not trying to see whether you can memorize algorithms. I am trying to see how you think about engineering problems.

You are allowed to use any tools you want. Including AI. The only rule is that nothing happens in secret.

Talk to me. Think out loud. Let me see your process.

I Am Playing a Role

During the interview, I am usually role-playing a product manager or project manager. I bring you a set of requirements that were dictated from above, often by executive leadership.

Sometimes those requirements contain a gotcha. Sometimes they conflict. Sometimes they quietly imply something unrealistic.

That is also deliberate.

Part of the exercise is seeing whether you can manage up.

Good engineers do not just implement specs. They interrogate them. They ask clarifying questions. They surface risk early. They help non-technical stakeholders understand tradeoffs.

If you notice a problem with the requirements, say so. If you think something will cause downstream pain, explain why. That conversation matters more than the “right” solution.

Collaboration Matters More Than Brilliance

I am paying close attention to how it feels to work with you.

Are you collaborative? Are you curious? Are you kind? Are you respectful when you disagree?

You would be surprised how often technical interviews accidentally select for confidence theater instead of teamwork. I am actively trying to avoid that.

I care deeply about authenticity.

I am not looking for a perfectly polished interview persona. I am looking for a real human being I would trust to build things with.

Getting Stuck Is Fine. Staying Stuck Is Not.

You will probably get stuck at some point. That is normal.

What I am watching for is what you do next.

Do you ask for help? Do you talk through what you are unsure about? Do you try to reason your way forward collaboratively?

One of the biggest red flags for me is pride disguised as independence. Getting stuck is human. Staying stuck because you refuse to ask questions is a problem.

Ask Good Questions About Us

Toward the end of the interview, I really enjoy it when candidates ask thoughtful questions about the company.

Not generic “what is the culture like” questions. Real questions.

Questions that show you care about the same things we care about. Questions that signal alignment. Questions that suggest you are imagining yourself actually working here.

Great interviews feel like a mutual exploration, not a one-way evaluation.

You Must Deliver Code

This part is important enough to be blunt about.

At the end of the interview, I need to be convinced that you can actually write code day to day.

I have seen a very common anti-pattern: People talk confidently about architecture. They describe systems beautifully. Then I ask them to write a small amount of code and everything collapses.

You do not need to finish the entire problem. You do need to show that you can translate ideas into working logic.

Pseudocode is fine. Real code is fine. But something concrete needs to exist.

Using AI Is Allowed. Mastery Is Required.

You are absolutely allowed to use AI tools to generate code during the interview.

In fact, I consider that realistic.

What I am evaluating is how you use those tools.

Do you give them good prompts? Do you understand the output? Do you verify the logic? Do you catch mistakes? Can you explain why the code does what it does?

Blindly pasting AI output without reviewing it is not a shortcut. It is a liability.

What a “Great” Interview Looks Like to Me

My definition of a good interview is one where the candidate learns something.

My definition of a great interview is one where the interviewer learns something.

That might be a new way of thinking about a problem. A perspective I had not considered. A question that makes me pause.

If that happens, regardless of outcome, the interview was a success.

Final Thought

You do not need to perform. You do not need to impress me with jargon. You do not need to pretend to be someone you are not.

Show me how you think. Show me how you collaborate. Show me that you can build.

That is it.