“What questions can I answer for you?” I asked the interview candidate. We had finished working through some technical problems, and I was ready to gauge his curiosity and passion toward the product, the team, and the mission.

“I don’t really have any,” he replied.

Apparently, he already knew all there was to know about the company after a couple of interviews, and there was nothing more I could add. It was the weakest reply he could’ve given if he wanted to show excitement for the job, and yet, he wasn’t the only smart person I’ve interviewed who’s given that response.

I’ve interviewed roughly 500 people in the past eight years, across Google, Ooyala, and Quora, mostly for engineering positions, but also for positions in management, data science, and product. In nearly every interview, I offer candidates a chance to turn the tables and grill me on questions.

The strongest candidates respond with curiosity. They want to know what the company culture is like, how teams go about shipping projects, what challenges the product faces in the marketplace, what aspects of the work environment can be improved, and what’s being done about them. They would fill the entire interview with questions if I let them. They’re not just looking for objective answers — they’re also curious about how my viewpoints differ from those of other interviewers.

The weaker candidates mistakenly assume that answering the technical questions correctly is all that matters in an interview. That’s important, but technical competence is just the table stakes. Interviewers adopt a much more holistic view of someone’s interview performance.

It’s not hard to understand why — if I’m going to be working with you for 40+ hours per week, whether you can figure out the correct answers to problems we might encounter is only one factor out of many. I’m also evaluating:

• How well you handle feedback or criticism.
• How quickly you can reason about a problem.
• Whether you’d be a good culture fit for the team.
• What gets you excited about the mission and the product.
• How well you communicate.
• Whether we can work through hard problems together.
• Whether your skill set complements what we already have on the team.

When interviewing for a job, don’t think in terms of the fraction of questions you can answer correctly — that alone won’t differentiate you from the rest of the applicant pool. Instead, focus on all the various ways that you can add value to the team and how you can effectively communicate that value to your interviewers.

Maximize the Signal-To-Noise Ratio

In an interview, you only have 30 minutes to an hour to impress your interviewer. And the more value that you can convey per minute in the interview, the more likely you are to succeed and get the job.

As an interviewer, I optimize for questions with a high signal-to-noise ratio, ones that reveal a large amount of useful information (signal) about the candidate per minute spent, with little irrelevant or useless data (noise). I’ll spend some time firing away questions to probe a wide surface area, hone in on any warning flags, and spend energy guiding the flow of the interview whenever we hit an area with diminishing returns.

Interviewing, however, is an imperfect science. And as an interview candidate, you can increase your chances by nudging interactions in the right direction. If you want to distinguish yourself from the other 99% of applicants, your guiding principle should be to maximize the signal-to-noise ratio of your interactions with recruiters and interviewers.

That principle carries throughout the interview process, starting from your application. Jobvite provides recruiting software to its customers, and according to one analysis conducted across 600+ customers, only 7% of job applicants come from referrals, and yet referrals account for 40% of total hires. ^{1 2} The conversion rate from referrals is so high because having someone (or a connection of someone) on the team vouch that you’ve been awesome to work with in the past provides a much higher signal than a few hours of interviews. Your resume is likely to get fast-tracked rather than just sit on the pile, waiting to be discovered. Given the value of a referral, if you don’t know anyone at the company, it’s worth trying to go through a friend, a friend of a friend, LinkedIn, Quora, or any other network to make the initial introduction.

Once you’ve secured an interview, the signal-to-noise ratio guides your interview mechanics. Sharing your thought process as you’re working through a problem, for example, is valuable because you convey a non-zero amount of signal to your interviewer. I get to learn how you reason through problems, how well you communicate, and which parts you excel at or struggle with — signals that I wouldn’t get by watching you pensively stare off into space.

The principle should also guide the tools you use to tackle interview problems. Someone asked on Quora a while back whether interviewers frowned on candidates who use Python or Ruby to solve interview questions. Seen from the perspective of maximizing the signal-to-noise ratio, it’s easy to understand why using Python or Ruby might actually be preferred.

Languages like C, C++, or Java tend to be significantly more verbose than more productive languages like Python or Ruby that come with more powerful built-in primitives like list comprehensions, lambda expressions, or destructuring assignment. Research by Prechelt compared 80 implementations of the same set of requirements across 7 different languages and found that solutions written in C, C++, and Java were on average 2-3x longer in terms of non-comment lines of code than scripting languages like Python. ³ Most candidates I’ve interviewed who code in C, C++, or Java therefore start out at a disadvantage — they need 2-3x the amount of time to convey the same information as someone who uses Ruby or Python. Each minute spent writing boilerplate code for a less productive language is a minute not spent tackling the meatier aspects of a problem and not conveying useful signals to the interviewer.

There are exceptions, of course. If you’re interviewing for a position that involves kernel programming, low-level systems, or iOS and Android development, you might convey more signal by using a language like C, C++, Objective C, or Java because it’s more similar to what you’d be doing on the job. At a more established tech company where code is written in C, C++, or Java, the ability to use one of the company’s standard languages may also provide a signal that interviewers care about. Ultimately, your choice of programming language, like any other decisions during your interview, is important to the extent that it affects the speed with which you can solve problems and provide the interviewer with useful signal.

Assuming you’ve handled the technical questions well, the signal-to-noise ratio also explains why it’s important to ask your interviewer questions. Asking good questions is one of the few opportunities you have to demonstrate your curiosity and excitement for the team and the product and to signal what you actually care about in a job.

What to Ask Your Interviewer

So what questions should you ask your interviewer when it’s your turn to grill him or her on questions?

Shy away from questions that can be easily answered by a few minutes of Googling, reading the company’s website, or using the product (if it’s a consumer product). Those types of questions signal laziness. If the company builds a web or mobile consumer product, you should have done your homework and already tried out the product prior to the interview – it still surprises me how often I’ve interviewed candidates who never even tried out the product they’d be working on and yet expect that they’d be able to get the job.

Instead, focus on questions that the interviewer can uniquely help you to answer. For example, you might ask them to help paint the picture of what working at the company is like:

• What’s your typical work day like?
• What’s the process of taking an idea you have from an inception and shipping it to production?
• What fraction of your time is spent building new things versus maintaining old ones?
• How do product / business / engineering decisions get made at the company?

Or focus on the team culture:

• What’s one thing you really like about working at the company and one thing you’d like to improve? What’s being done about the thing you’d like to improve?
• What are the core values of the company, and what are some examples of how they’re reflected day-to-day?
• How would you describe the culture of the company?

Or dive deeply into one aspect of the product that you’re curious about:

• How did this particular product feature get designed and launched?
• Why did you decide to launch this particular version instead of this other one?
• How has the product evolved since launch based on user feedback?

Or ask about growth opportunities:

• What’s the most unexpected lesson that you’ve learned on the job?
• What is the onboarding or mentoring process like (if any) for new hires?
• What opportunities have you had to work with different people and projects during your time at the company?
• How is knowledge across projects documented and shared at the company?

Or learn about the challenges that the company is facing:

• What are the biggest obstacles to this company becoming massively successful?
• What are the current priorities and focus areas at the company?
• Where would I be able to add the most value?

Given the endless array of questions, the next time someone asks you if you have any questions in an interview, be prepared with an answer other than “no.” Ask ones that can provide you with a lot of signal, as they’ll also signal to your interviewer that you’re thinking hard about the opportunity.