How to tell if a software company encourages/allows quality work, during the interview process?

Question

The book Peopleware has this to say about quality:

... managers tend to think of quality as just another attribute of the product, something that may be supplied in varying degrees according to the needs of the marketplace. It’s like the chocolate sauce you pour onto a homemade sundae: more for people who want more, and less for people who want less.

The builders’ view of quality, on the other hand, is very different. Since their self-esteem is strongly tied to the quality of the product, they tend to impose quality standards of their own. The minimum that will satisfy them is more or less the best quality they have achieved in the past.

My experience of the way I feel when working on a software product fits well with this description.

Peopleware further says that:

Quality, far beyond that required by the end user, is a means to higher productivity.

I include the second quote just to show that it is a potentially defensible position that high quality software will not put a software shop out of business, even though the opposite view seems to be oddly prevalent. Arguing this point is not the goal of this question, however.

I would also like to present some examples of other questions on this site that indicate that engineers caring about the quality of what they work on is not an uncommon occurrence:

• Professionalism: protecting code quality
• My work can affect peoples safety, and my employer prefers rapid development over quality?
• How can I fulfill my personal quality-demanding in a low-quality environment [closed]
• Perception of quality by management [closed]

With that background out of the way, my question is how can I identify that a software company provides an environment where quality software development work can be done? I am interested in effective methods for determining this at any/all stages from finding a job ad to the end of the interview process, inclusive.

Here's some ideas I was able to come up with myself, along with reasons I don't think they are sufficient, or necessarily even predictive at all:

• Looking for descriptions of quality work being valued in the job description and/or the company's website. I think it's quite easy for the word quality to end up on the marketing material without anything in particular to back it up. One can imagine someone finding "quality" as a synonym for "good" in a thesaurus.

• Asking about software quality during the initial phone screen. Unless the company is very small, in terms of employee count, I would not expect the person doing the phone screen to have any idea about this. I would guess they would say something like "of course!", or perhaps pass that on as a question to someone else. Asking about that here may also affect the chances of getting to the next stage of the interview process.

• Directly asking whether quality work is allowed/encouraged during a technical interview. While this interview stage has the greatest chance of being with someone who would know the answer to the question, those same people have the most motivation to say something besides that answer! Some reasons I can think of include: They have not faced the uncomfortable truth of the quality of the code. They may be simply embarrassed about it. Finally, they may just have only ever seen low quality code, and so may think they work at a reasonably high quality place, despite that not being the case. Also, many technical interviews do not leave much room for questions like this.

• Directly asking whether quality work is allowed/encouraged during a follow up interview, if one happens. Since these only happen sometimes, it doesn't make sense to solely rely on them as a diagnostic. Even if one was willing to rely on that, these meetings are often with folks who work far away from the actual software development, even if they were closer on the past.

• Picking up on subtle context clues during the previously described stages. This seems like the best way in this list, but it seems far from accurate to me.

Are there other options that I have not considered here? Are one or more of the options that I listed above more effective than I currently think?

_{And just to get ahead of some likely comments, this is a highly unbalanced binary classification problem, but I'm looking for something more accurate than the sadly quite accurate baseline of "assume quality is not permitted".}

Answer 1

how can I identify that a software company provides an environment where quality software development work can be done?

You ask to speak with future peers and talk with them. And you ask them about things you think lead to "quality work" as you personally define it.

For example, if you think it's important for you to have time to refactor old code, ask something like "Are you given a chance to refactor code that you think needs improvement?"

Whenever I interview, I ask to speak to at least a few of my peers. I have always been granted time to do that. I always ask questions like "What's it like to work here?", "How do you like working for [hiring manager]?", etc. Then I listen. I often get great insight that way.

Answer 2

Pick any subset of qualities from The Joel Test that you feel are important. When they ask during the interview if you have questions for them, this is a good chance to ask from this list.

Some notable adjustments to make The Joel Test relevant for 2022.

Do you make daily builds?

Replace with "do you have continual integration?"

Do you have testers?

Replace with "do engineers on this team implement both unit tests and automated integration tests?"

Answer 3

You want to work somewhere with a good culture and that has a high performing engineering organization. That's the sort of place that allows quality work.

I don't think places with bad cultures are capable of producing good engineering organizations. Here's a question about general company culture. For places with no obvious cultural red flags:

• Ask how decisions are made. Are the tech and process decisions for a team made in the team and made on the basis of the strength of the ideas?
• Try and figure out how much they value learning and will invest in your growth. For example, a company that sends you to conferences probably values and expects a higher standard craftsmanship than a place that doesn't.

You can also check for terrible indicators for how the organization thinks of software development, like outsourcing.

Companies with poor quality code won't be able to do the things that effective engineering organizations can. Are they able to?:

• Keep up to date with the latest frameworks and tech .... Is there anything wrong with old tech? Perhaps not. Is there something wrong with teams that get stuck on old tech? Very possibly yes.
• Release often. Build, release and setup infrastructure in automated way.
• Release components without manual testing.

Some things are worth asking about directly.

• How hard it would be to get a new tool you needed to do your job.
• What their approach to testing is.
• What do they think about Test Driven Development, Trunk Based Development, BDD, pair programming etc etc. Pick what matters to you here. But even if they don't match your preferences entirely, consider why that is. Are they curious and have tried it in the past or have they never bothered?

I don't think a lot of this is discoverable in a non-technical interview. But, in my experience, good places that attract good candidates will give a fairly early opportunity to talk to someone who knows stuff. Perhaps a CTO or a Dev Manager. They will be capable of answering your questions, because communicating all this to a prospective hire is a thing they value.

I also usually ask, later in the process, to pair for a short time with a developer doing their normal stuff.

Answer 4

A major indicator is the meeting culture. Places that tie you up in endless hours of meetings (1) have poor communication which is itself a barrier to quality and (2) tend to have a quantity over quality bias.

I would ask, "Can you tell me about your meeting culture? What types of meetings does this role have and about how much of my time is dedicated to meetings?" You can also clarify that, "I focus my attention on delivering high-quality work and I want to make sure the great majority of my time is spent on value-added tasks."