How to interview your interviewers

I recently had the utterly terrifying experience of giving a guest lecture to an MIT computer science class on technical communication/public speaking. To my relief, things went quite well, and it was awesome to peel back the curtain a bit and give students a perspective on what actually happens inside companies when they’re hiring.

Before my talk, I sent out a survey to see which job-hunt related topics were most interesting, and in addition to the usual stuff about technical interviewing and negotiation, one of the more sought-after topics was how to vet companies during the interview process.

Doing this well is really hard. There’s not much time, you don’t feel like you have much power, and people tend to respond to your questions with rehearsed platitudes. To make things easier, I’ve compiled a list of very specific questions you can ask, verbatim. The purpose of these questions is to be really specific/situational so you can quickly get past the platitudes and make shit get real.

Note that:

  • It’s a good idea to ask some subset of your interviewers the same questions to see how their answers differ… because the devil is in the deltas.
  • Don’t waste precious time talking about benefits/salary/vacations/process during interviews – you can get those answers later from HR or whatever.
  • Bolded questions are ones I particularly enjoy or find non-obvious.

Without further ado, the questions, broken up by topic, are below. Please use some subset of them at your leisure, and tell me if they helped you! Oh, and maybe don’t say “fuck” in interviews unless you can own it.

Team caliber/culture

  • How long have you been here?
  • When you were last interviewing, what were some of your other options, and what made you choose this company?
  • What is the most fulfilling/exciting/technically complex project that you’ve worked on here so far?
  • What is something you wish were different about your job?
  • How often have you moved teams? What made you join the team you’re on right now? If you wanted to move teams, what would need to happen?
  • (If the company is a startup) When’s the last time you interacted with a founder? What was it regarding? Generally how involved are the founders in the day-to-day?


  • What does a typical day look like?
    EDIT: What did your day look like yesterday? Was that pretty typical? If not, what does a typical day look like?
  • What is your stack?
  • What is the rationale for/story behind this specific stack?
  • How often do you add new tools to the mix?
  • Do you tend to roll your own solutions more often or rely on third party tools? What’s the rationale in a specific case?
  • What kind of test coverage do you have?
  • Would you describe your engineering culture as more pragmatic or more theoretical?
  • What portion of your time is spent working on new stuff rather than iterating on existing stuff?
  • How long are your release cycles?
  • What’s been the worst technical fuckup that’s happened in the recent past? How did you guys deal with it? What changes were implemented afterwards to make sure it didn’t happen again?
  • What is the most costly technical decision made early on that the company is living with now?
  • If possible, also ask for the opportunity to view the source. This may be tricky, it may involve signing some stuff, and you may not be able to do it, but it doesn’t hurt to ask. The best thing, if you can, is to just spend a few days working onsite as a contractor. It’s hard to make time, but boy does that give you some valuable perspective. I’ve had candidates on the brink of accepting offers rapidly drop out after seeing that the day-to-day/codebase/team dynamic was nothing like they expected. And I’ve had people who weren’t sold at all end up loving a place because they got to spend some time with the team.

Product voice/visibility into business side

  • What are you working on right now? Why/how did that become the thing that you ended up working on?
  • If you had an idea for something new to build, what would you have to do to make it happen?
  • What is some of the more meaty new stuff that got pushed in the last release? Where did the idea for that feature originate? Where do product ideas generally come from?
  • Who are the other major players in this space? What do we have that they don’t?
    The answer to this one can be useful for getting some idea of what the space looks like and what traction the company in question might have. Most importantly, though, it’ll give you some insight into whether the people at the company care about the product and the business side of things or not and how much they’ve thought about stuff like this.


  • How long does the average engineer stay at the company?
  • Why have the last few people left?


  • How many former employees have gone on to found startups?
  • Was their leaving to do so was generally looked on favorably?
  • How does company culture encourage entrepreneurship? Specific examples?

18 Responses to “How to interview your interviewers”

  1. Dejay Clayton

    Alternatively, you can ask the same types of questions that uninventive interviewers tend to ask. What are some weaknesses this organization has? Tell me about a time this organization had to resolve a conflict. Explain how the organization balances competing priorities. What are some ways this organization has solved problems when faced with a lack of resources?

  2. Rudolf

    Great questions, I wish I had asked about the release cycle and test coverage at all my previous interviews. I find those two things to be the most telling. If your release cycle is 2 weeks, there might be a problem. If it’s 2 months, there’s definitely a problem. If your test coverage is under 70% there’s a problem.

  3. Joel

    Thanks so much for this, Aline! I’m terrible at this part of the interview process. I’ve used some of these questions before (which makes me feel a little better), but there are plenty that I’ve never even considered.

  4. Igor Naverniouk

    Great post. I’m a hiring manager at a large Silicon Valley company. If I’m interviewing you, and you ask any of these questions, your chances of getting hired go up substantially. Besides your technical skills, some of the things we look for are communication skills, culture fit, and experience. So if you ask about technical debt, switching teams, and attrition — that tells me that you are able to think beyond the next line of code, and that you probably have experience working on a real team.

    • aline

      Igor, that’s great to hear! If there are other questions I ought to include/questions that you’ve heard before that have raised your esteem of your interviewees, please lmk.

  5. An Engineer

    An interviewee once asked me “What should I do to succeed in this role?” which gave me a good opportunity to tell them my perspective on the job and culture, beyond the posted description.

  6. CJ

    Asking to see the source code is a great idea. Or to be able tow work as a contractor for a couple days. I recently went to a job and by the 3rd day of being in the code I realized I had made a huge mistake. Spent the next month looking for a new job. It was a good company but horrible code base and lots of technical debt that they had no intention of refactoring or rewriting. It was a horrible month, I dreaded getting up in the morning and couldn’t sleep at night because I would dream I was at work.

  7. Jeff Joltes

    I find company/team culture is often one of the most important things to consider when vetting a company. I always ask how many hours th average engineer works on a typical week, an during crunch time. Do engineers work on call? How often do they work on weekends? Is it atypical for engineers to b called while out on holiday? Many of these questions are red flags to me. Work life balance is critical if you want to have a life outside work (seems silly I know, but I didn’t consider this at all when interviewing straight out of school).
    Finally, I always ask what we’re the circumstances surrounding the last engineer who was let go.


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>