When I interview for a new software engineering job, I’m usually participating in two interviews at once. The company is interviewing me, and I am interviewing the company. Both interviews are equally important to me.

Sometimes I am nervous about appearing over confident in interviews, but getting answers to the questions I enumerate below is very important to me. Getting a job offer feels great, but how will it feel 6 weeks from now when you realize this new job isn’t a good fit for you after all?

Questions I ask the software engineers

Most interviewers will ask if you have any questions, usually toward the end of the interview. For professional courtesy, I make it clear at the beginning of the interview that I’ll have several questions to ask. Often, the interviewer prefers to answer these at the beginning, and I prefer that too, because it helps me give better responses when it’s my turn to answer questions.

1. How do you know what to work on each day?

The purpose of this question is to identify dysfunction. I want to get answers from 2 or 3 engineers at least. If a company says they follow a certain development process, but the engineers don’t talk about the process, that’s a sign of dysfunction. If you get different answers from different engineers, that’s another sign of dysfunction.

In a high quality team, I get consistent answers to this question. Every developer knows the process, and the process is light weight enough to be supportive of the engineers rather than oppressive to them.

Example of a good answer (there are many others): “We do two-week sprints wherein each engineer commits to a set of features and bug fixes to deliver. Each day we report progress on our commitments to each other. We have an amazing product manager who interfaces with customers to prioritize the features and bug fixes.”

Example of a bad answer (there are many others): “I come into the office in the morning and resume working on the previous day’s tasks. Most days, I get interrupted with an emergency. I work on whatever is most important each day.”

2. What do you use for revision control?

Good tooling is a strong indicator of a good team. If a team is using a 10-year old revision control system, they are probably using a bunch of other outdated tools. Furthermore, they probably don’t value efficiency gains that can be achieved by good tooling.

Here are the kinds of answers I get to this question:

No revision control I almost never hear this answer, but if you do, run away from the job.

CVS, RCS, Visual Source Safe Old, outdated tools. This team probably has serious problems.

Subversion Not as bad as CVS, but the team has not seen the light of modern revision control systems.

Git, Mercurial, Darcs, Bit Keeper, Bazaar. Any of these is a satisfactory answer for me.

3. What do you like about working here?

Strong answer: I get a lot of satisfaction from the work I do.
Strong answer: We have a lot of fun at work.
Strong answer: I love working with really smart co-workers.
Strong answer: Management really respects engineering.

The more good answers the better. I don’t have to get all these answers, and some people are not naturally “gushy”, so this one can be a tough call.

If I hear these kinds of answers, and very few from the strong answer list, I get nervous:

Weak answer: It’s a steady job.
Weak answer: I don’t have to work very hard.
Weak answer: There is not a lot of pressure to deliver.
Weak answer: (silence)

I don’t automatically consider it a bad company if I hear those weak answers, but if those are the only answers, I definitely look elsewhere.

4. Do you write unit tests?

If a team gets excited when I ask about unit testing, that is a very good sign. If they come up with excuses for why they don’t write tests, especially bad excuses (we don’t have time), that is a very bad sign for me.

If the engineers tell me they write unit tests, and they are able to tell me metrics about their tests, such as how long they take to run, how many they have, and about their code coverage metrics, that is very attractive to me.

If I get the sense that I will be working in a large, old, untested codebase at this company, I am very unlikely to work with them.

I give bonus points for doing test driven development, but I penalize for dogma. If the engineers tell me that they usually write tests first, but they aren’t religious about it, that’s a good sign to me. This tells me they value testing, but they realize that every rule has an exception, and they are pragmatic about it. Teams who choose a methodology such as TDD but don’t tailor it to their team are generally more dogmatic than I like. However, teams who throw out ideas like TDD without ever trying them are equally dogmatic in my view. This is doubly true if they make unsubstantiated assertions about unit testing without having evidence to back them up.

Several follow-on questions I ask to get a feel for their testing culture:

• How many integration tests do you have vs. unit tests? (do they even know the difference)
• Do you have acceptance tests
• What testing framework(s) do you use?

5. Do you have continuous integration?

The best software development teams I know use tools like Jenkins, Travis, and Buildbot. If the team has no continuous integration, I try to gauge whether they are familiar with the concept at all. If they aren’t, this is a bad sign in my experience. Having a continuous integration system means that the team probably believes in automation, which is usually a very good sign in my experience.

6. What do you measure?

This is an open-ended question meant to find out if the team has put effort into measuring aspects of their software. For web development teams, the answers tend to focus on performance metrics like server response times, request throughput, and client-side responsiveness. But the discussion can go to things like number of users who speak different languages, browser breakdown, cache hit/miss rates, and a myriad of other topics. If the team hasn’t taken the time to measure any of these things, it can be an indicator that they don’t use real data to inform their decisions. They may be premature optimizers. I value a team that uses real, measured data to make decisions, especially about performance, but it applies to so many things.

Other sub-topics to which this question can lead:

• How long do your builds take? Are you making them faster?
• How long do your unit tests take to run?
• About how many lines of code do you have? (this isn’t a terribly useful number, but I like teams who know data about their code)
• How many bugs do you have in your bug tracker?
• How long do your bugs take to fix (min/max/typical)?

If the interviewer even knows answers to many of these questions, it’s a good sign that the team is high quality. If they have no idea why they would even care about any of these measurements, it could be a negative indicator.

7. How do you find and fix bugs?

A strong team usually has dedicated testers. A really strong team has impressive test automation. Some teams are too small for either of these things, but that doesn’t necessarily mean they are a bad team. When I ask this question, I’m trying to get a feel for their process. Is their hair always on fire because bugs come flying in? Do they have a sane process for finding bugs? Do they rely on users to find bugs, or do they try to ship bug-free software (as much as is possible anyway)?

