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

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
13
down vote

favorite

4

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.

interviewing

share|improve this question

edited Dec 5 '12 at 5:52

asked Dec 4 '12 at 22:44

amphibient

3,20772441

• 
  
  
  

  
  

  
  
  
  
  
  

  
  So how are you asking? The how is often as important as the what.
  – Steve
  Dec 4 '12 at 22:54
  

  
  
  
  


• 
  
  
  

  
  14
  

  
  
  
  
  
  

  
  This question phrased as such comes across to me as, "I only want to be able to do work which interests me, is that ok? I don't really care about being a team player because all I want to do is code..."
  – Elysian Fields♦
  Dec 4 '12 at 23:23
  
  

  
  
  
  


• 
  
  
  

  
  6
  

  
  
  
  
  
  

  
  +1 for "bureaucratic footprint" - a phrase that I hadn't come across and will certainly shamelessly steal.
  – GuyM
  Dec 5 '12 at 5:05
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I had a professor that used the term: administrivia.
  – user8365
  Dec 5 '12 at 13:46
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  This will go over particularly badly if you're going through an interview lead by HR first.
  – Matt
  Dec 7 '12 at 19:25
  

  
  
  
  

 | 
show 9 more comments

up vote
13
down vote

favorite

4

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.

interviewing

share|improve this question

edited Dec 5 '12 at 5:52

asked Dec 4 '12 at 22:44

amphibient

3,20772441

• 
  
  
  

  
  

  
  
  
  
  
  

  
  So how are you asking? The how is often as important as the what.
  – Steve
  Dec 4 '12 at 22:54
  

  
  
  
  


• 
  
  
  

  
  14
  

  
  
  
  
  
  

  
  This question phrased as such comes across to me as, "I only want to be able to do work which interests me, is that ok? I don't really care about being a team player because all I want to do is code..."
  – Elysian Fields♦
  Dec 4 '12 at 23:23
  
  

  
  
  
  


• 
  
  
  

  
  6
  

  
  
  
  
  
  

  
  +1 for "bureaucratic footprint" - a phrase that I hadn't come across and will certainly shamelessly steal.
  – GuyM
  Dec 5 '12 at 5:05
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I had a professor that used the term: administrivia.
  – user8365
  Dec 5 '12 at 13:46
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  This will go over particularly badly if you're going through an interview lead by HR first.
  – Matt
  Dec 7 '12 at 19:25
  

  
  
  
  

 | 
show 9 more comments

up vote
13
down vote

favorite

4

up vote
13
down vote

favorite

4

4

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.

interviewing

share|improve this question

edited Dec 5 '12 at 5:52

asked Dec 4 '12 at 22:44

amphibient

3,20772441

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.

interviewing

share|improve this question

edited Dec 5 '12 at 5:52

asked Dec 4 '12 at 22:44

amphibient

3,20772441

share|improve this question

share|improve this question

edited Dec 5 '12 at 5:52

edited Dec 5 '12 at 5:52

edited Dec 5 '12 at 5:52

asked Dec 4 '12 at 22:44

amphibient

3,20772441

asked Dec 4 '12 at 22:44

amphibient

3,20772441

asked Dec 4 '12 at 22:44

amphibient

3,20772441

3,20772441

• 
  
  
  

  
  

  
  
  
  
  
  

  
  So how are you asking? The how is often as important as the what.
  – Steve
  Dec 4 '12 at 22:54
  

  
  
  
  


• 
  
  
  

  
  14
  

  
  
  
  
  
  

  
  This question phrased as such comes across to me as, "I only want to be able to do work which interests me, is that ok? I don't really care about being a team player because all I want to do is code..."
  – Elysian Fields♦
  Dec 4 '12 at 23:23
  
  

  
  
  
  


• 
  
  
  

  
  6
  

  
  
  
  
  
  

  
  +1 for "bureaucratic footprint" - a phrase that I hadn't come across and will certainly shamelessly steal.
  – GuyM
  Dec 5 '12 at 5:05
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I had a professor that used the term: administrivia.
  – user8365
  Dec 5 '12 at 13:46
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  This will go over particularly badly if you're going through an interview lead by HR first.
  – Matt
  Dec 7 '12 at 19:25
  

  
  
  
  

 | 
show 9 more comments

• 
  
  
  

  
  

  
  
  
  
  
  

  
  So how are you asking? The how is often as important as the what.
  – Steve
  Dec 4 '12 at 22:54
  

  
  
  
  


