How To Be More Interesting During A Technical Interview

“Do you have any questions for me before we wrap up?”

This your chance to make a lasting impression on your interviewer. Don’t squander it by not having a thoughtful question or two. It’s an opportunity to show your prospective employer that you can see a bigger picture beyond scribbled code on a whiteboard. That you care about the humans at the opposite end of the tech stack.

It’s also a chance to learn something about how your prospective employer operates. Maybe there’s some pain point you can help address, or a process gap you can help fill. Maybe you’ll see some patterns that indicate how happy or miserable you’ll be if you accept an offer.

Below are some examples I jotted down after a particularly uninspiring phone screen. Use them, and create your own.


What’s your worst day like? How do you manage it?

If you could change one thing about your tech stack, what would it be? What’s blocking you from implementing this change?

What are some common pain points for your customers? Are you working towards solving them? Why or why not?

How do you respond to customer complaints? Do you have a system for customer-reported issues? How has that been working for you?

How do you monitor failures in the system? Do you have alarms? Do you have an oncall rotation?

How do you evaluate new technology for use? What are your criteria for adoption?

I see from your [source code|press release|company blog] that you’ve adopted [X technology]. What decisions led you to that adoption and how successful has it been?

How do you handle professional growth? What does the average developer career track look like at your company?

Tell me about your deployment methodology. Are you able to do continuous deployment? If so, how? If not, what is your release schedule like and what determines it?

What’s the ratio of product managers to developers? Does this ratio work for you? How did you decide?

How does your team handle code reviews? Do you have a review process?

What is your policy on using and/or contributing to open source projects?

When was the last time your company or team had to migrate to a new tech stack? How did you approach this? What did you learn?

What’s the one thing one would need to do or know to be successful here?