Re: Requirements feedback for jobs.postgresql.org. - Mailing list pgsql-www

On Fri, 12 Dec 2003, Josh Berkus wrote:

> In other words:
> Employers will enter jobs and their contact info.  The jobs but *not* the
> contact info will be made public.
> Applicants will fill out a form, and the system will e-mail its contents (and
> any attached resume) to the employer.


Ok. Understand it better now.
Wouldn't it be better to have the resumes on the service and to just have
prospective employees be able to have multiple resumes? This way when
there is an application they can tell the system which resume to point to
for that particular application.

Besides convenience for the prospective employee there is an extra
advantage. Reduced potential liability. If you EVER send attachments to
prospective employers what will happen if someone fakes an email as coming
from you and sends a trojan or a virus? Sure you will be able to prove
that it didn't come from you, but that is one employer that may shy away
from user the service. If you NEVER send attachements then you can even
wwarn people that any email coming their way with an attachemtn from your
service that the attachment should NOT be looked at.


> I disagree very strongly.  If this site gets as much use as we want it to, we
> need some kind of categorization to let searchers filter.   Pretty much every
> other job listing service in the world has job categories; I don't see
> bucking the trend on this one.

Really?
I have never seen categories in the sense you are talking about. My
experience is with Hotjobs, Monster and a few others. They have categories
like IT, programmer, etc.. but these are very general categories and most
of the time I have never used them to look for a job. I usually use the
'keywoard' search functionality.


> Certainly we want to stick to a small number of easy-to-understand categories.
> For example, I was thinking of:
> Database Administrator (DBA), Software Development, Performance Tuning,
> PostgreSQL Support, General System Administrator, Training, and Other.

Not a bad list, but the system should be flexible so the administrators
can add.

> We will not be storing applicant profiles on the system.   This would entail
> about 30 hours of additional work, half of which for security, and we're not
> going to do it.  Also, in the current economy, applicant profile storage
> would bloat the database and become and administrative headache.

So people are going to attach or cut/paste their resumes?
Sounds cumbersome. Just as you said above about doing something primarily
because every one else does it, storing the resume would go under the same
category. Plain text should not text so much space to store and could
possibly even be compressed.