How to write and talk about your project

This document contains the general rules and themes around what you are and not allowed to communicate on a resume and in an interview about a previous job or project.

This should be considered guidance and a framework for thinking about what you can and cannot say about a project. Every project is different, and it is important to think through what you want to disclose.

There are three sections in this document:

1. What is always allowed to be disclosed
2. What should never be disclosed
3. The gray area and how to navigate it

What is always allowed to be disclosed

Basic information and logistics of the project are always allowed to disclose:

• How you worked, when you met, team size, etc.
• Basic information about who you worked with at the company, such as their title.
• Tools you used (Python, what libraries, etc.)
• Anything public about the organization
• What you would find on their website, etc.
• Publicly available code, documents and PR related activities.

Note that some project are 100\% public. In this case you are allowed to show and share the code. If the code is not public, code should neither be shared nor used in any context.

What should never be disclosed

Non publicly available code, code snippets, files and documents. Detailed model results or information that could be used to directly reproduce your analysis or results.

The gray area

The gray area includes things are almost always allowed to be disclosed, but when you do you need to be careful not to stray too far afield.

IMPORTANT: The “Gray Area” guidelines here are just that – guidelines. If you have specific questions around an aspect of the below, please reach out.

The problem statement:

• What were you working on?
• Why was it important to the company? (Motivation)
• The basic setup of the problem
• General descriptions of the information available, such as the form (images or text) and rounded numbers of items or elements.
  • Detailed descriptions of the data are to be avoided.
  • If the information is a paid-for or commonly used source, then it is usually okay to mention the sources name (“Bloomberg terminal.”)
• The techniques that you used, especially if they are readily available in a pre-built python or R package.
• General discussion of model assessment, specifically if those assessments are standard packages. (“Evaluated via F1 because…”)

Results:

• Information on process improvements:
  • “We increased speed by 10x” or “Our model performance beat the current model by 2%”
  • Accuracy and specific benchmarks should be avoided as they get darker in the gray area.
• Anything that is “obvious” from what the company does.
  • One way of thinking about obvious is asking yourself “Would I be surprised if a company didn’t do this?”
  • If the answer is “Yes” then it is probably all right to disclose.

Conclusion

Keep in mind that the above are general guidelines. If you have any specific questions reach out to the director of the data science clinic.