• 
  
  
  

  
  14
  

  
  
  
  
  
  

  
  This question phrased as such comes across to me as, "I only want to be able to do work which interests me, is that ok? I don't really care about being a team player because all I want to do is code..."
  – Elysian Fields♦
  Dec 4 '12 at 23:23
  
  

  
  
  
  


• 
  
  
  

  
  6
  

  
  
  
  
  
  

  
  +1 for "bureaucratic footprint" - a phrase that I hadn't come across and will certainly shamelessly steal.
  – GuyM
  Dec 5 '12 at 5:05
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I had a professor that used the term: administrivia.
  – user8365
  Dec 5 '12 at 13:46
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  This will go over particularly badly if you're going through an interview lead by HR first.
  – Matt
  Dec 7 '12 at 19:25
  

  
  
  
  

So how are you asking? The how is often as important as the what.
– Steve
Dec 4 '12 at 22:54

So how are you asking? The how is often as important as the what.
– Steve
Dec 4 '12 at 22:54

14

14

This question phrased as such comes across to me as, "I only want to be able to do work which interests me, is that ok? I don't really care about being a team player because all I want to do is code..."
– Elysian Fields♦
Dec 4 '12 at 23:23

This question phrased as such comes across to me as, "I only want to be able to do work which interests me, is that ok? I don't really care about being a team player because all I want to do is code..."
– Elysian Fields♦
Dec 4 '12 at 23:23

6

6

+1 for "bureaucratic footprint" - a phrase that I hadn't come across and will certainly shamelessly steal.
– GuyM
Dec 5 '12 at 5:05

+1 for "bureaucratic footprint" - a phrase that I hadn't come across and will certainly shamelessly steal.
– GuyM
Dec 5 '12 at 5:05

1

1

I had a professor that used the term: administrivia.
– user8365
Dec 5 '12 at 13:46

I had a professor that used the term: administrivia.
– user8365
Dec 5 '12 at 13:46

1

1

This will go over particularly badly if you're going through an interview lead by HR first.
– Matt
Dec 7 '12 at 19:25

This will go over particularly badly if you're going through an interview lead by HR first.
– Matt
Dec 7 '12 at 19:25

 | 
show 9 more comments

8 Answers
8

active

oldest

votes

up vote
27
down vote

...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.

share|improve this answer

answered Dec 4 '12 at 23:19

Steve

3,70611127

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Agreed. When I read "bureaucratic footprint" I thought of things like reviewing timesheets, taking mandatory training (like harrassment, ethics, info security 101), filling out IT paperwork to install software, stuff like that. Non-coding parts of the actual job are still, y'know, parts of the job, and if that's what OP means I would react badly too.
  – Monica Cellio♦
  Dec 5 '12 at 15:43
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Have to admit I was a bit floored at the question. Even asked for clarification but was assured that this was how it was asked.
  – Steve
  Dec 5 '12 at 16:15
  

  
  
  
  

add a comment | 

up vote
15
down vote

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."

share|improve this answer

answered Dec 4 '12 at 23:13

pdr

19.2k46081

• 
  
  
  

  
  

  
  
  
  
  
  

  
  This is how I usually ask it too. I want to know the broader picture, not just the administrivia piece. I usually ask about a typical week (rather than day) because that lets the day-to-day variation settle down a bit. But hey, if the person answers in terms of days that's cool too; the point is to get a breakdown of all the major types of tasks, not just codinvg vs admin.
  – Monica Cellio♦
  Dec 5 '12 at 15:46
  

  
  
  
  

add a comment | 

up vote
7
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:11

Justin Cave

34.9k9112136

add a comment | 

up vote
7
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:39

Elysian Fields♦

96.9k46292449

add a comment | 

up vote
4
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:18

JB King

15.1k22957

add a comment | 

up vote
3
down vote

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.

share|improve this answer

answered Dec 5 '12 at 14:09

user8365

add a comment | 

up vote
2
down vote

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!

share|improve this answer

answered Dec 7 '12 at 16:30

Rhys

5,73623558

• 
  
  
  

  
  

  
  
  
  
  
  

  
  fantastic answer. thanks
  – amphibient
  Dec 7 '12 at 16:33
  

  
  
  
  

add a comment | 

up vote
2
down vote

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.

share|improve this answer

answered Dec 7 '12 at 17:06

