If I understand what you are getting at, the first example passes an already-created object into a method, while the second example creates the object within the method and then returns it.
Both are perfectly valid things to do, but (naturally enough) are appropriate to different situations. I can't really tell from your simple example which would be more appropriate - after all, if that's all there is to your program it would be even simpler to just write:
Having said all that, I have a general preference for passing in precreated objects, mainly because it allows for easier reuse and testing (by supplying different implmentations of the parameter object, which might be "stub" or "mock" implementations during a unittest, for example.
I feel distinctly uneasy when I see "new" in the middle of some code, especially in a non-overridable private method. There's no way in your example of using a SpecificSomething instead of a Something.
Although not practical everywhere, it is often a good idea to avoid modifying passed-in objects. Or even to avoid modifying any objects.
This makes the objects easier to share. For example, String is easy to share, StringBuffer isn't, because you can't rely on a StringBuffer staying the same. For instance, you couldn't do a for loop over a StringBuffer and cache the length, because another thread might change the length and make your for loop run over the bounds (exception).
Of course, if your method made the StringBuffer and hadn't given it out yet, this wouldn't be a problem.
In the cases where immutability is hard or not practical, you should make methods that mutate have a void return type. This avoids some mistakes where people assume you've made a new object.
To your specific examples - Frank is correct, the 2nd code is harder to write tests for, assuming you need to test this code independently of the Something class. However, if Something already has test cases, and is not expensive to use (doesn't do lots of I/O, etc.), then there is no benefit from testing this code independently of Something. By adding indirection (IoC, etc.), you might actually make the code harder to understand.