Is it appropriate to ask an interviewer about the position's bureaucratic footprint?

Question

When interviewing, is it appropriate to ask the interviewer about the position's or even organizational bureaucratic footprint? I have asked it several times but I got the impression it wasn't received very well, essentially as coming from someone who potentially may be evading the organizational standards and procedures, is a downright slacker or not skilled at subtle communication.

Essentially, what I would like to find out is: for every hour of doing my technical responsibilities, how many minutes they envision I would spend doing administrative tasks, such as babysitting deployments, documentation, non-technical meetings etc.

If asking it directly is not recommended, how would you go about extracting that info in a manner that would not garner prejudice against me and reduce my chances of being hired.

Answer 1

...for every hour of doing my technical responsibilities, how many minutes they envision I would spend doing administrative tasks, such as babysitting deployments, documentation, non-technical meetings etc.

The idea behind your question is reasonable and one that I've taken in many interviews over the years. I've never reacted badly to the question nor has it been received poorly when I've asked it.

But the way your phrase your question would certainly cause me to react badly if I was interviewing you for a technical position where your responsibilities included deployments and documentation for example. You've basically just said that you don't consider those tasks important or part of your technical responsibility.

You've pretty much told me that:

1. What you consider important and what I consider important aren't the same.
2. If that's what you expect I won't fit in with the company culture here.
3. I may do the work you ask of me but I'll never treat it with the same respect and diligence that I do the things that I consider fun and exciting.

As I said in my comments: the how you ask is important as well. And in this case the how would have prevented you from moving forward in the process at all.

Simply asking 'How much time is spend on non-job related tasks?' would open the door for you to ask more pointed and direct questions without tipping your hand.

Answer 2

I always ask "What does the average programmer's average day look like?" I frequently get joking responses, such as "What's an average day?" In those cases, I go into more detail.

But here's the key, I think: I always make it clear that I expect there to be some non-programming time, and I have no problem with that. When you say "for every hour I spend programming, how many minutes ..." you are giving the impression that you have a problem with those minutes, that you resent them, that what you really want to hear is "zero".

Try to talk on a larger scale and put other tasks on a par with programming.

"In an average week, what percentage would I expect to spend: programming, in meetings with other developers, in meetings with customers or product managers, working with a designer, doing administrative tasks, researching, etc."

Answer 3

You certainly can (and should) ask about the development methodology that is used which should tell you a good deal about how much overhead you should expect.

Rather than asking how much time you would be expected to spend babysitting deployments, you'd want to ask about the build management system. If the interviewer says that they've got a system that automatically builds and deploys to production every day with no downtime, you can be pretty confident that you're not going to spend much time dealing with deployments. If the interviewer involves more manual efforts and coordinating the efforts of humans in different groups, you'll be spending a lot more time on deployments.

Rather than asking how much time you would spend writing documentation, you'd ask about the organization's approach to software development. If they do traditional waterfall development, you'd expect that a lot more time is spent by developers writing documentation (and much more time would be spend writing requirements for the developers). If they have a more agile approach, you'd expect less time to be spent generating documentation (though, of course, that also means that the requirements you get will tend to be less detailed because the approach assumes that things will change).

Similarly, you can ask about how they track bugs, how they track requirements, how they test, how they prioritize items, etc. The more manual the process and the more process there is, the more time you should expect to spend doing non-technical tasks.

By talking about the software development process, you generally show yourself to be an engaged developer and you generally make it hard for the interviewer to (intentionally or accidentally) mislead you. Most people don't have a really accurate idea of what they actually spend time on over the course of a day-- lots of minor tasks end up swallowing much larger fractions of the day-- so it is hard for most people to accurately guess about how much time is spent working on builds. This is doubly true when the people doing the interviewing are managers that aren't doing those tasks themselves. It is easy for managers to believe that a build process is relatively smooth when, in reality, it involves a ton of manual intervention, simply because no one brings the inefficiency to their attention. Talking about the process of developing software, however, tends to be much easier since it is much more transparent. It is unlikely that a manager would be unaware, for example, of the daily standup meeting if that's what the team uses or that the manager wouldn't be able to describe at least generally how releases are planned and deployed.

Answer 4

If asking it directly is not recommended, how would you go about extracting that info in a manner that would garner prejudice against me and reduce my chances of being hired.

All software developers are going to have to do these tasks. Sorry, but you're going to have to do work which isn't coding/

That being said, you can ask things like:

• "What is your approach to developing higher level yet new architecture?" This gives insight into how many brainstorming/planning meetings you will have.
• "How is existing code maintained?" This gets at what documentation is created as part of the process, and it's easy to ask about this
• "What is the process for deploying new code/revisions?" Gets at the involvement of the developer in this process..
• "How involved are software developers in researching customer needs and developing specifications?" Insight into how much time you will spend on scope, feature brainstorming, etc.
• "How do you track software bugs/features to be developed?" Helps give insight into documentation/issue tracking.
• "What is your least favorite part of your job?" When asked to other developers, can be incredibly insightful as this is often a least favorite part for developers.

These questions, asked in some combination, will very clearly give you an answer to your question. Also note that while most of these questions are specific to software, the general idea applies to nearly all jobs - but rather than software/code you just substitute whatever product you work on (marketing material, widgets, etc) in the questions.

Answer 5

