In addition to all the other excellent answers...

As mentioned in @VoiceOfUnreason's answer, sometimes you should consider enums instead of 'plain' int and String values. Enums are usually more expressive and thus a better fit for enumerated values. Constants should always be declared as static final to communicate the intent that they are unmodifiable, and that they can be used without class instantiation.

In addition to all the other excellent answers...

As mentioned in @VoiceOfUnreason's answer, sometimes you should consider enums instead of 'plain' int and String values. Enums are usually more expressive and thus a better fit for enumerated values. Constants should always be declared as static final to communicate the intent that they are unmodifiable, and that they can be used without class instantiation.

edit: After some Googling, I think it's prudent to clarify that this is not an endorsement of the constant interface pattern, and I hope you are not alluding to that. An interface should be used for its original purpose, foremost. It should not be used purely to attach constants to classes implementing the interface. When implementations require some constants to ease inter-implementation operability, or said constants are abstract enough not to be regarded as implementation-specific, then adding them to the interface 'makes sense'.

Answering your questions

1. Is it OK to put constants to interface and use them in the implementation?

Certainly, so long that it makes sense for them to 'belong' to the interface.

2. Should I make constants static final if they are defined in an interface? Which constants should I prefer, int or String?

As mentioned in @VoiceOfUnreason's answer, sometimes you should consider enums instead of 'plain' int and String values. Enums are usually more expressive and thus a better fit for enumerated values. Constants should always be declared as static final to communicate the intent that they are unmodifiable, and that they can be used without class instantiation.

3. Can I make some additional actions in setters?

The idea here is to be consistent. If your setEmployer() method calls signRenumerationPackage() and the optional (I hope) burnBridges() methods, then you have to make sure modifying the employer reference always goes through the setEmployer() setter. As long as you have consistency in place, having additional actions in setters are OK and sometimes even encouraged.

4. When should I write a JavaDoc?

As early as possible. :)