Interview question: Percentage of time spent coding

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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?

Answer 4

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.

Answer 5

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.