How to interview your interviewers

For the last few semesters, I’ve had the distinct pleasure of guest-lecturing MIT’s required technical communication class for computer science majors.

My lecture focuses pretty heavily on two of the most important (and daunting) communication challenges of one’s technical career: interviewing and negotiating. I cover one other thing, largely because it’s something students ask about over and over again: How do I vet the companies I’m talking to during the interview process… and make sure that I end up in the right place?

One of my favorite things about giving this lecture is peeling back the curtain so students can see what really happens inside of companies when they’re hiring (spoiler: we’re all making it up as we go along, and it’s mostly a haphazard rat’s nest held together with chewing gum and staples).

And, as such, I thought it’d be cool to give you some of the same tools. Tools that will help you peak behind the curtain and evaluate companies you’re talking to in the same way they’re evaluating you.

Now, getting meaningful information about a company during the interview process is 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.

So to make things easier, I’ve compiled a list of questions you can ask, verbatim. The purpose of these questions is to be specific/situational so you can quickly get past the platitudes and cut to the chase.

How to best consume this list

A few things to keep in mind as you go through the list below:

• Note that a lot of the questions skew specific. This is on purpose. Asking “What did your day look like yesterday?” will get you much more rich info than “What does a typical day look like?”
• 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 somewhere else.
• Bolded questions are ones I particularly enjoy or find non-obvious.
• Italicized notes, where applicable, are my thoughts on how or why to ask the question.

Without further ado, the list of questions, broken up by topic, is below. Please use them at your leisure, and tell me if they helped you!

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?

Engineering

• What did your day look like yesterday? Was that pretty typical? If not, what was different about it?
• 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 screw up 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?
• Can I view the source code? This may be tricky because it may involve signing legal agreements. While you may not be able to be view the source in the end, 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 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 question can be useful for getting an idea of what the market looks like and what traction the company in question might have. Most importantly, though, it’ll give you 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 such matters.

Attrition

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

Entrepreneurship

• How many former employees have gone on to found startups?
• Was their leaving to found a startup generally looked on favorably?
• When’s the last time a founder or manager encouraged someone to go try something entirely new (whether it fit in well with the current core product or not)?

Want to become awesome at technical interviews and land your next job in the process? Join interviewing.io!