In addition to [all][1] [the][2] [other][3] 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][4] library to better represent chronological events/periods. The `long` primitive also makes it questionable what is the [epoch][5] 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][6] 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](https://en.wikipedia.org/wiki/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][3]'s answer, sometimes you should consider `enum`s instead of 'plain' `int` and `String` values. `Enum`s 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. :)

[1]: https://codereview.stackexchange.com/a/107638/24141
[2]: https://codereview.stackexchange.com/a/107648/24141
[3]: https://codereview.stackexchange.com/a/107695/24141
[4]: http://www.joda.org/joda-time/
[5]: https://en.m.wikipedia.org/wiki/Epoch_(reference_date)
[6]: https://en.m.wikipedia.org/wiki/Unix_epoch