Now I understand that your database should only contain "one to many" relationships
Not really. One to One relationships can be quite useful. And some special use relationships may look like "many to many" due to "crowsfeet" at both ends of the relationship line and yet be very useful relationships to use in your database.
4 tables may be a good data model or you might set up one join table for both interviews and placement by using the same table for both, but with a field that identifies the record as either an "interview" or a "placement". I'm not recommending for either option, just pointing out possible options to consider.
Mark, it seems good to me. I worked on a similar database, and yours sounds much the same. We had a tabler named "Status", which could have an "Interview" within the field "Status" (as it had a few other statuses also). We had a separate table for "Calls" (just for Candidates; we had a separate ones for "Client Contacts", and for their "Contact Calls"), which would contain the actual "meeting", for the "interview". Both of these tables had a lot of records, with some more important than others.
Placements did not have a lot of records, but each was critical. They linked together a specific group of a "Client" and "Candidate" (we also had another table for "Jobs", as Client could have multiple jobs, each of which could have more than one possible Placements (do to multiple "positions" for one Job).
So, four tables is the least you need, but it sounds good for a start.