Self-assessment on "largest project"

Question

In the course of applying for positions in software development, I have been asked to indicate the team size and number of lines of code of the largets project I have worked on. Unforunately, while I have been in software development for roughly 10 years, I feel unable to answer this question accurately:

Team size:

I can make a vague guess here. However, the larger the project, the less I ever got in touch with the whole team. Especially the larger projects I was a part of had quite a bit of hierarchical organization, in which I only ever got in touch with representatives of other branches of the project, each of whom spoke for a whole team of developers, whose size I never became aware of.

On top of that, I hardly ever witnessed a project from its first day till its last day. Therefore, I usually do not know how many people contributed to the project in previous or later phases.

Lines of code (LoC):

For similar reasons as above, I simply have no idea how large the projects were I worked on in terms of LoC. Especially in the larger projects, there usually was a clear distribution of responsibilities, in such a way that I usually wouldn't look into code of modules I did not interface with and hence I even have no idea whether most of the other modules were larger or smaller than the modules I was responsible for. Moreover, given that LoC are quite a meaningless metric unless the actual measurement method is well-defined, I never bothered to find out even for the code I wrote myself.

So, how do I answer the question for the largest project in terms of team size and LoC I was involved in?

• Describe the dimensions of a smaller project? I can tell with absolute certainty that for some of my own open source projects, team size = 1 and LoC = around 50,000 is true. This information would be definitely truthful, but might misrepresent my experience in working on larger projects.
• Pick an arbitrary, smaller project? This might allow me to make a somewhat accurate guess, but is certainly not answering the question for the largest project.
• Say I do not know, like in this question. The self-assessment question (on a form ...) does not expect such a long answer. Also, stating briefly "I do not know." might come across as more disinterested in the projects than what I think I am (frankly, I do not see lack of knowledge about team size of LoC any more as a sign of disinterest in a project than lack of knowledge about an author's birth date and age indicates disinterest in their novels) ... or maybe that is just a paranoid fear?

Answer 1

They ask the team size question to gauge if you worked in a large team or small team. They also gauge if you worked by yourself or with someone else. So you can answer the question appropriately, "I worked with a small team with at least 5 individuals, sometimes more but never over 10. We each get assigned a single ticket for a project each week and we each update our status each morning."

As for LOC, I never got asked that. I would answer it similar to above, "I contributed roughly 50-1000 lines of code per ticket per week."

Answer 2

I would describe the sections of the project that you actually worked on and state that it was part of a larger project, giving estimates of LoC. If they are familiar with large projects they will find this reasonable. So for instance I worked on X project for a year in a team of ten on the Y section and contributed roughly 50,000 LoC.

It's not reasonable to expect you to know the exact numbers of staff involved outside your own portion. So give a rough estimate if you have one and stipulate that it is an estimate only.

Answer 3

Make an estimate. How would they know any different? Whatever answer seems reasonable to you, that is your answer.

The bigger issue here is that if you do not know the answers to these questions, then it would call into question your ability to answer similar questions along the same lines. Sure, you can guestimate your way past a total size of project question, but once you start guestimating your way through the whole interview, the other party may start to get the idea you have no idea what you are doing.

Answer 4

I have no idea how many LOC there are in the projects I'm responsible for, but still get asked by interviewees and internal stakeholders. I think it's fine to guesstimate, once past a certain complexity it becomes almost impossible to know. I use the number of bytes in the repo as a proxy for LOC in this extremely clever formula...

Number of bytes in repo / (Maximum line length in standards / 2)

Alternatively, you could just write a bit of code to scan your repo and then wait a day while it counts the number of EOLs in there...