I ask three questions
When I'm interviewing for a job, these are the questions I ask
During my freshman year of college, I got invited to volunteer for the school’s welcome guide group. It was a crappy gig: the pay was a pizza party at some point, and you were on-call to give tours to prospective students and their parents. It was a mistake to volunteer for this group, but I did it nonetheless.
By the end of my freshman year, I was pretty disillusioned with college, mostly because I thought I’d made a big mistake. My parents had talked me out of my first choice (RIT) to go to a tiny Christian college in the middle of nowhere, and I was feeling depressed and frustrated. And yet, I was giving tours to high schoolers.
What struck me at this time is how bad the questions they’d ask were. The students would ask things like, “What’s the average class size?” and the parents would ask, “How’s the food?” Those questions ring in the back of my mind, and I’m convinced that they were only asked because they either made the asker feel like they were doing their due diligence or because they didn’t realize that there is no possibility of getting a response that would change their minds about the school. What am I going to say? “The food here is shit, and make sure to bring bottled water.”
And even if the food wasn’t great, is that really the thing that’s going to make you decide how to spend the next 4+ years of your life? No, not at all. The questions were useless filler and served no purpose except to make me miserable.
Years later, I interviewed for jobs that turned out to not be what I thought they were. And similarly, I interviewed folks for positions that they ended up leaving because it wasn’t what they thought it would be. And I realized it was the same problem: people don’t know how to ask questions. Almost everyone joins a job with the intention of being there for a while, and yet the questions they ask about the role/team/company are oftentimes useless for understanding what their experience might be like.
The top three questions I’ve heard from candidates during interviews that are resoundingly useless:
What’s the culture like?
If you don’t ask about something specific, you’re going to get a feel-good non-specific response.
What are the working hours? What’s on-call like?
Both of these things are (almost always) what the team makes them. On-call sucks if nobody puts effort into making on-call better. Working hours are strict if the team decides that working hours are important. It’s rarely the case that either of these things are bad because someone decided they should be bad.
What’s your favorite part about working there?
This tells you literally nothing. Your mileage will vary, and one single positive data point should never sway your decision-making.
In 2017, I developed a set of three questions that I think have helped me to understand the role, the team, and the company. These are the questions that I ask to the people interviewing me for a job. I want to share them with you after reading reading a former coworker’s post:
To be clear, these are questions that I ask while interviewing for a job. Not ones that I ask to candidates. And certainly, they’re not the only questions! They’re great conversation starters. Often, they reveal hesitations and little nuggets of information that can be worthwhile to pick at and peel back the layers on.
#1 - What is something you’ve done in your role that you’re the most proud of?
This is a bit of a softball question, I’ll admit. But it’s supposed to be! It lets your interviewer think about something that they’ve accomplished, which is more substantive than their “favorite thing about the company,” or whatever. Having something you’re proud of should be a real meat-and-potatoes sort of accomplishment.
The best answers are where the interviewer can talk about something that they got their hands dirty on and were able to fight for. This can give you signal about how hard it is to cut through bureaucracy or work cross-org. It may be worth asking followup questions about that: was it a challenge for bad reasons? Or just because the project was so substantive?
Weak answers are usually vague and don’t have much substance. I’ve talked with EMs who have said things like “it makes me really proud to work with my ICs and help them advance in their career.” And while I don’t doubt that brings them pride—or at least hopefully it does!—that’s also sort of the job. My expectation is that anyone that’s been with a company for more than a few months has at least something that they’ve done that they’re at least a little bit proud of that stands out from just showing up and doing the job.
Most importantly, this should be a question that the interviewer enjoys answering! At least for me, if there’s something I’m proud of, I love to tell people about it. I love getting asked questions about the things I’m proud of. If nothing else, assuming things are going well, this should be a positive way to set your interviewer up for the remaining two questions.
On the other hand, if your interviewer isn’t jazzed about answering this question, that’s something to talk about. I’ve heard a few answers to this where the interviewer did really good work that created real business impact within the company, but it created some organizational turmoil. Depending on what you’re looking for in a role, this could be a red flag, or it could be an indication of the sort of problem you’re looking to work on within a company. Either way, it’s high-signal.
#2 - What’s your biggest frustration day-to-day?
This is a juicy question because there’s only one way to give a vague, wishy-washy answer—and that’s to not answer the question. Everyone in every job on earth—even the most stress-free job—has something frustrating. If you asked, I’d bet the Dalai Lama gets frustrated that he can’t wear some comfy sneakers or maybe the guy that brings him his lunch makes some weird mouth noises or something. So if someone answers this with, “there’s not really anything that frustrates me,” they’re full of it.
I like this question because it tells you a few things. It’s kind of rare that you hear about frustrations that are big red flags. But it tells you a lot about the culture:
It hints at the themes of internal problems. Bad developer experience? Bureaucracy? Ineffective EMs or PMs?
How candid are they?
Folks who are reserved about problems are either trying to gloss over something potentially serious, or perhaps feel like they aren’t well-supported enough to actually call something a problem. A junior engineer might see something as annoying, but downplay it as not a big deal because they don’t have the experience (and by proxy: mentorship) to confidently call it an issue.
Folks who are way too candid about frustrations weird me out. They’re either on the cusp of quitting in spectacular fashion, or they are extremely transparent because all of the skeletons in the company closet aren’t really all that bad. Dial in on how that person is feeling and try to get a sense for their level of angst.
How deeply do they talk about the problem? “Test times are bad,” is a good signal in itself, but do they resist if you try to peel back the layers?
A great answer is where the interviewer can give you details and shows understanding (“We’ve been trying to bring test times down, but we haven’t invested in keeping our CI infra scaled appropriately, so there’s a lot of investment to get that into a good place as a prerequisite.”).
A bad answer is one where the interviewer is just salty, even if it’s not their fault (“We use Jenkins and it just sucks really bad.”).
It’s okay for someone to not know why something is bad or frustrating! But that gets back to their level of candor. They shouldn’t be afraid to admit they don’t know.
#3 - What’s the biggest thing you’ve broken?
This one usually catches most interviewers off-guard. Many of the folks that I ask this to smile or chuckle. That’s a good sign! If your interviewer can look back on things that went poorly with a sense of humor, that’s perhaps a sign that things aren’t all that bad in the company’s engineering culture.
For interviewers who haven’t been at the company for very long, there might not be an answer here. For the dozens of times I’ve asked this question, maybe one person didn’t have a solid answer because of their tenure. Instead, I asked them about incidents that they might have helped with or been adjacent to.
The ideal outcome for this question is 1) fun anecdote 2) we both laugh a little 3) I ask some followup questions about the incident to cover my bases. At this point, we’re usually out of time, we shake hands, and go our separate ways. I love to hear from the interviewers how breaking something turned into a learning opportunity, or how it was an unexpected milestone that helped with career growth. There’s lots of positive that can come out of a bad day.
The signal I’m really looking for is how problems are actually handled at the company. The same way companies parrot the phrases “agile development” and “metrics-driven,” you often find companies chanting “blameless postmortems!” but really miss the point of what the postmortem process is supposed to be for and misunderstand what blamelessness is.
As a quick aside, blamelessness doesn’t mean “we don’t name names,” it means, “we assume you’re acting with good intentions and doing good work, and we as a company could have done a better job of keeping you from shooting your foot off.” And part of that involves having conversations that are tough for folks that aren’t used to putting their bad days under a microscope. That is very much the crux: best practice for incident response has no understanding of people, it serves the engineering org. Engineering leaders are responsible for taking good things for engineering and making them good things for people.
A company might have the best incident process on paper, but it can still suck. The most by-the-book incident response can still feel bad to the person(s) that caused the problem. Feeling bad about incidents can, and does, lead to organizational fear, which slowly leads to a deep cultural rot that’s terribly hard to fix. I have a story about organizational fear!
In 2017 when I was interviewing for work after my fairly short stint at Uber, I had applied to work at Airbnb on a frameworks team. I asked each of my interviewers these three questions. When I got to this last question, one of the interviewers said something that was a huge red flag: everyone is afraid to touch the booking page.
The booking page, if you’ve never used Airbnb, is sort of the checkout flow for a listing. It’s where you book the trip. To paraphrase the person I was talking to1:
The booking page is full of tech debt, and the code isn’t great, and if you break it we stop making money.
The impression I got from the conversation that ensued was that nobody in the company had prioritized developer velocity or safety for that page in particular. Components like that, especially ones that are business-critical, start to turn into a perverse game of Jenga. Everyone wants to do as little as possible to avoid being The One Who Caused The Incident. Inevitably, you end up with a brittle product that’s poorly-understood supporting a huge chunk of your business. A healthy org, on the other hand, would have said, “It’s not broken now, but we value it not being broken in the future, so we’ll make sure it’s less dangerous to work with.”
For what it’s worth, I didn’t end up taking the job with Airbnb. They made me an offer (actually the best offer of the companies I’d applied at), and I asked to meet the team. They invited me to the HQ to have lunch with the team, and I’ve never since encountered such an unhappy, unengaged group of folks in my career. Their roadmap seemed to just be “fix problems that other teams caused” and to try not to get further underwater. Which, as a DX-focused team, was not at all what I wanted to hear. I hope that they’ve since been empowered to be more impactful, and now work on what they would rather be working on.
Why it matters and what you can do differently
I’ve talked to so many people about their jobs, especially people who are unhappy with their jobs. Without fail, one of the biggest reasons that folks are dissatisfied is that the company/role/team/culture didn’t match their expectations.
And who could blame them! Being an engineer (or doing any serious profession) takes skills. And then on top of that, there are skills to master for interviewing. And even if you’re good at what you do and you’re good at proving you’re right for the company, there are additional, separate skills for knowing whether the company is right for you. And nobody teaches any of this.
Whether you use my questions, or whether you come up with your own questions, is a matter of personal taste. But everyone should have some tools for evaluating jobs. Don’t ask garbage questions like the prospective college students I gave tours to! Put your questions to work!
Thinking on questions
The first step is meditating on the things you actually care about in a role and company. Be specific. “It has a good company culture” isn’t a good response here. What about the company culture? It feels like a small company? It’s fast-paced? It’s slow-paced? It celebrates little wins? It recognizes employees for hard work? Get really stuck in on the little things that you actually care about that, and craft your questions around those.
From there, it’s a matter of trying to build a question that gives you signal that you want. In my experience, good questions don’t have an easy answer. Questions that prompt the interviewer to answer with a story work great. Ask yourself, “If I got a short answer or one light on details, would that be a red flag?” And if the answer is “Yes,” it’s likely a good question.
Practice asking the questions. Ask your coworkers. Ask your friends. The greater the variety of responses you can get, the better you can understand what signals you can extract. What kinds of followup questions can you ask? Take notes and read them later; you’ll often have insights well after the fact after you’ve had some time to chew on the responses.
And last, iterate on your questions. My three didn’t start as these questions. Sometimes questions you thought were good actually kind of stink. And sometimes they’re on the right path but they give you signals that don’t help as much as you thought. Iterate until you feel like you can really get a feel for the right vibes from your interviewers.
It has, after all, been about six years and I’m pulling this from my memory.