How to handle a table schema with a new relationship subtype in an interviews scenario?
My gut says that the schema is rapidly getting too complex.

Let's back up and think about "Entities" and "Relationships".

There are 2 main Entities:  People and Reviews.  See if it is not too clumsy to put Interviewers and Interviewees into the same People table.  If the columns are too different, then make 2 tables.  Ditto for Reviews.

Then provide the minimum number of Relationship tables -- but only when there are many:many relationships.  (Many:1 does not need an extra table.)  The "Interview" is likely to be a Relationship table, but have a few extra columns for when/where/how-long/type/etc.

Do not "over normalize".  For example, an Interview Type is probably one of a few keywords.  These could be implemented in an ENUM without needing an extra table.