^
That's what [ code ] tags are for.
The issue with that approach is that, while it's extensible, you lose the referential integrity back to the Clients and Jobs tables. That may or may not be an issue for the OP.
If I was modelling something like this I'd want to know if a client contact is semantically the same as a job contact. If they effectively mean the same thing, then you don't want to completely split the contact tables.
In that case, assuming you want to keep RI, I'd have job_contacts and client_contacts tables that just map between the jobs/clients tables and a single contacts table that has all of the contacts in it.
If they mean different things, then I'd split them up entirely to avoid any confusion.