bethlakshmi

70.4k4136277

add a comment | 

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "423"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
noCode: true, onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f6755%2fis-it-appropriate-to-ask-an-interviewer-about-the-positions-bureaucratic-footpr%23new-answer', 'question_page');

);

Post as a guest

Name Email

StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;

var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');

$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');

pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);

)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();


);
);

8 Answers
8

active

oldest

votes

8 Answers
8

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
27
down vote

...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.

share|improve this answer

answered Dec 4 '12 at 23:19

Steve

3,70611127

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Agreed. When I read "bureaucratic footprint" I thought of things like reviewing timesheets, taking mandatory training (like harrassment, ethics, info security 101), filling out IT paperwork to install software, stuff like that. Non-coding parts of the actual job are still, y'know, parts of the job, and if that's what OP means I would react badly too.
  – Monica Cellio♦
  Dec 5 '12 at 15:43
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Have to admit I was a bit floored at the question. Even asked for clarification but was assured that this was how it was asked.
  – Steve
  Dec 5 '12 at 16:15
  

  
  
  
  

add a comment | 

up vote
27
down vote

...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.

share|improve this answer

answered Dec 4 '12 at 23:19

Steve

3,70611127

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Agreed. When I read "bureaucratic footprint" I thought of things like reviewing timesheets, taking mandatory training (like harrassment, ethics, info security 101), filling out IT paperwork to install software, stuff like that. Non-coding parts of the actual job are still, y'know, parts of the job, and if that's what OP means I would react badly too.
  – Monica Cellio♦
  Dec 5 '12 at 15:43
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Have to admit I was a bit floored at the question. Even asked for clarification but was assured that this was how it was asked.
  – Steve
  Dec 5 '12 at 16:15
  

  
  
  
  

add a comment | 

up vote
27
down vote

up vote
27
down vote

...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.

share|improve this answer

answered Dec 4 '12 at 23:19

Steve

3,70611127

...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.

share|improve this answer

answered Dec 4 '12 at 23:19

Steve

3,70611127

share|improve this answer

share|improve this answer

answered Dec 4 '12 at 23:19

Steve

3,70611127

answered Dec 4 '12 at 23:19

Steve

3,70611127

answered Dec 4 '12 at 23:19

Steve

3,70611127

3,70611127

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Agreed. When I read "bureaucratic footprint" I thought of things like reviewing timesheets, taking mandatory training (like harrassment, ethics, info security 101), filling out IT paperwork to install software, stuff like that. Non-coding parts of the actual job are still, y'know, parts of the job, and if that's what OP means I would react badly too.
  – Monica Cellio♦
  Dec 5 '12 at 15:43
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Have to admit I was a bit floored at the question. Even asked for clarification but was assured that this was how it was asked.
  – Steve
  Dec 5 '12 at 16:15
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Agreed. When I read "bureaucratic footprint" I thought of things like reviewing timesheets, taking mandatory training (like harrassment, ethics, info security 101), filling out IT paperwork to install software, stuff like that. Non-coding parts of the actual job are still, y'know, parts of the job, and if that's what OP means I would react badly too.
  – Monica Cellio♦
  Dec 5 '12 at 15:43
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Have to admit I was a bit floored at the question. Even asked for clarification but was assured that this was how it was asked.
  – Steve
  Dec 5 '12 at 16:15
  

  
  
  
  

4

4

Agreed. When I read "bureaucratic footprint" I thought of things like reviewing timesheets, taking mandatory training (like harrassment, ethics, info security 101), filling out IT paperwork to install software, stuff like that. Non-coding parts of the actual job are still, y'know, parts of the job, and if that's what OP means I would react badly too.
– Monica Cellio♦
Dec 5 '12 at 15:43

Agreed. When I read "bureaucratic footprint" I thought of things like reviewing timesheets, taking mandatory training (like harrassment, ethics, info security 101), filling out IT paperwork to install software, stuff like that. Non-coding parts of the actual job are still, y'know, parts of the job, and if that's what OP means I would react badly too.
– Monica Cellio♦
Dec 5 '12 at 15:43

Have to admit I was a bit floored at the question. Even asked for clarification but was assured that this was how it was asked.
– Steve
Dec 5 '12 at 16:15

Have to admit I was a bit floored at the question. Even asked for clarification but was assured that this was how it was asked.
– Steve
Dec 5 '12 at 16:15

add a comment | 

