Interview question: “How do you make sure your logs are sufficient?” [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 1 year ago.

Improve this question

I was in a job interview with a vp r&d today.

I would like to ask it here, even though it is, in my opinion, too broad as a question.

One of his questions went something like:

"How do you make sure your code works?"

This question struck me as a bit strange, so I explained how I debug (divide and conquer, debugger, prints, unit testing).

He then continued:

"What if the problem only comes once a day?"

I said I would use a log.

He then asked

"What would you put in the log?"

"How can you make sure that when you get the log, you would be able to find the problem quickly?"

I sat there quietly, not knowing the answer he was looking for.

The question seems over-broad to me, and I am sure with some specific context I would have been able to come up with something.

Maybe it's actually a viable question and I just have a knowledge gap, or I just don't get something…

My question to you:

Is there any standard methodology for logging?

What answer could he have been waiting to hear?

Answer 1

How do you make sure your logs are sufficient?

My 11th grade English teacher has the best answer for this question:

Know your audience.

Think about who will be reading this. What they will and wont know. Think about what they need.

When you log, log with intention. There should be a point to everything you capture. You should be thinking about the use cases your logs will be put to. You should have clear ideas here. Otherwise you give up and just log everything.

To much logging is worse than not enough. I've been on teams that couldn't control this and created beasts that filled up our largest hard drives every few days. Worse the torrent of data kept normal users from being able to figure out what was happening to the system.

When you log think about who you're logging for. They are your audience. Do not overwhelm them. Keep what you show them clear, brief and useful.

Conversely, insufficient logging is easy to fix. Add logging as you find you need it. This only works though if you are iteratively developing. That is, you write it, use it, learn from it, and rewrite it. Some people just call this testing.

For that to work you have to put yourself in the mind of who will use the log. This can be end users as well as maintenance programmers. Your log might inspire searches of the code base. It might inspire searches on google. Give them enough keywords that they can find appropriate results.

Also, it can be useful to know the state of the system. Sure give me a break point and a reproduceable error and I can learn that myself but I still hate seeing "File not found" with no mention of the expected file name. Give me the fully qualified name and I'll know where to put the file to fix this problem.

"How can you make sure that when you get the log, you would be able to find the problem quickly?"

Make sure you log something that can be used in a search. You don't have to dump a full stack trace for every log entry. Not everything you log is consumed by a programmer anyway. But what you log should be something someone could look up in something.

When logging an error, a stack trace might be appropriate but logging covers more than errors. Class and method name are sometimes enough, usually right next to the date-time stamp. Even without those you can still provide a way to find what created this log entry by ensuring use of a unique word or phrase that can be found by searching the code base. I've used this one plenty.

Pro tip: don't break up the searchable phrase by word wrapping it in the source code. People aren't going to know where to put "\n + " in their search string.