The Perfect Job - Part 1

Zen And The Art Of Recruitment

It might not seem all that hard, but manning an organization's Human Resources division is actually a pretty difficult task. Sure, HR guys and gals don't have to worry about memory leaks, garbage collection or mangled code; however, their problems are often just as compelling and challenging as those of any software programmer or interface designer.

One of the most challenging problems for any Human Resources department is recruitment, the art of matching potential employees with vacancies within the organization. The process is complex: place an advertisement, wait for resumes to roll in, and then begin the arduous task of sifting through them in search of potential recruits. This is usually followed by interviews and reference checks of potential candidates, and perhaps a job offer.

Now, back before the Web was a buzzword, the only way to let potential employees know about a job was via advertisements, either in a newspaper or journal, or on television. And once responses started rolling in, HR would have the unenviable task of wading through mounds of paper to find the perfect match for the open position. Along the way, you could almost always expect to misplace or destroy a few of those resumes, sustain multiple paper cuts, and say goodbye to any hope you might have had of a social life.

However, with everyone and their deaf grandma now connected to the Web, reaching out to potential candidates has become much easier. A company can now either advertise vacancies through online employment agencies, or place job listings on their own Web site. Since online employment agencies aren't in the biz out of the goodness of their hearts, the latter option is usually the one smaller companies prefer, if only for economical reasons.

Of course, putting up jobs on a Web site is just the tip of the iceberg. Once those resumes begin coming in, there's still the task of organizing them into categories, wading through all the data to short-list candidates for interviews, and filing rejected applications for future use. Oh, yes...and just to make things interesting, there's usually a clock ticking away in the background as well.

With the help of powerful open-source tools like PHP and mySQL, the process can be simplified considerably. And over the course of this article, I'm going to demonstrate how, by building a job listing system suitable for a small- or medium-sized business.

The goal here is two-fold: to introduce novice and intermediate programmers to the process of designing and implementing a Web-based application; and to offer HR managers and other interested folk a possible solution to their woes.

Onwards!

An Ideal World

Before getting into the nitty-gritty of syntax and structure, it is important to understand the problems I am addressing, so that the functional requirements of the solution become clear. Very briefly, here they are:

1. Every placement call attracts a large number of resumes. Most of these resumes are printed documents, making it harder to search through them for potential candidates. Ideally, resumes should be made available electronically.
2. Resumes are not in a standard format. Different applicants use different templates, styles, and colours, making it harder to read and sort through the volume of data. Ideally, every resume should be in a standard format, with standard fields and some structure imposed on the data within.
3. With a large volume of responses, job applications may get misplaced or destroyed. Ideally, every resume, once entered into the system, should remain stored there with any data loss, so that it may be accessed at any time in the future.
4. Searching through a large number of job applications for specific skills or capabilities is a time-consuming process. Ideally, the resume database should be easily searchable against pre-defined criteria.

Having understood the problems, it becomes easier to decide on the requirements of the solution. An analysis of the problems above reveals that most of them would be resolved if I had a system which:

1. categorized resumes by job;


2. imposed a standard structure on the contents of a resume;


3. processed resumes electronically;


4. incorporated a search engine to easily produce a subset of the database matching specific criteria;


5. archived applications over a period of time;


6. allowed administrators to easily add and remove job listings from the Web site.

This, therefore, constitutes the initial feature set for the application, and serves as the guideline for future development activity.

Entry Point

At this point, I have also come up with a few ideas as to how this system is likely to work.

Conceptually, I can consider this system to be split into two parts: a user section, and an administration section. Here is an initial draft of the basic flow and rules that I plan to build into this application.

1. In the user section, the entry point for a potential job applicant will be a job listing, which will display a list of open positions within the organization. This should, in turn, allow the applicant to select a specific job and obtain detailed information on responsibilities, qualifications, salary and other basic information.
2. The applicant will also have the option to fill up an application form online, and provide the organization with personal information, qualifications, experience and other information typically found in a resume. This data will be stored in a database, accessible and searchable by administrators.
3. In the administration section, administrators will have the option to add, edit and delete job listings.
4. The administration section will also contain a search form, to help administrators search stored applications for specific skills or qualifications.

Copyright Melonfire, 2000. All rights reserved.