Amélioration du modèle des offres d’emplois

[alexisjanvier]

Notre modèle d’offre d’emploi est encore très minimal, et se calque sur le modèle décrit dans schema.org

{
  "title": "Developpeur Javascript",
  "url": "https://jobs.caen.camp",
  "datePosted": "2010-03-02",
  "employerOverview": "Au sein d'une équipe DSI composée de juniors et de séniors",
  "employmentType": "CDD",
  "experienceRequirements": "3 ans d'experience sur un projet Javascript",
  "jobStartDate": "2020-05-02",
  "skills": "JavaScript, Devops, Php, ...",
  "validThrough": "2010-05-05",
  "hiringOrganization": {
    "identifier": "a122edec-5580-4a93-aff7-fc18b41e4c57",
    "name": "Incaya",
    "image": "https://www.incaya.fr/static/logo-incaya.svg",
    "url": "https://www.incaya.fr/",
    "address": {
      "addressCountry": "France",
      "addressLocality": "Caen",
      "postalCode": "14000"
    }
  }
}

Mais cela ne répond pas forcement à vos/nos attentes en tant que développeurs !

Que souhaiteriez-vous ajouter à ce modèle ? Quelles sont les informations qui vous intéresse vraiment lorsque vous regardez une offre d’emploi ? Et celle dont finalement on se moque ? Quelles sont les informations que vous aimeriez avoir et que vous ne trouvez jamais ?

[Clebiez]

La rémunération, qui peut parfois être "minimale", ou une fourchette.

employerOverview pourrait être plus qu'une simple string pour permettre de faire des sections / sous-sections.
Idem pour : skills qui parfois est aussi appelé "Profil recherché" et qui se compose d'une liste d'aptitude plus ou moins obligatoire. Pas tout à fait des skills au sens métier mais par exemple "Autonome, à l'écoute" ce genre de trucs.

Un "Qui sommes nous" de l'entreprise pour contextualiser l'offre ?

jobStartDate peut parfois être "dès que possible" compte tenu de la difficulté de recruter dans nos secteurs

Après je pense que les entreprises qui accepteront de mettre des offres sur ce board nous dirons les manquants :)

[Nexoid]

La rémunération, qui peut parfois être "minimale", ou une fourchette.

+1 pour la fourchette de rémunération :)

employerOverview pourrait être plus qu'une simple string pour permettre de faire des sections / sous-sections.

Pour l’employerOverview, je sais pas trop quoi penser, ca ressemble plus à une preview.

JobPosting étend de l’objet Thing, il a donc une description qui semble adéquate pour contenir le markdown de l'offre.

Idem pour : skills qui parfois est aussi appelé "Profil recherché" et qui se compose d'une liste d'aptitude plus ou moins obligatoire. Pas tout à fait des skills au sens métier mais par exemple "Autonome, à l'écoute" ce genre de trucs.

Pour skills, peut-être que l’association d’une technologie et d’une valeur basée sur une échelle de compétences ex:[notion,maitrise,expertise] suffit ? A nous de voir comment l’afficher ensuite mais je partirai plus sur un array (peut-être DefinedTerm) qu’une string.

Un "Qui sommes nous" de l'entreprise pour contextualiser l'offre ?

Je pense que la propriété knowsAbout dans Organization est appropriée pour ca si j’ai bien compris la description !

Sinon, j’ajouterai bien la propriété jobLocationType pour les offres en télétravail/etc.

EDIT: il y a aussi jobImmediateStart pour le "dès que possible"

[alexisjanvier]

La rémunération, qui peut parfois être "minimale", ou une fourchette.

C'est vrai que cette info manque pour le moment. Dans schema.org, on a un baseSalary qui peut être de type number ou PriceSpecification (avec un min et un max). Cela semble pas mal, non ?

employerOverview pourrait être plus qu'une simple string pour permettre de faire des sections / sous-sections.

