Many candidates approach interviews like they approach oral exams at school: a stressful, one-sided evaluation of their knowledge, their skills, and perhaps even their worth as a human being. This is misguided and detrimental: on the one hand, this tends to generate a lot more stress than is warranted, and on the other hand, it prevents the candidate from evaluating the interviewer.

In fact, an interview process should go both ways. It's more akin to dating: sure, you want to put your best foot forward, and you are, to some extent, being judged for adequacy, but you should also be judging the other party and how good a fit they are for you. Ultimately, the goal is for both parties to evaluate whether there is a match; it's not about judging the other party's "worth" on some arbitrary, absolute scale, it's really about evaluating mutual fitness for a specific role in a specific context.

I've done my fair share of interviews, on both sides. Most recently, my team is currently hiring, which means I've been doing a couple interviews a week for the past few months. We tend to be very conservative in our decisions, and we're not in a rush, so it's taking some time. I always make sure to save some time for candidates to ask me questions towards the end of an interview, and I have been a bit disappointed by the questions I get, so I decided to write some thoughts and advice on the subject.

Things to avoid

Some candidates tell me their questions have already been answered by other people in other interviews. That's pretty bad: it signals either a lack of interest (maybe they don't actually have any question), a lack of understanding of the process (they're not aware they should be evaluating the company), or a lack of critical thinking skills (they don't think there's any value in hearing different answers). That last part is critical: as an interviewer, I want to hire people who can think, criticize, and value different perspectives. More importantly, I have found that, as a candidate, asking the same questions in multiple interviews is a great way to quickly identify dysfunctional workplaces. You learn a lot if the answers do not match.

If you've never been on the other side of the interview process, and you're concerned about "being caught" asking the same questions to multiple interviewers, don't be. Even if you did somehow interview for a company where people discuss interviews in such details that they end up comparing notes on which questions you asked, if they hold that against you, you probably don't want to work there.

Some candidates just tell me point blank that they don't have any questions. This is obviously not great either: on the one hand, you're squandering an opportunity to learn more about how well the company fits you; on the other hand, it doesn't send a very strong signal that you're serious about the job.

Finally, in the category of things to avoid, there are questions that can be answered by looking at the company website ("what's your mission?", "what are your values?", etc.), which signal you didn't bother to do that, and questions that are too vague to be answered, like "what is your typical day like?".

You should ask questions that are designed to:

• Be easy to answer, and
• Yield information that will help you decide whether that workplace is a good fit.

You may not care about the same things I do, so my questions may not work for you. But think about what your questions should be, and don't be afraid to ask them at every single interview, so you can compare answers. Also, tweak them over time to get the best responses.

Here are three questions I like to ask in interviews, and why. Hopefully, seeing my reasoning will help you come up with your own. Or, if you like these ones, feel free to steal them.

How do you know what to work on?

This question should be easy to answer, as people have to decide what to work on every day (whether that day happens to be typical or not). This question should let you know whether the company uses any specific methodology (Scrum, Kanban, etc.), and if you're carefully listening to the answer, how much freedom you may have in that job. This should get you the answer to "is your boss a micromanager?" without having to ask, and without your interviewer(s) having to explicitly state it. It would also tell you how often priorities change, and how that happens, as well as roughly how much time the whole decision process takes.

If you care about that sort of thing, the ensuing discussion should also tell you how much design is done before work starts, and how priorties are actually determined (client demands, data-driven, some guy in the product department fancies it, etc.).

You may also use that discussion to signal that you're willing to work within the system they already have. This is not the time to tell them it's a bad one.

Once it "works on my machine", how does it get to customers and how long does that take? Please describe every step.

This question will tell you about code review, CI, testing, and deployment. It should also raise the question of pair programming, if that's something the company is doing and it somehow hasn't come up yet. You'll discover how often code gets shipped to customers, in what form, and with a little bit of digging, what happens to your code afterward, such as whether there's any kind of monitoring for which features actually get used.

This should also be an instant reveal of where the company sits on the devops axis, if that's something you're interested in. Questions like who gets called in the middle of the night when production goes down should also come up here.

Whether you get your motivation from the impact your code has on your users, or you'd rather stay focused on the theoretical beauty of your algorithms, this will tell you where the position you're applying for actually sits on that spectrum.

Is there any remaining concern I can address?

As an interviewer, I sometimes end an interview with unanswered questions. Maybe we ran out of time; maybe I decided I would rather give the candidate a chance to ask their questions. There may be some technical area I haven't covered, or something the candidate said that bothers me because it's not quite wrong but it's not really correct either, or the candidate gives me the impression that what they want is different from what the position can offer.

Any such question that stays open in the interviewer's mind is ultimately going to play against the candidate. Not necessarily by much, and it may not be the deciding factor, but if you still have a couple minutes at the end of your interview, I think this is a good way to wrap up.

If nothing else, if the interviewer does have some unaddressed questions after that, they'll blame themselves for not asking, which is always better than them blaming you.