How we think about skills

The [re]searching model

At the core of this website is the skill. This is intended to represent a word or a phrase that best describes an aptitude, and can include "hard" skills such as differential equations and python, as well as "soft" skills, such as communication and public speaking.

In developing [re]searching, I've tried to broadly follow the Stackoverflow model of tag creation, where users can create new tags if they cannot find a suitable existing tag. The upside of this model is that users are not constrained by the skills available in third party databases (such as itsyourskills, or through the LinkedIn API), and can add skills that are very specific to their field and area of expertise. This model also ensures that skills relating to new technologies can be added to the database.

The downside is that things can get very messy. While I encourage users to double-check the spelling of each newly created skill, there is currently nothing stopping misspelled skills entering the database, and ptyhon, pythen and python are all valid. To limit the build-up of misspelled and unused skills, I automatically remove skills from the database if they are no longer associated with any users (however in practice this requires a user to create a new tag, realise that it’s misspelled, and remove it from their profile).

To keep this under control, I plan on doing some manual curation of the skills database from time to time, as well as manually tagging skill ontologies. If you have any ideas for improving this system, or would like to contribute to maintaining the skills database, please get in touch.


Adding a new skill

Users can add new skills to the database if they don’t already exist. When adding a new skill, think about how other users will search for it in the future. Generally speaking, writing a skill in full is better, but sometimes using the abbreviation is more consistent with common usage. For example, pcr is more appropriate than polymerase chain reaction.

A skill tag is best used to express a discrete aptitude that works as a stand-alone descriptor. If the skill you want to add is ambiguous, it should not be added to the database. For example, writing is not a good skill descriptor. A better tag would add specificity: science writing, grant writing or technical writingare much more appropriate.

Similarly, analysis of data, analysing data and analysing experimental data would all be better represented by data analysis .

Use more skill tags to articulate specific knowledge. For example, if you have broad knowledge of statistics, but specifically use Bayesian statistics, you should register this as two separate tags: statistics and bayesian statistics. These are both more appropriate for your skill base, and will increase your chance of being found in the database.


Skill groups

[re]searching divides skills into two groups: academic skills and professional skills. Some skills will exist in both databases, but there will be many that are unique to one class.

The idea behind dividing skills in this way is to help mentees gain a better understanding of the types of skills actually required by a particular job or industry, and to enable companies to specify the skills that they like to see in incoming job applicants, as well as filter users on the skills that the possess.

Here are the top 20 (ranked by the number of users associated with each skill) skills in each class:

Top 20 academic skills

Top 20 professional skills