up vote
15
down vote

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."

share|improve this answer

answered Dec 4 '12 at 23:13

pdr

19.2k46081

• 
  
  
  

  
  

  
  
  
  
  
  

  
  This is how I usually ask it too. I want to know the broader picture, not just the administrivia piece. I usually ask about a typical week (rather than day) because that lets the day-to-day variation settle down a bit. But hey, if the person answers in terms of days that's cool too; the point is to get a breakdown of all the major types of tasks, not just codinvg vs admin.
  – Monica Cellio♦
  Dec 5 '12 at 15:46
  

  
  
  
  

add a comment | 

up vote
15
down vote

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."

share|improve this answer

answered Dec 4 '12 at 23:13

pdr

19.2k46081

• 
  
  
  

  
  

  
  
  
  
  
  

  
  This is how I usually ask it too. I want to know the broader picture, not just the administrivia piece. I usually ask about a typical week (rather than day) because that lets the day-to-day variation settle down a bit. But hey, if the person answers in terms of days that's cool too; the point is to get a breakdown of all the major types of tasks, not just codinvg vs admin.
  – Monica Cellio♦
  Dec 5 '12 at 15:46
  

  
  
  
  

add a comment | 

up vote
15
down vote

up vote
15
down vote

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."

share|improve this answer

answered Dec 4 '12 at 23:13

pdr

19.2k46081

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."

share|improve this answer

answered Dec 4 '12 at 23:13

pdr

19.2k46081

share|improve this answer

share|improve this answer

answered Dec 4 '12 at 23:13

pdr

19.2k46081

answered Dec 4 '12 at 23:13

pdr

19.2k46081

answered Dec 4 '12 at 23:13

pdr

19.2k46081

19.2k46081

• 
  
  
  

  
  

  
  
  
  
  
  

  
  This is how I usually ask it too. I want to know the broader picture, not just the administrivia piece. I usually ask about a typical week (rather than day) because that lets the day-to-day variation settle down a bit. But hey, if the person answers in terms of days that's cool too; the point is to get a breakdown of all the major types of tasks, not just codinvg vs admin.
  – Monica Cellio♦
  Dec 5 '12 at 15:46
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  This is how I usually ask it too. I want to know the broader picture, not just the administrivia piece. I usually ask about a typical week (rather than day) because that lets the day-to-day variation settle down a bit. But hey, if the person answers in terms of days that's cool too; the point is to get a breakdown of all the major types of tasks, not just codinvg vs admin.
  – Monica Cellio♦
  Dec 5 '12 at 15:46
  

  
  
  
  

This is how I usually ask it too. I want to know the broader picture, not just the administrivia piece. I usually ask about a typical week (rather than day) because that lets the day-to-day variation settle down a bit. But hey, if the person answers in terms of days that's cool too; the point is to get a breakdown of all the major types of tasks, not just codinvg vs admin.
– Monica Cellio♦
Dec 5 '12 at 15:46

This is how I usually ask it too. I want to know the broader picture, not just the administrivia piece. I usually ask about a typical week (rather than day) because that lets the day-to-day variation settle down a bit. But hey, if the person answers in terms of days that's cool too; the point is to get a breakdown of all the major types of tasks, not just codinvg vs admin.
– Monica Cellio♦
Dec 5 '12 at 15:46

add a comment | 

up vote
7
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:11

Justin Cave

34.9k9112136

add a comment | 

up vote
7
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:11

Justin Cave

34.9k9112136

add a comment | 

up vote
7
down vote

up vote
7
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:11

Justin Cave

34.9k9112136

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.

share|improve this answer

answered Dec 4 '12 at 23:11

Justin Cave

34.9k9112136

share|improve this answer

share|improve this answer

answered Dec 4 '12 at 23:11

Justin Cave

34.9k9112136

answered Dec 4 '12 at 23:11

Justin Cave

34.9k9112136

answered Dec 4 '12 at 23:11

Justin Cave

34.9k9112136

34.9k9112136

add a comment | 

add a comment | 

up vote
7
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:39

Elysian Fields♦

96.9k46292449

add a comment | 

up vote
7
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:39

Elysian Fields♦

96.9k46292449

add a comment | 

up vote
7
down vote

up vote
7
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:39

Elysian Fields♦

96.9k46292449

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.

share|improve this answer

answered Dec 4 '12 at 23:39

Elysian Fields♦

96.9k46292449

