Without knowing what the rest of the code looks like, I'd say that this is begging for another object that represents the max and min.
When you have state that comes into existence later, that suggests another object. Otherwise, you've got state that is uninitialized for some time, then later is initialized, so the one object is mixing/conflating state with different lifetimes. That conflation can be removed with another object (class instance or tuple), so each then has consistent state lifetime.
That way you're addressing a number of design principles. Single Responsibility, and also, it makes better abstraction. So, there's two objects, the original with its original purpose yet it can create the min/max object, and then min/max object with it's separate purpose and lifetime.
An object is an abstraction — a grouping of things together having a common purpose and lifetime. If you find a different lifetime, that suggests the code is switching abstractions, which suggests another object.
FWIW, the same issues, conflating state lifetimes, occurs in the other question cited by @user2180613, which in that case seems best resolved by using local variables instead of object fields.
It is also worrisome that this is an instance method of an already constructed object that takes the doubles as a parameter. This suggests that the class in question isn't tied to a particular double array, and, that this method could be called again later with a different double array, changing the min and max. Of course, the method is private so maybe this is fine and just internal detail of the constructor; we can't tell from the snippet.
All in all, separating these out into a tuple or other class instance to return would be cleaner and would not beg these questions.