Files in ClearCase can only be changed when they are checked out.
But as you may know, flipping the read bit on a file is all it takes to get write access. So hijacking a file is a description of the process where you change the read bit on a file from read-only to modify on a file that is actually in source control.
This technique is only available in snapshot views - files in dynamic views can not be hijacked.
As soon as the file is hihjacked your editor or IDE is happy - now you can go and change the file. But your changes are not recognised by ClearCase. If you should attempt to check in the content of a hijacked file you'll find that according to ClearCase it's not even checked out - there's is nothing to checkin.
What you can do instead is to update your snapshot view, and before you kick off the process tell ClearCase to "Check out hijacked files". Files will then get the status in ClearCase that they are checked out, and consequently the check-in option for these files will become available - and you can check them in.
Things get out of sync when others have created newer versions of files that you have hijacked. The update process will then force you to merge the files into the files that are view private in you view.
The scenario resembles the way Subversion is implemented quite a bit.
Hijacking files is not as evil at the term hijacking indicates, it's a quite legitimate way to manipulate ClearCase versions and the only way that allows you to detach you ClearCase client for the network and still accomplish some decent work.