People are just people.
An instructor can take a class, and thus, be a student. An admin may also instruct. A student may take several classes, and thus have several instructors. So, it is best not to conflate the notions of a person's identity with the role(s) they play and to accommodate that roles they play are contextual.
Many systems need to support the notion that one user has several roles. If you don't support that, then when an Instructor is an Admin or a Student, either they'll have too much permission for a given context or it just won't work properly, and they'll have to use a different login (i.e. create multiple identities, possibly involving managing multiple email addresses) when they want to use the system from a different role they play.
Regarding your internal implementation (from your comment to @Joppe), use of inheritance (e.g. Student inherits from Account) precludes having one person play multiple roles. This should use composition instead. Speaking philosophically, we would not say that "A Student is-a(n) Account".
You might consider an identity page, which gives the user access to the various roles & contexts they have. Then allow them to choose a role (or context) and proceed with the authorizations and access control associated with that role for the rest of their session. They should be able to change roles by going back to their identity page.