Essentially, what I would like to find out is: for every hour of doing my technical responsibilities, how many minutes they envision I would spend doing administrative tasks, such as babysitting deployments, documentation, non-technical meetings etc.

I'd probably first ask whether or not the company has formal processes in place that would allow for this kind of accounting. If the organization is a start-up then there may well be a cowboy mentality where this kind of tracking just isn't done and thus you'd get a potentially blank stare.

You do realize that "babysitting deployments" and "documentation" may well be considered technical from a management perspective though not from fellow developers, right? There are communication issues here along with being careful in your vocabulary here.

Answer 6

You need to ask for examples to see how detailed the documentation requirements are and compare to other positions you've had. How much "time" you have to spend on them is going to be determined by your writing skills.

It's more important to gauge their perceptions on the amount of time developers currently spend in this area. Do they think it needs improvement? Are they open to finding tools to make the process more automated?

Every programmer would rather be writing code than doing just about anything else. They get it. What they don't want is someone who displays such an aversion to it that they may be difficult to work with and reluctant to do the dirty work. Focus more on finding their management style to see if they are open to making improvements in this area.

Answer 7

I would say it is appropriate to ask this question about the role.

The interview is a two way process, one where the company learns about you, your skills, and if they think you will fit with the team. The second is you gaining information on the job you are expected to do and the environment (both physical and digital) that you are expected to work in.

Many people suggest asking a question like this would hint at the interviewer that 'you only want to do what you want' and anything else is an added weight to your daily struggle.

I both agree and disagree, you ARE giving this impression to some interviewers, but at the same time if you are looking for a job that has a low bureaucratic footprint you are well within your rights to factor this into your decision making process.

At the end of the day there are many inappropriate questions to ask. I don't think this is one of them as your happiness is a large factor in your productivity at a job. Just be wary that HOW you ask this is of real importance.

If you make it out as a hassle, a daily struggle, an added weight then you are likely to be viewed in a negative light.

It's all about positivity, you want to give the impression that you WILL give your best, that you WILL work with the company and not against it!

Answer 8

As others said, I would skip the words "organizational bureaucratic footprint". It sounds snazzy and smart but it could easily come off as snide. The managers who are interviewing you could very well be the ones responsible for the "organizational bureaucratic footprint" and they did whatever (potentially horrible) bureaucracy for a reason that they considered value enough to justify everyone's time. They may even be proud of this work and see it as a real value add to the company, so summing it all up as bureaucracy (which has a negative connotation in and of itself) is not likely to win you advocates. Fellow individual contributors may find it a fun and clever phrase - certainly we've all had to dwell within a pile of red tape big enough to be a footprint made by the abominable snowman, but when you're the snowman, you may not find it funny.

It sounds like your biggest concerns are in the time spent on things that I'd call "risk mitigation" at an individual contributor level. Meetings, documentation and deployment verification all seek to mitigate the screw ups that happen between other members of the project when people fail to communicate clearly about an important part of the job.

I like quite a lot of the answers provided by other posters, here, and I'm loathe to reiterate these many good examples, so I'll just point out that there are a few basic strategies:

• Day in the Life Questions - get into detail about the tasks you'll be expected to do and what the work breakdown on a given day, week, phase may be. Talk about processes, talk about particular areas of concern on the project, talk about team dynamics, talk about tools and processes they use to make rote, repeatable work faster.

• What do we care most about Questions - different industries have different drivers. Government, defense and health care often have very strong drivers for quality - you'll spend a lot of time documenting code so someone else can maintain it without messing things up, lots of time testing and checking that everything works, lots of time making sure that specifications are clear and deployments are done properly. In a life critical system, not screwing up is more important than getting an extra feature done. In e-Commerce, social media and other products in a very competitive feature space, getting something to the market fast is the name of the game. There's quality assurance, but if push comes to shove, they'll get it to market, even if something minor (like documentation) isn't done. So, ask about what the company's priorities are and how they chain to the way you'd be doing work as a developer.

• Corporate culture questions - is is a dictatorship? A consensus culture? a small group of illuminati running the business? How are decisions made, how are issues resolved, why and when do you have formal meetings? How the organization makes plans to move forward and overcome obstacles will highly influence the number of meetings and the productiveness of those meetings.

I'd actually ask a mix of all three at any given interview, and I'd pick and choose between them based on the interviewer - both his personal style, and his place in the organziation would be factors. Managers are likelier to be able to answer the "what do we care about" questions most clearly and succintly. Individual contributors may be most accurate at the "day in the life" questions. Often I find that the HR rep is better than you'd think at the "corporate culture" questions because they see the team from the outside looking in. But that doesn't mean you should strictly limit the target of your questions. For example, it can be VERY telling if the individual contributor and the manager don't agree much on any of these questions - particularly the "what we care about" - if the team is working one angle and the management sees another you are looking at team that may be headed for a crash landing for other reasons than Death by Paperwork.

Over time, I've developed a sense from talking to others in my industry of where my preferred job types land in the realm of "organizationl bureaucratic footprints" - I happen to like high risk, high complexity, high cost, high bureaucratic overhead type challenges... but I also realize how much more quickly my peers in other industries move... over time, my general sense has been that in most cases, competitors in an industry will operate very similarly - so if I know how one operates, I can make certain generalizations about the next and go into the details pretty quickly.