Parent child design to easily identify child type

In our database design we have a couple of tables that describe different objects but which are of the same basic type. As describing the actual tables and what each column is doing would take a long time I'm going to try to simplify it by using a similar structured example based on a job database.

So say we have following tables:

These tables have no connections between each other but share identical columns. So the first step was to unify the identical columns and introduce a unique personId:

Now we have the "header" columns in person that are then linked to the more specific job tables using a 1 to 1 relation using the personId PK as the FK. In our use case a person can only ever have one job so the personId is also unique across the Taxi driver, Programmer and Construction worker tables.

While this structure works we now have the use case where in our application we get the personId and want to get the data of the respective job table. This gets us to the problem that we can't immediately know what kind of job the person with this personId is doing.

A few options we came up with to solve this issue:

Deal with it in the backend

This means just leaving the architecture as it is and look for the right table in the backend code. This could mean looking through every table present and/or construct a semi-complicated join select in which we have to sift through all columns to find the ones which are filled.

All in all: Possible but means a lot of unecessary selects. We also would like to keep such database oriented logic in the actual database.

Using a Type Field

This means adding a field column in the Person table filled for example with numbers to determine the correct child table like:

So you could add a 0 in Type if it's a taxi driver, a 1 if it's a programmer and so on...

While this greatly reduced the amount of backend logic we then have to make sure that the numbers we use in the Type field are known in the backend and don't ever change.

Use separate IDs for each table

That means every job gets its own ID (has to be nullable) in Person like:

Now it's easy to find out which job each person has due to the others having an empty ID.

So my question is: Which one of these designs is the best practice? Am i missing an obvious solution here?