It all depends how they intend to use your answer. One person might “bucket” responses as follows:

• 100 lines or less: all you have written is demos or school assignments. Unless it’s a language designed for little scripts, you probably don’t know it thoroughly or work with it regularly.
• 100,00 lines or less: you write normal sized programs and probably understand them all, and there’s a good chance you’ve met all the features of the language, know how to debug in it, and know at least one framework
• more than 100,000 lines: you are exaggerating or we need to discuss this in the interview

I would be ok with that. But another person might have a far more granular approach where they distinguish between having claimed a 2000 line program and a 10,000 line program. That’s silly. It doesn’t mean that there’s no difference between writing ten programs, each less than a hundred lines, and one thousand line program, because there is, and if you’ve written a thousand line program (or 100,000 line) you know this.

There are three issues with this question.

1. LOC

Lines of code is a terrible measure, especially with the assumption that more lines is better than less.

Imagine two students who are asked to solve the same problem.

• One starts writing code, and during the entire exercise, writes more and more of it, never reading it. At the end of the exercise, the code base is full of:

  1. Dead code (code which is not used at any point),
  2. Code duplication due to Ctrl+C/Ctrl+V abuse (one of the most important issues in software development),
  3. Plain duplication because of the lack of organization (the method is written from scratch, while the pretty same one exists in an other class),

  4. Stupid comments such as:

     // Concatenate the first and the last name.
     string displayName = this.firstName + " " + this.lastName;
     

  5. Pieces of code which should have been inlined, such as:

     int age = this.Age;
     int threshold = this.Threshold;
     int temp = age - threshold;
     int limit = 3;
     
     if (temp == limit)
     {
         return true;
     }
     
     bool tmp = temp > limit;
     if (tmp == true)
     {
         return true;
     }
     else
     {
         return false;
     }
     

     which should have been as simple as:

     int ageWithoutThreshold = this.Age - this.Threshold;
     return ageWithoutThreshold >= MIN_AGE_TO_APPLY;
     

• Another one adds new lines of code carefully: more code means more sources of errors. He regularly refactors the code, architectures it properly to be able to find very easily which method should be put in which class, avoids code duplication, and, in general, tries to do what is required to solve a given problem, and nothing more.

Which one should have a better grade?

2. Working program

What is a working program? How to determine whether it works or not?

If a working program is a program which has no bugs, then there are practically no working programs in the world (a few use formal proof to be able to guarantee that the code doesn’t have bugs, but I can hardly find an example of such program).

If a working program is a program for which no bugs are known, then the spaghetti code I urgently wrote this morning is a working program. I haven’t compiled it yet, so I’m unaware of any bugs, even if I’m pretty sure that such terrible mess would take weeks to correct.

If a working program is a program for which every requirement has a functional test which passes, then what do you do with most code base which is grown organically, often with no written functional and non-functional requirements, and no functional tests?

If a working program is a program that is assumed to work by the author, then the answer to the question is pretty irrelevant. I assume that an app of 5 000 LOC might work. So what?

3. Program ≠ system

Most large systems are assembled from smaller programs, often presented as web services. For example, a CRM may rely on a REST API for authentication of users, or on another API for the management of documents, or on a third API for the upload of the documents.

Those systems are not programs.

For a web developer, for example, it makes no sense to talk about a large program. It would even be alarming to see a web developer being proud of creating a single large program: a set of small services would need much less maintenance.

Measuring familiarity

Using metrics to have an idea of a familiarity of a developer with a language doesn’t make sense. I’ve already explained why LOC measure is wrong. Let’s consider a few other measurements.

1. Years of professional experience

   I’ve spent two days working on a C# project doing work so basic that a monkey could do it. Does it make me more experienced in C# than somebody who haven’t spent two days doing the same thing?

   Take a young, not very smart coder who have spent five years doing e-commerce websites again and again using Ruby. Now take a talented software developer who, until now, worked only with Assembler, C, C++, Java, Haskell and Python. Two weeks ago, he started to learn Ruby. Who is more valuable for a company looking for a developer for a Ruby project?

   Years of professional experience is a meaningless measure; the fact that HR department loves it so much makes it extremely dangerous.

2. Number of projects

   The same arguments apply here. I can spend a year doing e-commerce websites, again and again. Or I can spend a year working on a technically-challenging project where I do learn stuff.

   Sadly, this metric is popular among HR people a lot too.

So, how to measure the experience of a developer in a given language? Through a systemic approach, by considering multiple factors, without transforming them into metrics:

• Implication of the person in the community, including contribution to open source projects,
• Projects which were actually sold,
• Open source projects which became popular,
• Writings (publications, blogs, etc.),
• Participation to the conferences,
• Personal motivation,
• Ease of speech when it comes to explaining language quirks and dark sides,
• Awareness of language pitfalls and drawbacks compared to other languages,
• Knowledge of tools related to the language or ecosystem (debugging tools, testing, continuous integration, continuous delivery, etc.),
• etc.