Added changes to parse experience

[RyanKramer]

Added some changes to parse the experience. I faced some issues since the experience is not the same across all resumes and some would have many jobs and others would have less. So I tried to pre-populate the number of columns and then add them in later for each resume. Take a look and let me know what you think and if you have recommendations.

[bjherger]

@RyanKramer ,

I think this looks really great! Thanks for the update. I've submitted a few minor knits / code style comments.

Additionally, I'm not seeing any values populated for the new field, for the 3 sample resumes in the repo (data/input/example_resumes). Could you include a resume that is processed correctly for the added fields, or generalize the new fields so that they capture the correct information from the sample resumes?

Thanks, BH

[RyanKramer]

@bjherger

Thanks for the quick review! I added the minor changes noted and added a few of the resumes that I was able to parse correctly.

So my approach will parse the experience but a few columns to the right so basically there is a manual cut and paste that has to be done as the end in order for it to work dynamically in the way I needed it to work for my case. I'm sure there is a better way of doing this but not sure exactly how to do so.

Ryan

[bjherger]

Hey,

A couple of thoughts on generalizing the new matching code:

• Location: Named entity recognition might work better (perhaps Stanford's NER. By default, it will spit out three categories: person, organization and location. The regular expressions you've added seem a bit finnicky, unless candidate's resumes are highly normalized
• Years worked: The regular expression currently in the PR is a bit restrictive. It might be worthwhile to evaluate other formats, such as MM/YYYY, MM/YY, MON/YY, MON/YYYY (check out this so. I fear that with the regular expression currently used, a user might think there is no work experience, when really it is in another format.

Could you provide an example output file, with the raw output, and the output how you'd like to have it formatted. Once I have a better idea of the formatting irregularity that requires manually copying and pasting, I might be able to help suggest an alternative.

[bjherger]

@RyanKramer This looks great! One last request: the resumes_output.csv in this PR appears to have more observations than there are resumes in data/input/example_resumes/. Please re-run on only the resumes in the example folder, and include that output.

This way, users will have sample output, and be able to confirm that they can repeat the process with a standard set of resumes.

[bjherger]

@RyanKramer Were you able to make the changes described in the last PR review?

[RyanKramer]

Hello Brendan,

I think my specific use case did not generalize well so I built it as a custom solution and then did a hard fork on your project.

Any new projects you were working on?

Ryan

On Apr 14, 2017, at 10:11 PM, Brendan Herger notifications@github.com wrote:

@RyanKramer Were you able to make the changes described in the last PR review?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bjherger]

Closing, as @RyanKramer has opted to do a hard fork for his specialized use case, rather than merging that code into this project.