When I evaluate a job, I usually optimize for a few things (position, location, salary, tech) but very TOP of the list (i.e., non-negotiable) is what my sense of happiness as a contributor/developer will be.
A very good metric to this (for me) is lines of code. Take where they say their product is (in terms of features etc) and then weigh that agains their LOC (if they're willing to give it to you)... If you get a sense that the LOC is far too much wrt the capability of the product (experience/intuition will give you a feel for this over time, as you start paying attention to the metric)... this will give you a good sense of how many late nights you'll be spending trying to fix some nasty bugs or contend with spaghettini instead of delivering real value.
Experience and intuition give you approximately no useful, valid "feel" for how much LOC is appropriate for a given thing, with the possible exception of outliers or incredibly trivial programs.
We don't value LOC as a measure of productivity because it is a terrible metric to use. That doesn't change just because a person is on the developer rather than the manager side of things.
LOC can be a huge indicator of quality of code imho—would you want to work on a 100k loc app that is more or less crud operations for a specific domain? Etc.
A very good metric to this (for me) is lines of code. Take where they say their product is (in terms of features etc) and then weigh that agains their LOC (if they're willing to give it to you)... If you get a sense that the LOC is far too much wrt the capability of the product (experience/intuition will give you a feel for this over time, as you start paying attention to the metric)... this will give you a good sense of how many late nights you'll be spending trying to fix some nasty bugs or contend with spaghettini instead of delivering real value.