TL;DR: A hard link is another directory entry pointing at the same inode, so the two names are equal and the data survives until the last one is removed. A symlink is a small file containing a path, so it breaks if the target moves and it can cross filesystems and point at directories, neither of which a hard link can do.
How to approach it
Define both in terms of the inode, because every difference follows from that. Then give the case where the choice matters in production, since that is what turns a definition into an answer.
A strong answer
A filename is a directory entry mapping a name to an inode number. The inode holds the metadata and the pointers to the data blocks. The name is not the file; the inode is.
A hard link creates a second directory entry pointing at the same inode and increments its link count. Neither name is the original, because there is no such concept: both are equal references. rm removes a directory entry and decrements the count, and the data is freed only when the count reaches zero and no process holds the file open. So deleting one name leaves the data fully intact under the other.
A symlink is a separate file whose contents are a path. Resolving it means reading that path and looking it up again, which is why a symlink to a moved or deleted target becomes a dangling link, and why ls -l shows it pointing somewhere that may not exist.
The constraints follow directly. A hard link cannot cross filesystems, because inode numbers are only meaningful within one filesystem. A hard link cannot normally point at a directory, because arbitrary directory hard links would allow cycles that break filesystem traversal. Symlinks have neither restriction, which is why almost everything user-facing uses them.
Where it bites in practice:
Log rotation. mv app.log app.log.1 on a running process changes the directory entry, and the process keeps writing to the same inode through its open file descriptor, so it writes into the rotated file and the new app.log stays empty. Prefer supported reopen signaling. copytruncate is a fallback with a race between copying and truncation that can lose log lines. Understanding this is the same knowledge that explains why deleting a large open log file does not free disk space.
Backups and disk usage. du counts an inode once per traversal, so a tree of hard links reports far less than the sum of its names. Snapshot backup tools use hard links deliberately for unchanged files, which is how an incremental backup can look like a full one at a fraction of the space.
Permissions. Permissions live on the inode, so changing them through one hard link changes them for all names. A symlink's own permissions are meaningless; the target's apply.
What interviewers probe next
"How do you find all names for a file?" Get the inode with ls -i, then find /mount -xdev -inum <n>. Bounded to one filesystem, since that is the only place the number applies.
"What does the link count on a directory tell you?" On filesystems exposing the traditional count it is two plus immediate subdirectories. Filesystem features can report a sentinel or different count, so do not use link count as a portable directory inventory.
"Why can rm free no space?" An open file descriptor holds the inode alive after the last name is removed. lsof +L1 finds them.
Common mistakes
Calling one of them "the original". With hard links there is no original.
Missing that permissions and ownership are inode properties, so they cannot differ between hard links.
Not connecting it to the open-file-handle behaviour, which is the same mechanism and the reason the question is asked at all.
References