Skip to content
GitHub Copilot is now available for free. Learn more

Interview the interviewer

It’s not presumptuous to turn the tables on an interviewer.

Artwork: Kasia Bojanowska

Photo of Kathy Korevec
Vercel logo

Kathy Korevec // Vice President, Product, Vercel

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

It’s easy to think that an interview is mainly for a hiring manager and their team to evaluate and judge candidates. The truth is that interviews are a two-direction experience. The team has to decide if they want to extend you an offer and, if so, you have to decide whether to accept it. Years ago, I started asking the same question in every interview I had for a new role: “How will I fail?” This question always surprised the interviewer, and I consistently learned significantly more about the role, the company, and the team. When I started doing this, I flipped how I thought about interviews. I stopped seeing them as a meeting to just evaluate me. Instead, I realized they’re a tool to build opinions about a decision I would soon make: to join a new company, or not. I’ve learned a lot of lessons along the way, and the most important one is how to interview the interviewer.

Five questions to look under the hood of the interview 

1. How will I fail? 

Why this matters: This question can clue you into whether or not the person who’s interviewing you has truly thought about your success in the role. The majority of employees who leave a company report that the primary reason was poor management. Answering this question mindfully gives you insight into whether the hiring manager knows what the blind spots are for the role, and if they’ve thought through the challenges that they’ll need to help you navigate. 

2. How do you incentivise your team? 

Why this matters: Knowing how people are rewarded tells you what is actually important to the hiring manager. For sales roles, the answer to this question is straightforward, but for people working with engineering, product, and design, it’s much more nuanced. Will you be rewarded for how much and how often you ship code? Are people incentivized by delivering on KPIs and adoption metrics? Closing the most support tickets? Look for examples that let you know whether or not you’ll be able to thrive based on what you’ll be judged and rewarded for. There could be red flags if the incentives are unfair, unattainable, or not well thought through. 

3. Can you share an example of something the team did that didn’t go well, and what did you do to course correct?  

Why this matters: The first thing this question helps you learn is whether or not the team and leadership have thought about principles and values, how they communicate and uphold those, and how they work to hold a high bar. The second thing this question can do is help you understand if the team is rewarded for thinking like scientists. Are they encouraged to try, fail, and learn? 

4. What does the shipping look like internally, and, 5. How much attention do you pay to reducing friction for the engineering team? 

Why this matters: I hear a lot about teams that are slowed down by too much process, failing tests, slow or inefficient PR reviews, or single-track efforts (one engineer per project). There’s a constant balance that engineering teams need to maintain to help evolve their workflows and ship more efficiently. Knowing whether or not this work is valued at the company will give you a big clue into what working with the team will be like. 

The secret sauce of interview preparation 

Arming yourself with information is the antidote to feeling nervous in almost any situation. Finding the power you need to feel convicted, and the confidence to be honest, are what you need going into, during, and after an interview. 

Research what customers are saying about the company. It’s important to understand how the company is perceived by its own customers; those are the people that you’re going to be thinking about the most, after all. You’ll be spending a lot of time with your co-workers, but the majority of it will be thinking about your customers. It’s important to get in their heads even before you know whether or not you’re going to join the company. 

Design the ideal scenario for your first few weeks on the job. When you start at any new company, you have an opportunity to reinvent yourself. Identify what it’s going to take for you to achieve your goals well in advance of accepting the role. Doing this work up front, while you’re interviewing, forces you to be honest with yourself about the decision to accept or decline an offer. Tactically, this will help you identify what gaps you currently have in your own experience. For example, what do you need to learn? Who will be your mentor? How will you know you’re in a high-stakes moment vs. an everyday situation? 

Data is your best friend in the interview process. Similar to the research you do about customers, dig into the public data that’s available about the company to complete the picture of the opportunity. Look to things like Google Trends to understand market fit and opportunity; CrunchBase to learn about who financially supports the company and how much runway they have; and GitSence data to learn about the company’s commitment to open source. Even if the insights you glean from the data aren’t entirely bulletproof, this exercise will give you additional topics to cover in the interview, help you stay curious, and, if you accept the role, provide a starting point for research you do in the future. 

Why all of this matters

It may seem a bit presumptuous to ask so many questions of an interviewer, but the questions I outlined above will help both you and the interviewing team determine if you're a good fit for the role. Think about it this way: You’re making a decision that will affect how you spend your time every day for the foreseeable future. Be the most informed person in the room about the choice you’re making. You are the master of your own destiny.

Hi! My name is Kath. I’m from Alaska, and I’m a vice president of product in San Francisco. For the past 10 years, I’ve taken all sorts of products from prototypes to launch day. Through my successes (and failures), I’ve developed a philosophy about how we make products shine. My process thrives on the delicate dance between data-driven design, business goals, and user feedback. Now I work at Vercel on making the Web fast. Say hi 👍😎.

More stories

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

Thank you! for subscribing