Résumébly

Résumébly (or resume résumé ably) is a service for managing the content of your résumé.

When you look at your résumé it may not seem obvious at first but it can be divided into two parts: content and presentation. The content part of a résumé is made up of sections, each which can recursively contain of subsections until eventually you reach the smallest subsection, which is generally represented as a bullet. The mathematical model for such a structure is a tree. Each node in this tree contains some arbitrary data which is used when visually displaying that section, and a list of children representing the subsections of that section. Each sibling in a list of children has a similar data structure, and is usually displayed in a similar way. For example, a simplified version of my résumé could be represented like:

var resume = {
    label: 'Résumé',
    children: [{
        label: 'Experience',
        children: [{
            title: 'Software Developer',
            company: 'Noom',
            children: [{
                label: 'Designed new features'
            },{
                label: 'Optimized algorithms'
            }...]
        },{
            title: 'Software Developer',
            company: 'Tagged',
            children: [...]
        }...]
    },
    {
        label: 'Education',
        children: [...]
    }...]
};

The structure of a résumé plays well into a paradigm of software development called templating. Templating is a way of easily defining how an object will be visually represented based on the structure of the object, not on the content of the object. The way it works is by defining a template of what an abstract object would look like, and then binding that template to data in order to create a visual representation of the object. For example, the leaf nodes in my above example all have a similar structure, one property with the key ‘label’:

{
    label: 'Designed new features'
}
...

The way I represent these objects in my résumé is with bullets:

• Designed new features
• Optimized algorithms

But instead of defining those bullets explicitly, I can define them abstractly in a template:

<ul>
    {{#each this.children}}
        <li>{{this.label}}</li>
    {{/each}}
</ul>

After binding my résumé data to this template I get the markup that generates the bullet visual representation above.

<ul>
    <li>Designed new features</li>
    <li>Optimized algorithms</li>
</ul>

To summarize, we’ve shown that a résumé can be broken down into content and presentation, and the content part of a résumé can be mathematically modeled by a tree, which lends itself nicely to the presentation paradigm of templating. Résumébly’s purpose is to utilize these properties, and others, to provide a service that makes maintaining your résumé easier and creating new résumés (dare I say) fun.

So what does Résumébly look and feel like? Well, for the MVP I’ll keep it simple. To start, you can either create a new document, or paste in the contents of a JSON file representing the content from an existing résumé. After doing so, an editing interface appears, displaying the root node. This interface shows you the “arbitrary data” attached to the currently displayed node, which is in the form of valid JSON. You can click on this data to change it. Beneath that, it shows you the array of children that this node has, each with a preview of the data in the child. You can click on a child in order to view that node as the root node in the editing interface and update it’s data. Beneath that, there is a button for adding a new child. Finally at the bottom there is a button which you can click to export a new JSON string of the content from your résumé. In the spirit of an MVP, that’s it. To generate your new résumé you must take this valid JSON and combine it with your own template.

This MVP is notably lacking some features, and since skeletons scare me I feel the need to at least mention them. First, since children of a section often contain similar data, I envision a feature allowing users to describe what data must be included in each subsection. Since the application now knows what fields will exist when a user adds a new child, the application can better optimize for editing those fields. Second, since navigating trees can be confusing, each section should require a unique identifier (name), and the path from the root to the currently visible node should be displayed at the top of the page. This gives users an intuitive way to navigate the contents of their résumé without becoming overwhelmed. Third, I envision there will be several common fields, such as lastUpdated and dateAdded, that deserve special attention. The application can simply manage these fields automatically, and condense their information in order to show cleaner interface to the user.

Since I’m reading The Lean Startup by Eric Ries, let’s list the leap-of-faith assumptions for this product:

• The aforementioned method of creating a résumé is better than the ‘regular’ way of creating a résumé
• People would create their résumé using this method if a service removed the high barrier of technical knowledge
• People would use this product

Also we should note that this product pulls inspiration from existing products. Static site builders have long made use of the templating paradigm to ease the process of content creation. Ghost, a blogging platform, recently raised over $200,000 to apply similar ideas to blogging. There are also many existing JSON editors (for example) which seem reasonably used (for example).

Before I say goodbye I think it’s important to dream big for at least a second. In an ideal world I imagine this idea growing in scope to include all the features I wish I had now when creating and dispersing my résumé currently. I’d like to be able to easily customize my résumé for different applications based on job titles and descriptions. I’d like to be able to easily swap out different styling for my résumé. I’d like to be able to programmatically access the data in my résumé so that I can use it other applications. I’d like to be able to share résumés with other people so that I can build upon their ideas. I’d like to be able to create multiple versions of my résumé and A/B test them to see which is best.

Furthermore, this idea does not apply only to résumés. It applies generally to almost all text based content generation. For example: menus, cards and emails could be supported almost out of the box with a working solution for résumés.

Finally, like many of my ideas, this product revolves around my belief that people should track their personal data and feel secure in pooling this data to support the common good. This more fundamental hypothesis is being explored in a platform I’m developing called BlackBox, which will likely have its own blog post soon to explain it in greater detail.

If you think this idea is interesting I’d love to talk to you. Just tweet me @jomrcr. Thanks for reading :)