Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been asked to estimate the percentage of time I spend coding at my current position in a job interview (I said about 70%). This excludes time for things like documentation and meetings.

What does this statistic tell an interviewer?

I'm guessing that they are looking for a balance between coding too little (thus being out of practice) and coding too much (not seeing the bigger picture of product development).

EDIT: After reviewing your answers I'm even more curious what the actual reasoning behind this question was... I should have just asked the interviewer! Your answers are actually really funny in the context of this company.

share|improve this question

closed as primarily opinion-based by Ixrec, durron597, MichaelT, GlenH7, Snowman Jun 22 at 3:07

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

It means that you are (as seems incredibly common today) being interviewed by idiots. –  nbt Jun 10 '11 at 19:23
It doesn't tell them anything helpful. They must have a problem with people not working "most of the time" and/or not getting their assigned work done. Why are you excluding meetings and documentation that is part of the coding process, you cannot have a quality production without either, the process does work. –  Ramhound Jun 10 '11 at 19:23
If your answer was 10%, then your 10 years of experience would be more like 2 years. –  Job Jun 11 '11 at 2:40
Are they asking you what percentage of your job is comprised of development (as opposed to support or something else), or are they asking you what percentage of your time while developing is actually spent typing? If the latter, I'm in 100% agreement with Neil. –  GrandmasterB Jun 11 '11 at 5:25

5 Answers 5

up vote 12 down vote accepted

I'm going to go against the grain and suggest it is a very important question. Let's say you listed your title as Senior Software Developer, Lead Software Developer, or Development Lead as I do (because those are titles I've been given). What's your first thought as to how much time I spend in code? 80%? 70%? 50%?

Try 0%. That's right, none. In fact, my record as a Lead Developer has been 10% of time in code. I'm not a bad coder. I spend a lot of my personal time in side projects. But that's not what people pay me for. I'm a coach, a mentor, a management interface, and a cheerleader.

Conversely, on most large teams I've been with there is usually another Senior Developer, Lead Developer, Architect, or, in one peculiar case, Manager who has spent at least 80% of time in code. That's the heavy hitter who has been given titles along with raises to signify the company respects his contributions and wants to keep him around.

I've been asked on every interview how much time I spend in code and always for the same reason. They want to know which kind of "Lead Developer" I am and that's a quick way to asses it.

share|improve this answer

If an interviewer asked me this question I would probably thank them for their time and leave early. This is a huge red flag that they either have clueless managers and interviewers or they are a miserable sweat shop pumping out bad software and engaging in bad development practices.

I imply from this question that by wanting you to exclude time on documentation that they are in fact not concerned about the role of documentation in the software process which is a management anti-pattern. Plus their concern about how much time you spend typing on a keyboard says that they don't acknowledge how important design, and just thinking through problems really is.

share|improve this answer

What does it tell the interviewer? It tells them how you spend the majority of your time. It has no bearing on your competence, or the quality of your code, or anything else. Those things cannot be measured by time alone. The only thing that can be measured by time spent coding, is time spent coding.

I'm a notorious interview question hater, but this one is perfectly reasonable. My weird CV usually provokes this question (my percentage is about 35%, but my job is extremely broad and includes a lot of admin work), and I like it because it is a very easy way to break down my average routine.

That being said, if you're solely a programmer, then you should be spending the bulk of your time coding, so this question is pretty meaningless. It might be useful to account for the amount of bureaucracy at your current job?

share|improve this answer
While I would disagree with your answer if your responsibilities were software development full time, you make a good point that if software development is only part of your current job then perhaps this interview question is acceptable. +1 for that –  maple_shaft Jun 10 '11 at 19:56

Does making a paper prototype count as coding? Is it just writing production code and thus doesn't include tests or proof of concept code? Course this could be seen as being a bit nit-picky when it comes to terminology but I do like the idea of being on the same page as for some coding = implementation while for others coding can mean anything involving working with raw source code on some level which can include debugging, design and a few other aspects as well.

Course I may be a little jaded to see the question as a kind of trick question where if you just toss out a number then you may discover that there were assumptions that went into how it was computed.

share|improve this answer

I don't know if it tells the interviewer anything but you can certainly spin it in a way that makes you look good. The best way to answer would be to say something about each project being different and you dividing your time between researching, prototyping, testing, documenting, and coding based on the complexity and your familiarity with the project requirements. If you're coding something you've seen before then you'll spend less time on researching and prototyping and more time on documentation and coding. Conversely you'll spend more time on researching, prototyping, and testing to make sure the code works as it should if you're in unfamiliar territory.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.