share|improve this answer

share|improve this answer

answered Dec 4 '12 at 23:39

Elysian Fields♦

96.9k46292449

answered Dec 4 '12 at 23:39

Elysian Fields♦

96.9k46292449

answered Dec 4 '12 at 23:39

Elysian Fields♦

96.9k46292449

96.9k46292449

add a comment | 

add a comment | 

up vote
4
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:18

JB King

15.1k22957

add a comment | 

up vote
4
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:18

JB King

15.1k22957

add a comment | 

up vote
4
down vote

up vote
4
down vote

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.

share|improve this answer

answered Dec 4 '12 at 23:18

JB King

15.1k22957

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.

share|improve this answer

answered Dec 4 '12 at 23:18

JB King

15.1k22957

share|improve this answer

share|improve this answer

answered Dec 4 '12 at 23:18

JB King

15.1k22957

answered Dec 4 '12 at 23:18

JB King

15.1k22957

answered Dec 4 '12 at 23:18

JB King

15.1k22957

15.1k22957

add a comment | 

add a comment | 

up vote
3
down vote

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.

share|improve this answer

answered Dec 5 '12 at 14:09

user8365

add a comment | 

up vote
3
down vote

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.

share|improve this answer

answered Dec 5 '12 at 14:09

user8365

add a comment | 

up vote
3
down vote

up vote
3
down vote

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.

share|improve this answer

answered Dec 5 '12 at 14:09

user8365

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.

share|improve this answer

answered Dec 5 '12 at 14:09

user8365

share|improve this answer

share|improve this answer

answered Dec 5 '12 at 14:09

user8365

answered Dec 5 '12 at 14:09

user8365

answered Dec 5 '12 at 14:09

user8365

add a comment | 

add a comment | 

up vote
2
down vote

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!

share|improve this answer

answered Dec 7 '12 at 16:30

Rhys

5,73623558

• 
  
  
  

  
  

  
  
  
  
  
  

  
  fantastic answer. thanks
  – amphibient
  Dec 7 '12 at 16:33
  

  
  
  
  

add a comment | 

up vote
2
down vote

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!

share|improve this answer

answered Dec 7 '12 at 16:30

Rhys

5,73623558

• 
  
  
  

  
  

  
  
  
  
  
  

  
  fantastic answer. thanks
  – amphibient
  Dec 7 '12 at 16:33
  

  
  
  
  

add a comment | 

up vote
2
down vote

up vote
2
down vote

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!

share|improve this answer

answered Dec 7 '12 at 16:30

Rhys

5,73623558

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!

share|improve this answer

answered Dec 7 '12 at 16:30

Rhys

5,73623558

share|improve this answer

share|improve this answer

answered Dec 7 '12 at 16:30

Rhys

5,73623558

answered Dec 7 '12 at 16:30

Rhys

5,73623558

answered Dec 7 '12 at 16:30

Rhys

5,73623558

5,73623558

• 
  
  
  

  
  

  
  
  
  
  
  

  
  fantastic answer. thanks
  – amphibient
  Dec 7 '12 at 16:33
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  fantastic answer. thanks
  – amphibient
  Dec 7 '12 at 16:33
  

  
  
  
  

fantastic answer. thanks
– amphibient
Dec 7 '12 at 16:33

fantastic answer. thanks
– amphibient
Dec 7 '12 at 16:33

add a comment | 

up vote
2
down vote

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.

share|improve this answer

answered Dec 7 '12 at 17:06

bethlakshmi

70.4k4136277

add a comment | 

up vote
2
down vote

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.

share|improve this answer

answered Dec 7 '12 at 17:06

bethlakshmi

70.4k4136277

add a comment | 

up vote
2
down vote

up vote
2
down vote

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.

share|improve this answer

answered Dec 7 '12 at 17:06

bethlakshmi

70.4k4136277

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.

share|improve this answer

answered Dec 7 '12 at 17:06

bethlakshmi

70.4k4136277

share|improve this answer

share|improve this answer

answered Dec 7 '12 at 17:06

bethlakshmi

70.4k4136277

answered Dec 7 '12 at 17:06

bethlakshmi

70.4k4136277

answered Dec 7 '12 at 17:06

bethlakshmi

70.4k4136277

70.4k4136277

add a comment | 

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f6755%2fis-it-appropriate-to-ask-an-interviewer-about-the-positions-bureaucratic-footpr%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email