Use The Interview

“So, do you have any questions for us?”

They asked me this question at the end of many interviews in my young software development career. I’m ashamed to say that I answered it with “no” a few times.

They shouldn’t have to ask you this question. You should use the interview to learn about them as much as they use it to learn about you. Not just at the end, but from minute one.

The software industry is fraught with undesirable employment situations. How are you going to avoid them? You need to do your homework. The interview is a big part of that. It’s your opportunity to get information directly from a team you’re thinking about working with. You should get as much information out of it as you can. (You should also be aware of the source, of course, of course.)

I’ve been thinking about questions to ask potential clients/employers during an interview to get a good idea what the work will be like.

What are some areas of improvement for your team? What are you doing to address them?

This is important on a few levels. On the surface, you want to know what this team you might be joining is capable of and what they struggle with. Maybe their answer to this question will give you a chance to say “I can help you with that.” That’s a sign of a good fit for both parties.

A little deeper: Knowing the kinds of problems they’re thinking about will tell you a lot about what level the team is working at. If you’re interviewing for what they’re calling a junior dev gig and they tell you their team is struggling with problems you’d consider trivial, that’s a sign that either the gig is not for you or that you should start angling for a more senior role.

Deeper still: You want to work with people who are self aware and humble. People who know what they don’t know and aren’t afraid to admit when they don’t know.

What are some areas of improvement for you individually? What are you doing to address them?

See previous question. Also, for an individual, it’s helpful to know what role they play on a team for context when you hear their answer to this question.

Have you ever had to deal with a toxic team member? How did/would you handle that situation?

I’d watch their reactions closely when asking this question. They might give away the presence of a toxic team member on the team you’re about to sign up for. Or you might see signs of good camaraderie. Their answer should at least give you some idea of the interviewers’ communication skills and emotional intelligence.

What happens here when people make a mistake?

I wouldn’t expect to hear that people are treated poorly when they screw up, even if it’s true. I would watch them closely as they answer this question to get a sense of that.

What I want to hear here is that mistakes are addressed rationally and without animosity. “What went wrong? How can we make sure it doesn’t happen again?” (Bonus points for five whys or similar.)

How much up-front or long-term planning do you do?

Do they try to plan the whole project up front and then execute it? Do they do this with features? Do they work in iterations? How long are the iterations?

How often do requirements change while work is in progress?

When this happens, how is this addressed? What happens if development is almost done on a feature and the requirements change substantially?

How frequently does the team interact with the customers?

Do they try to minimize interaction with clients/stakeholders, or do they encourage it? How early/often do they deliver working software to customers for review?

How frequently does the team interact with users?

(If customers and users are different sets of people.) How often do users see work-in-progress? How does the team make sure users want what they’re building?

How closely does your team collaborate?

As a feature gets defined, designed, developed and tested, does that process involve siloed work with handoffs, or is everyone involved from beginning to end? Or something in between? Do the programmers pair?

What forms of communication do your team prefer?

Is the team co-located? If not, what kind of remote collaboration tools do they use? What means of communication are most used on the team? (Examples: Meetings, phone/Skype conversations, impromptu face-to-face chats, email, IM, chat, etc)

How does the business evaluate the progress and success of your team?

Do projects begin with fixed budgets? Fixed scopes? Fixed timelines? Which of those does the business tend to be flexible about when things get tight?

Do you practice continuous integration?

How about continuous deployment? Do they run regression tests regularly? Do they run a nightly build? Do they do a build with every commit? How often are commits made?

Do you value good software design?

What does that even mean to them? Do they have unit tests? How have unit tests affected their software designs? Do they write tests first? How frequently do they evaluate the design? What form does that evaluation take?

Do you ever ship prototype code?

Yuck. This happens when quality isn’t valued. That could mean the team doesn’t value it, or that the organization around them doesn’t, and the team caves to pressure to ship ship ship.