support multiple positions within same job

[mattknox]

ATM, to represent a 5-year stint at a company during which you did many different jobs, you'd need multiple jobs entries. perhaps it would be best to have positions be an array of objects?

[thomasdavis]

Personally I would rather create a new work entity. Because as your position changes, your summary and highlights should too. I believe most people do this on resumes now and LinkedIn also does this.

[vote539]

A schema similar to the one I proposed for organizations in #54 may be appropriate here.

[ocram]

@vote539 I would rather adjust your proposal to work the way @thomasdavis suggests.

[osg]

As one gains more experience(s), and the need for consolidation arises, the support for multiple positions for the same company proves useful.

At one company, I was a Technical Writer Intern, Technical Writer I, and finally a Technical Writer II.
At another company, I was a Senior Technical Writer and then a Technical Publications Manager.

That said, it is something that could be added later.

[DonDebonair]

I don't agree with that. If you feel the need to list all those different positions, you might as well create new work entities for those positions. I you're really consolidating, you would probably merge the highlights of different positions you had in the company and put them under 1 work entity.

I think we would be over-engineering it if we were to support multiple positions in the same company. You can use different entries for that.

[osg]

Said another way, a negative goal is to have one company listed three times just to accommodate different positions within it.

[DonDebonair]

Why is that a negative goal? I doesn't bother me personally :) I see it a lot on LinkedIn as well: having multiple positions at the same company listed as different "work" entries.

[osg]

This issue is not that important to me ATM; I withdraw. :)

[DonDebonair]

Proposal: close this issue and only allow for one position per work entry.

+1 if agree. Please vote.

[osg]

+1

[thomasdavis]

The redundant data bothers me, whereby you would have to list the same company and website x times.

@mattknox I think your suggestion makes sense. Though I like to think this project is trying to be much more casual than other specifications. The more nested properties and arrays there are, the harder everything will be to get off the ground.

EuroPass has a great complete specification -> http://interop.europass.cedefop.europa.eu/data-model/json-resources/v3.1.1/examples/europass-cv-example-v3.1.1.json

But getting an ecosystem thriving around it might prove difficult, whereby we can make ground in development by remaining as simple as possible.

My vote goes to closing the issue for now and marking in README to revisit later.

[osg]

+1 for revisiting later

[DonDebonair]

I added it to the README for revisiting later. Sorry for the bogus commit message, I saw that too late, after I already committed it.

[azzamallow]

My 2 cents.

A project I am working on has the need for nested positions within a particular job. This is important to us as we are largely dealing with consultancies, where an employee will work with many clients while representing a single organisation.

Our customers (the consultancies) want to hand resumes to their clients clearly indicating which positions their employees held with them, and which positions their employees held with other companies/consultancies.

[mruhlin]

There is a credible difference between the guy who gets promoted every 2 years and the guy who gets fired or quits every 2 years, so there's a good use case for one entry with a clear startDate and endDate covering the whole stint.
HR could merge by company name, but can an applicant rely on that?

[telekid]

+1 for supporting multiple positions within a single job rather than relying on duplication of company data. From a data-structure perspective, a position is a natural subcategory of an employer. Asking users to duplicate an employer's information across multiple entries increases the probability of non-uniform data, and makes visually representing positions as a subset of employers difficult and unreliable.

Something like this makes sense to me:

"companies": [{
    "name": "Acme Inc.",
    "website": "www.acme.com",
    "positions": [{
        "location": "New York, NY",
        "corporateTitle": "Vice President",
        "title": "Chip Manufacturing",
        "startDate": "2012-05-03",
        "endDate": "2015-04-30",
        "highlights": [
            "Did something awesome involving math"
        ]
    }]
}]

[JSchwerberg]

+1 to @telekid 's suggestion. I think being able to list multiple positions for one company would be beneficial for people who have held many positions at one institution, so that they don't have to waste valuable resume real estate by listing the same company name multiple times.

[mboudreau]

@mattknox My opinion on the matter is that data is data, and visualization is another thing. I see no issues with having different entries for the same company, but if you are to display it, you can always try to find other companies of the same name and display them in a group.

As a developer, I try to use the idea of "make the simple easy and the hard possible". I think the current schema is more than fine since one person moving within a company, I would imagine, is more of an edge case than the norm (can we get data on this somehow?).

However, I do agree with @thomasdavis around data redundancy and I for one love efficient data. One way of doing it would be to take an example from AWS CloudFormation's templating schema that uses a 'Ref' object to reference variables/constants.

For example, this is a simple, valid cloudformation template

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "Example Project",
    "Resources": {
        "InstanceProfile": {
            "Type": "AWS::IAM::InstanceProfile",
            "Properties": {
                "Path": "/",
                "Roles": [  "EnterRoleNameHere" ]
            }
        },
        }
}

But this is with the knowledge that the role has already been created before using the template and you already know the name. However, what if you wanted to create the role as part of this template? This is where the 'Ref' object can be used, like this:

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "Example Project",
    "Resources": {
                "Role": {
            "Type": "AWS::IAM::Role",
            "Properties": {
                "Path": "/"
            }
        },
        "InstanceProfile": {
            "Type": "AWS::IAM::InstanceProfile",
            "Properties": {
                "Path": "/",
                "Roles": [ 
                                        { "Ref": "Role" }
                                ]
            }
        },
        }
}

As you can see, the role that was created can be referenced in another entity without the ugly swapping of string names. Maybe JSON resume can do something similar to this?

{
    "work": [
        {
            "company": "Company",
            "position": "President",
            "website": "http://company.com",
            "startDate": "2013-01-01",
            "endDate": "2014-01-01",
            "summary": "Description...",
            "highlights": [ "Started the company" ]
        },
        {
            "company": {"ref": "work[0].company"},
            "position": "President",
            "website": "ref": "work[0].website"},
            "startDate": "2013-01-01",
            "endDate": "2014-01-01",
            "summary": "Description...",
            "highlights": [ "Started the company" ]
        }
    ]
}

However, I'm not a fan of using a specific index to reference something in an array. A better way might be to add a new potential property to add these references like variables:

{
    "parameters": {
        "CompanyX": "CompanyX",
        "CompanyXWebsite": "http://companyx.com"
    }
    "work": [
        {
            "company": {"ref": "CompanyX"},
            "position": "President",
            "website": "ref": "CompanyXWebsite"},
            "startDate": "2013-01-01",
            "endDate": "2014-01-01",
            "summary": "Description...",
            "highlights": [ "Started the company" ]
        },
        {
            "company": {"ref": "CompanyX"},
            "position": "Chairman",
            "website": "ref": "CompanyXWebsite"},
            "startDate": "2013-01-01",
            "endDate": "2014-01-01",
            "summary": "Description...",
            "highlights": [ "Started the company" ]
        }
    ]
}

Just a thought. Personally, I think the current way is fine and there's ways around this particular issue.

[stp-ip]

I think the current solution would be to have work.projects. So each project has a role assigned to it and can represent an internal role switch or even just a project switch or could be used for client work etc.
We discussed this in more detail in #201 (comment).

I think referencing would complicate the tooling around the schema more than necessary, but I agree this should be discussed. I think it's best to discuss the possibility of referencing via variables or otherwise within its own issue. Please open a new issue, with only the referencing and variable idea. The work itself was discussed in the linked issue and in my opinion would work for your use case also.