Alors je ne sais pas si il vaut mieux se baser sur le employerOverview ou le description de things, mais je sais que l'on a prévu d'implementer du markdown pour ce type de champs un peu "large". (Voir #43 - Permettre le formatage des contenus en markdown).

Idem pour : skills qui parfois est aussi appelé "Profil recherché" et qui se compose d'une liste d'aptitude plus ou moins obligatoire. Pas tout à fait des skills au sens métier mais par exemple "Autonome, à l'écoute" ce genre de trucs.

Effectivement, cette notion de skills est hyper interessante et mériterait sans doute un peu plus qu'un simple champs texte. J'aime bien l'idée d'avoir une organisation un peu poussée de ces skills (en DefinedTerm ?), d'autant plus qu'une telle implémentation pourrait aussi servir à qualifier les organisations, voir même les profils si un jours on implémente les profils d'utilisateurs/développeur !

Un "Qui sommes nous" de l'entreprise pour contextualiser l'offre ?
Je pense que la propriété knowsAbout dans Organization est appropriée pour ca si j’ai bien compris la description !

On a déjà implémenté une description au niveau d'une organization. Je comprend ce que sous-entend la différence entre cette description et ce que pourrait être un KnowAbout. Mais je me demande si pour le moment, on arrivera déjà à avoir des description de qualité !?

Sinon, j’ajouterai bien la propriété jobLocationType pour les offres en télétravail/etc.

Carrément, je 👍

EDIT: il y a aussi jobImmediateStart pour le "dès que possible"

Pareil je 👍 :)

Et donc si je récapitule, cela ferait :

• Ajout d'un baseSalary au modèle de jobPosting basé sur schema.org
• Ajout d'un jobLocationType au modèle de jobPosting basé sur schema.org
• Ajout d'un jobImmediateStart au modèle de jobPosting basé sur schema.org
• Trouver un moyen de gérer les skills autrement que dans un champ texte (stacks-api ?)
• Implementation du markdown sur certain champs (Voir #43 - Permettre le formatage des contenus en markdown)

[alexisjanvier]

Bon sinon, en ce qui concerne ce que j'aimerais avoir sur une offre d'emploi et que nous ne trouverions pas encore sur notre jobBoard, voici ma liste :

• des liens vers du code produit par l'entreprise. Idéallement, pouvoir voir comment se déroulent les reviews. Alors cela passerait certainement par des lien vers Github, gitlab, ... Mais bref, du code !
• des liens vers ce que communique l'entreprise (blog, etc ....)
• avoir une idée de la stack favorite de l'entreprise (à la StackShare)
• voir qui travaille dans cette boite, et idéallement pouvoir entrer facilement en contact avec eux
• l'implication de l'entreprise dans le "reseau" (par exemple leur participation aux CaenCamp.s ;) )

[Clebiez]

Ah oui +1 !

Les entreprises de plus ont parfois un système d'apply qui est spécifique.
Ca peut être :

• passer sur leur website sur un form dédié
• Envoyer un e-mail
• Utiliser une solution tierce

Peut être du coup fournir un champ ou un lot de champs permettant de définir quel est le type de contact à entreprendre. (e-mail, form) et le lien qui s'en suit (adresse e-mail, l'url du formulaire)

Pour le logo de l'entreprise, il y a une super API gratuite de clearbit qui permet de récupérer facilement les logos des entreprises à partir d'un e-mail ou d'un nom de domaine.

https://logo.clearbit.com/marmelab.com
https://logo.clearbit.com/yousign.com
https://logo.clearbit.com/orange.fr

Cependant pour utiliser ce service il faudra respecter cette mention :

Using our Logo API requires a link back to clearbit.com on any page the logo is displayed. Attribution must be legible and use at least a 12-point font.

[alexisjanvier]

Yep. Je vois pas mal d'offres aussi passées sur Slack avec un pdf ... On pourrait ajouter un input file pour permettre de joindre les versions pdf des offres ?

[gaelreyrol]

Qu'est-ce qu'on acte du coup pour l'amélioration du modèle ?

[alexisjanvier]

Et bien, je dirais :

• Ajout d'un baseSalary au modèle de jobPosting basé sur schema.org
• Ajout d'un jobLocationType au modèle de jobPosting basé sur schema.org
• Ajout d'un jobImmediateStart au modèle de jobPosting basé sur schema.org
• Ajout d'un champ file pour l'annonce en pdf, docx, odt ? déclaré comme https://schema.org/DataDownload dans l'API

Et puis ensuite, passer sur :

• Trouver un moyen de gérer les skills autrement que dans un champ texte (stacks-api ?) => Faire une issue ?
• Implementation du markdown sur certain champs (Voir #43 - Permettre le formatage des contenus en markdown)

[alexisjanvier]

Bon, et bien je prend la première liste d'évolutions alors !