HR area

[shaedrich]

Motivation

Currently, vutuv is mostly profiles (plus a feed). This is helpful for purely presenting yourself by your digital CV. But aside from the feed, this isn't really interactive. When looking for work, one mostly has to resort to the feed and hope, someone picks up their cry for help or when looking for potential employees, one has to use the search function and sort through endless profiles. In this area, we might be able do better than LinkedIn if done properly. One can already mark their intent to look for work (#870), but that's about that right now.

Follow-up of #896

Solved in https://github.com/wintermeyer/vutuv/milestone/11

[wintermeyer]

We have to make sure that the different roles are all happy and that each of them benefit from using vutuv.

[wintermeyer]

Any job posting or job search has to have a default end of life date. Otherwise we are going to collect Karteileichen. Users can refresh that date but otherwise they will auto delete or at least not been displayed.

[shaedrich]

Scenarios

• Looking for work (Feature Request: Job application when looking for work #896)
  • Indicate job search on profile (already solved in Feature Request: Employment status #870) ✓
  • A profile box describing the job, one is looking for
  • Automatically creating a system message (kind: 'announcement') in the feed so it can be read by following employers and recruiters as well as shared by followers
  • A new search tab to search through people who are looking for work (target audience: employers and recruiters)
• Applying for a specific job
  • Sure, one could just write a vutuv message or use one of the other contact methods on the employer's page but this would be free-form and make it more complicated than it has to be. Just a simple form, pre-populated with the "looking for work" information the user might already have submitted plus private information, they user might not have wanted to share publicly with their "looking for work" announcement
  • If the person wants to send an email, we could at least open a form with a text area automatically attach the CV
• Looking for potential employees directly (employer)
  • Create a job posting
  • A new overview of everyone who applied for a job to manage applications
• Looking for potential employees via a middleman (recruiter)
  • Have a list of job postings assigned to them
  • Have a list of people looking for work to manage their status
• Miscellaneous
  • Show that you found the job with vutuv, possibly even credit a recruiter

Current road blocks

• vutuv currently does not have a concept of companies as vutuv has not agreed on a sound way to prove that this company is legit (Feature Request: Standardize education and experience fields #851), so we have no entity to issue a job posting. A company's employee on behalf of said company would work but this would result in the same verification problem that the person is authorized to post said job offer and/or receive an application
• vutuv currently has no concept of jobs (Feature Request: Standardize education and experience fields #851). We have a position field in the "Experience" section but this is a free-form text field and can not be compared with positions of other people

New data models

System message/announcement

Like a notification but shown in the feed

• subject
• CTA link
• date
• avatar (or system)

Looking for a job

• User (UUIDv7)
• Salary expectation (per month/year; public)
• Remote: 'yes'|'no'|'hybrid'|'no-preference' (public)
• Employment classification: 'full-time'|'part-time' (public)
• Shiftwork: 'yes'|'no' (public)
• Rotating shiftwork: 'yes'|'no' (public)
• Notice period (Enhancement: Notice Period #893; private)

Job posting

We could utilize https://jsonresume.org/job-description-schema

The job postings would need some kind of UI, we could use the search for this (#902)

• Company (free-form)
• Salary (per month/year)
• Remote: 'yes'|'no'|'hybrid'
• Employment classification: 'full-time'|'part-time'
• Shiftwork: 'yes'|'no'
• Rotating shiftwork: 'yes'|'no'
• (Earliest) Start date
• Description (free-form)
• Benefits (string[])
• Qualifications (Certificates & licenses section + recover LinkedIn's discarded Certifications.csv #859)
• The job description lists skills but since we don't have that (Feature Request: Skills #860), we could use tags
• Contact data if different from person making the job posting
• Required documents (string[])
• Status ('open'|'closed')
• Valid till (date, HR area #898 (comment))
• Subject to collective bargaining agreements ("tarifgebunden")

Job application

• job posting UUIDv7 if not a cold call
• see fields from "Looking for a job"
• Documents (Document[]?; Documents #899)
• Applied at (date)

Candidate (user_x_job_posting)

• User (UUIDv7)
• job posting UUIDv7
• Status ('open'|'declined'|'accepted')
• Decline reason (free-form?)
• Round (int)?
• Notes (string)

[wintermeyer]

What about head hunters who search for candidates? And what about head hunters who search for candidates while searching for a new job too?

[shaedrich]

What about head hunters who search for candidates?

Right, forgot about that (#898 (comment)) 👍🏻

Should be mostly the same data model as the one for recruiters just with the view being reversed.

And what about head hunters who search for candidates while searching for a new job too?

I'm not sure if I understand that correctly. Head hunters who look for a new job themselves would do so as a normal user. So this per se is a non-issue.

However, that raises the question about user roles that isn't covered in the proposal above that only focuses on objects rather than users.

We could approach this in two ways:

• The users table gets a new column (`kind: 'wage-slave'|'freelancer'|'headhunter'|'recruiter'|'employer')
  • Pro: No new table
  • Contra: Users would have to create a new account for each of their roles (probably not what we want)
• A new user_roles table
  • with the following properties
    • User: UUIDv7
    • kind: `'wage-slave'|'freelancer'|'headhunter'|'recruiter'|'employer'
  • Arguments
    • Pro: Avoids the problem above we would have when modifying the users table
    • Contra: We might need a select in the top navigation bar so users could switch their role in the future when they would need a UI tied to their role

Question is: Would the user_roles also spawn the need for role specific data (e.g. the relation of headhunters to people who look for a job or recruiters and employers)?

[wintermeyer]

Most important: What is the MVP version of this? Let's not start with the super duper version but one that helps and doesn't block any future features. I prefer small steps which itself make sense.

PS: Let's not forget that not everybody is looking for a new job or a new job candidate. Most people use vutuv for other stuff. So don't make their live worse with a new feature they don't need.

[shaedrich]

Since we haven't tackled the user roles and the company problem yet, we can only work the "Looking for work" side of things without changing too much. I would go forward by cherry-picking from what I outlined in #896: A profile box describing the job, one is looking for. This is non-invasive as it doesn't clutter the feed and is only descriptive in the profile when people view it directly. Recruiters and employers could already see this without roles or even without being logged in. In the future, we can add a setting or the like to hide it from specific user roles but I don't thing we need that right now.

[wintermeyer]

I fear that a lot of people will not feel comfortable with having to describe a job they are looking for. Job postings are much easier.

[shaedrich]

The job postings would need some kind of UI, we could use the search for this (#902)—wdyt?

[wintermeyer]

wdyt

I don't want to invest resources right now on new job posting or searching features. #901 and #900 are good examples of the work we need to do right now. I want to concentrate on this in the next couple of days.

[wintermeyer]

Since we haven't tackled the user roles and the company problem yet

Maybe we should first tackle the company problem. I don't know. I just want to outline that if we need companies than that should be the highest priority. Maybe we don't need them.