Adding Responsibilities and Accomplishments subsections to Experiences

[ktneely]

As ones moves into management and leadership, I think it is important to highlight the specific responsibilities and list accomplishments aligned with those responsibilities. Since the CV/resume is a reflection of that journey, it would have some older experiences using the highlights model, and move towards responsibilities & accomplishments in the more recent experiences.

To represent this, I've built some logic in the LaTeX templates that will check for the existence of two arbitrary keys and extend the template to check for their existence. Just as with the existing environments, the use of these two are completely optional. At the moment, I'm re-using the highlights environment, since I want it to all fit together.

When the new environments are used, the experience section looks like this for both Markdown and LaTeX:

# Experience

## Microsoft, Software Engineer Sr. Manager

- June 2003 – Aug 2003
- Redmond, WA

*Responsibilities*

- Build a world-class team
- Make them successful

*Accomplishments*

- Led the happiest staff in the business
- Managed a budget enabling us to GSD

*Highlights*
- If either of the other two are present, Highlights gets its own heading.  Otherwise, it follows the default.
- A single experience item probably wouldn't have all three...
- ...but maybe there is something you *really* want to reinforce

I think this would be a helpful addition to the options for crafting the CV. Would this be the kind of thing you're looking for? I'd be happy to make a pull request if it is.

[sinaatalay]

Thank you for the idea! I personally don't like the entry type logic; it's hard to explain to people how they can use such entries (hard to document it), and it's not straightforward to use, in my opinion. It's harder to maintain the templates too.

But this may be a good candidate for a new entry type: maybe ExperienceEntryWithSections?

If we create this as a new entry type, then the challenges would be

• Designing such an entry type. We will need to decide what the PDF will look like with the variable margins and other settings coming from the design field in the YAML.
• Designing it for all the themes.
• Implementing the design in $\LaTeX$ for all the themes.
• Maintaining it.

But it may be feasible, considering what we can gain from it. I am not sure. What do you think?

[ktneely]

I hear what you're saying: one of the great things about renderCV is that it is very simple and the fields are take-it-or-leave-it. While my PoC implementation of extra sections adheres to that design philosophy, it could get very messy, very quickly with many checks for the existence of n fields and then keeping that all consistent. It also wouldn't allow for the arbitrary placement of the sections, as my example is rigid in the order.

I like the idea of a new entity (or environment?) that enables the CV writer to create arbitrary sections. I would also say that it would be best if the implementation did not require the sections for every entry in experiences. As a hiring manager, I'm a lot more interested in the details from the more recent experiences and a short summary of older ones is good enough. This is why my current implementation will not even print a section heading if only highlights are present in a given - company: entry.