In addition to all the other excellent answers...

Seeking new employment

@Override
public void fire() {
    this.salary = 0;
    this.employer = HOMELESS;
    isHappy = false;
    status = LOOKING_FOR_NEW_JOB;
}

I'm pretty sure HOMLESS can't be an employer. Also, does calling this method imply the engineer is fired, or the engineer has decided to fire the employer? Should there be a difference between resign() and retrench()?

Dates

Using long primitive to represent 'times' is an archaic concept from the old java.util.Date-based classes. In case you are not on Java 8 (with its new java.time.* APIs), you should look at the JodaTime library to better represent chronological events/periods. The long primitive also makes it questionable what is the epoch you are using. As a last resort, even a Date object will be better as it clearly represents a date-time, and uses the well-understood Unix epoch so that there is no ambiguity there.

equals(Object) comparison

@Override
public boolean equals(Object engineer) {
    if (this == engineer) {
        return true;
    }
    Engineer e = (Engineer) engineer;
    return this.isHappy == e.isHappy() && hashCode() == e.hashCode();
}

You will also need to return false when the input is not an Engineer implementation. This is partly why for the equals(Object) method, the argument name used here is usually something along the lines of object, obj, other or just o. It cannot be assumed that the casting will always work.

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.

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'.

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. :)