Model separate Person types as separate tables at beginning of application's lifetime? If I have a couple of distinct types of Person that will always have a set of disjoint fields, should I go ahead and model them with two different tables?

For example, say I'm setting up a system that connects Worker with Hiring Manager, where both are expected to be individual humans. These two different types of Person will never share members.

At the application layer, I don't expect either of these two types of people to log in, initially, but at some point in the application's life, they will have emails and passwords and so on.

What's the best approach at the beginning?
My gut feeling (which seems to be borne out somewhat by this question) is that you should go ahead and do different tables, since you can always migrate later to a schema where these different Persons all have the same kind of Account associated 1:1 (as suggested in this answer).