Questions to ask at the end of a technical interview

It takes people off-guard and sometimes you get a really authentic look at the problems in the company. I think people are more willing to be frank with the question because it's asking for their insight, even if it comes at the expense of the company's reputation.

When my future manager told me that he wished the company was "less tribal", I should've listened. The politics between teams was insane.

Usually you get good information that you can deduce a lot from. It's simple, it's polite, it's opens a whole conversation about whatever you want to about next, etc.

> This allows your to figure out how up-to-date the firm is with technology. Up-to-date here is entirely your definition :)

What? The question is fine, but not at all for that reason. This question allows you to figure out whether you can provide immediate value, whether it'll present a challenge you wish to embrace, or whether it'll present a challenge you wish not to embrace. It'll also tell you whether you think their stack was chosen based on whether it helps address the problems at hand or based on whether it's the "new hotness" or, as this write-up puts it, "up-to-date"

The obvious corollary would be to ask why that stack was chosen for the products and services the firm offers or for those which you'll be working on.

I am more impressed when people ask about overall company direction and current challenges. It demonstrates to me that they're interested in the company as a whole, where it is going, and how they see themselves fitting in and contributing.

"Do you conduct regular peer reviews of code and documentation?"

"Do you have a bug tracking system?"

I like this because "fulfilling" means different things to different people. Some folks would deem the opportunity to work on hard technical challenges as fulfilling, whereas for some it's simply a positive impact on the customer and/or other developers (agnostic of whether the solution was simple or complex.)

This also helps you gauge the quality of problems the team is working on, and how they gauge said problems. With the added dimension of time (i.e. 6-12 months) you get a sense of how recent or old are the projects that they're about to discuss. I wouldn't put much stock in something too recent (ex: something they started 2 weeks ago) but would also be suspicious if they mention projects that are 1yr+ old. More than once in my career have I run into issues when my definition of "fun/fulfilling/cool" was widely different from my boss's. Getting a heads up on this for me is critical when it comes to evaluating which team to join.

It isn't at the end, but a few times I've asked mid-interview for one of the team members to give me feedback as though it were for a peer review.

I've been known to ask what an interviewer's favorite NPR show is. It's great if the interview is at a location I'd have to relocate to and they answer with a show carried locally I've never heard. That's how I learned about "Says You" (which is the correct answer to my question, with points for effort if it's "Wait, Wait Don't Tell Me" or "Prairie Home Companion").

To get a half decent answer on some of these would eat a lot of time. I tend to ask these DURING the interview and like to spend the end of the interview trying to get the know the developer on a personal level to establish how they fit into the culture of the team.

This will get their personal insight on how they see the company. However, I am not too sure if the answer is always 100% truthful.