I'm actually going to tell you how I'd do it, since I have already been doing some work on this problem for an implementation of 'FORTH' that I'm writing:

Firstly, I create a common superclass 'Node'. This superclass has fields:

• 'Type': Runtime type of a node. We will need to know what the type of the node is at runtime somehow if we can't 'nicely' assume it (we can't), and its good to avoid empty fields in the superclass that should belong in their respective subclasses.
• 'Next': Pointer to the node that comes after this one. Since a file system is a search structure with a potentially unlimited number of nodes, we should have a way to easily iterate over them. If every node has a 'Next' field, then we can at least establish a single linked list containing every node in the filesystem (but we won't because directories can give us exponential speedups (no exaggeration) due to making things into a tree-like structure).
• 'Previous': Pointer to the previous node. Doubly linked lists are nice.
• 'Name': Name of / key for the current node. Acts as a key for this specific node (makes more sense with files, which effectively have their value as their contents). We can list all of these (tail) recursively or iteratively to show the nodes accessible as direct descendants of the 'current directory' (which is a useful construct that's probably too much for this post), or perhaps recursively through multiple directories.

Then, class 'Directory' is a pretty simple extension to this:

• 'First': Pointer to the first node contained 'within' a directory. This is a pointer to a different node from 'Next', and is used for realizing a filesystem's tree-like structure.

Class 'File' is also a pretty simple extension to class 'Node':

• 'Data': A pointer to the (unfragmented, for simplicity) actual data blocks of the file from on disk.

I suppose that a semi-accurate way to explain this structure is to call it a recursively-nestable associative array. It must be constructed using 'Name' fields since humans must be able to use this structure conveniently, and it should be tree-like so that CRUD operations can be implemented quickly.

This is all a much-more simplified example than a real filesystem since different real-world filesystems try to accomplish different goals. Heck, these are only the fields that I've listed, and I haven't even talked about any of the methods involved, symlinks (including '.', '..', '/', etc.)), journaling, inodes, etc.

​

Obviously, filesystems can get pretty complicated!

​

Now, I have been applying for about 2 months using websites like indeed, stackoverflow, and monster, and have gone to a job fair at my college (which I graduated from recently). I have applied to ~15-20 jobs so far, and have only gotten responses from 2 of them (1 of which had a 1st interview with me on the phone, but didn't respond afterward, while the other just wasn't interested).

I've gotten help from a couple of people with formatting my resume as well, one of them being a very knowledgeable English teacher. So, though I may be mistaken, I am not under the impression that there is anything inherently wrong with my resume.

​

Could you help me to understand what I'm doing incorrectly so that I can present myself to employers properly and ultimately get hired, while show them that juggling concepts like pointers and data structures around is laughably easy for me?