This usually leads to these sub-topics:

• How do you prioritize your bugs?
• What bug tracker do you use? (and what do you hate about it)
• What bug trackers have you used in the past? (and what do you hate about them)
• Do you use Excel to track bugs? (nooo)

8. What collaboration tools do you use?

In my experience, high functioning teams use lots of collaboration tools. They often use chat services (IRC, HipChat, Jabber), code review services (Gerrit), and of course, the venerable-but-showing-its-age Email. I am looking for indicators that each developer knows what the other developers are doing. I’m not looking for insane levels of detail, but more for a general awareness. Also, I like to see cool integrations with collaboration tools. The simplest example is an automatic email sent any time there’s an automated build failure. Another example for web-dev teams is automated error logging services that notify the team’s chat room when serious errors occur, or when key metrics cross a certain threshold. Collaboration integrations are usually pretty easy to set up, and a team who has taken the time to do so shows promising vision.

9. What frameworks do you use?

I like to hear that teams are using the latest and greatest frameworks in their development. If they are building a UI using Motif, I usually am not interested. I am especially happy to see that teams have made contributions to open source projects that they use. Also, if the team is reinventing the wheel rather than using readily available tools to help them build their product, I get nervous.

10. When can we pair?

I’ve never actually done this, but my friend has. I think it’s a fantastic idea. If you want to learn almost anything about the team, go work with them for a half day. It might require you to sign an NDA. If the team is even willing to consider this idea, I think it’s a very good sign.

Questions I ask managers

1. When was the last time you wrote code?

I like managers with a strong technical background. No offense to my MBA friends, but I’ve found the managers I really like are those who have done what I do.

2. How did you become a manager?

I like managers who chose to become a manager because they truly enjoy it and have a knack for it, rather than being forced into it. I also like it when managers seem to be focused on serving their team. My favorite managers are those who focus on making life better for their team, rather than “managing up”. They see themselves as a helper and protector for their team.

3. How do your engineers know what to work on each day?

Since I ask the engineers this same question, I like to compare the manager’s answer to see if they match. If they don’t match, it can mean there’s dysfunction. The worst kind of dysfunction is unrecognized dysfunction. I believe it’s the manager’s job to identify disparity like this and fix it.

4. What is your team’s biggest challenge right now?

They usually answer that it’s a shortage of staff. Because this is a common and obvious answer (they are hiring after all), I like to ask for their second biggest challenge. I’m looking for red flags like slipping schedules, product quality problems, and interpersonal drama. You’ll know the red flags when you see them. Every team has problems, so the answers you get will depend on several factors:

• The manager’s awareness of problems
• The manager’s willingness to be honest with you
• The seriousness of the problems on the team

5. How do you measure your team members’ individual performance?

A clueful manager will have a good technique for doing this. The best managers will carefully gather feedback from the whole team when assessing an individual team member’s performance. A bad manager will simply make a call based on their own observations, without consulting the team.

6. Do you do annual performance reviews?

I like to work for managers who value giving feedback and helping their team members improve.

7. Do you do annual salary increases?

I like to know that my compensation will be adjusted to match my contribution to the company, and that we’ll take an official look at it at least once a year. For companies where it applies, I like to ask about equity. Will you give me stock options? Will you give me more stock options every year?

Questions I ask company leadership

I don’t always get to talk to the company’s senior leadership, especially for larger companies, but when I do, I take it as an opportunity to assess the company’s financial viability. I’m not really qualified to do this, but there are some obvious problems that I can sometimes discover in an interview. Also, I like to know what the top-down culture is like, because this information can tell me how the company values its engineers, both positively and negatively.

1. How are you funded?

I’m trying to gain insight into the money behind the company. If they are funded by venture capital, private equity, public stock, or self funded via revenue, I want to know it. Often I can figure this out before the interview pretty easily, but company leadership will often add insights that I can’t find via Google.

2. Are you profitable?

If profitable, great! If not profitable, what’s your plan for becoming profitable? Some startups have a plan for this, while others are looking for an exit via acquisition or IPO. Whatever the case, I want to know. Sub-topics that can come from this question:

• Historical revenue for the past few quarters/years
• Risks to profitability like competition, surprise expenses, and surprise revenue shortfalls

3. What is your opinion on outsourcing?

I want to know if the job I’m applying for is likely to get outsourced in the future, or if the job could turn into a position managing outsourced engineers.

4. Tell me about the company culture.

This is another question I use to reconcile the engineers’ perspective against leadership’s perspective. I’m looking for discrepancies as a sign of dysfunction, and I see consistency as a sign of, well, consistency. I want to know if senior leadership is out of touch with the in-the-trenches employees. I also want to see if the leadership has solid vision that is well communicated. My favorite companies to work for have a strong, shared vision.

5. What assurance do you have that this company will be successful?

With this question I’m looking for real evidence, not just marketing hype. If senior leadership gives me actual numbers, like revenue, market size, and capitalization, that is a good sign. Also, if I can verify this information from other sources, that is an even better sign. On the other hand, the numbers may indicate something very bad, like a one-month runway with no funding on the horizon.

6. Tell me about your reporting structure.

For me, the best answer to this question is a simple one. If the person can draw a simple org chart that explains the reporting structure, I am satisfied. If they start talking about a matrix, I get nervous.

Conclusion

Interviews are bidirectional. Make sure you get everything out of the experience you need to know to make an informed decision if you are fortunate enough to get an offer. Good luck!