Finding people willing and capable of filling a position that is vacant is something desired by organisations and society in general. Typically society would prefer to see vacancies filled with people who are "local" and capable. If "local" isn't possible (for whatever "valid" reason), society would prefer the successful applicant to at least be a citizen of that country (or region). Being productive in the position is assumed to happen.
Deficiencies in finding productive employees/workers are distributed, some fall mostly on the employer, some on the employee, some on both, some on neither.
There are places where organisations can make improvements, where government may be able to help, and also where trade organisations may help.
One report suggests that about 4% of employees are both good at the position they are in, and enjoy it. In positions that don't involve a safety component, this type of statement probably has serious consequences for productivity. I've seen lots of postings in blogs (web logs, aka journals or diaries) that people are visiting various kinds of internet sites (the blog itself, social networking sites, porn, ...) during work, often because they are bored.
When safety is involved, this is hazardous. Gee, sorry I didn't see the warning light or hear the alarm, I was bored and was watching porn (or whatever).
I don't think that any employer can ever expect every employee to be functioning at maximum productivity at every moment they are on the job. If nothing else, our attention span isn't that long. A break of some kind is needed periodically.
Within the context of keyboard usage, doing something every 20 minutes to allow your eyes to focus at some distance other than about 18 inches is good for your eyes, and taking the opportunity to also stretch your hands is good. Many people practice this sort of behavior by drinking diuretic beverages like coffee during work hours. When you have to go to the washroom; your eyes, wrists and fingers get a break. It is probably a 5 to 10% hit on the "duty cycle" that is needed.
It is nice to have the occasional break, but we've all seen situations where it looks like the breaks are taking up most of the shift. A person might have some sympathy for a person in a service industry when there are no people to provide service to, but even then, there are usually things like cleaning or housekeeping which could be done.
In a time when there potential employees are in abundance, it's easy for management to curb this kind of behavior. Warn them a time or two, and then replace them with someone else. However, is this the best way? There isn't always an abundance of potential employees, at times they are downright scarce. What then? Hiring the best (or at least better) employees in the first place might have been the tactic to use.
Depending on jurisdiction, discrimination because of race, religion, gender or other reasons may be illegal. Proving an employer is discriminating illegally can be difficult. While you can't prove anything using statistics, you can look for tendencies. Most courts will not accept statistical arguments for discriminatory practices, funding agencies could practice discrimination on employers who appear to be discriminatory. In some jurisdictions, a person's surname can be a reaonable indicator of race and/or religion, while most first names are good indicators of gender.
If application forms are handled internally as accepted, it is inevitable that the people grading various aspects of the application form see the applicant's surname and probably their first name. (Some women just put an initial for a first name, but if all men use a first name, ....) So, the opportunity is there for concious or unconcious illegal discrimination to take place when the applicant's name is known. In many places, people of similar race or religion tend to live close to each other, so knowing an address can lead to illegal discrimination. I'm not aware of any mapping sites that might allow one to "look up" someone's race or religion based on their address, but the technology is available. It needed be limited to that, it could contain all kinds of discriminatory (or non-discriminatory) information.
Unconcious discrimination would include being less tolerant of spelling mistakes.
Doing something as simple as putting a label over the name with some random string for the name would be a start on minimising misuse (intentional or not) of information which might contain discriminatory information. What would be better is data entry and recoding. In either case, the people who are charged with actually accepting the applications (and hence knowing the relationship between the applicant's name and the random string) should not take part in further processing of applications. The advantage of data entry and recoding, is that many random strings can be assigned for use with a single application, one for each kind of information present in the application.
Historically there are 2 application formats: the organisation standard application form, and the resume. Typically, resumes are accompanied by a cover letter. With the development of the Internet, various electronic formats have been developed.
In an environment where one wants the fastest processing of applications with as much flexibility as is possible, it is hard to argue against electronic formats. The problem with electronic formats, is that not everybody has an email account, internet access, a computer, etc.
In an environment where paper applications are allowed, or even preferred; there is a strong tendency for people to think in terms of what their application looks like on paper, and hence word processor formats. These formats are at least as difficult to handle in an automated way as a plain ASCII text file.
If paper formats are allowed, one option is to have someone manually re-enter all of the data into an electronic format. There can be errors re-introduced at this point, and it is probably expensive. Optical Character Recognition (OCR) is an option, but the better typefaces for reducing errors in (OCR) scanning tend not to be chosen by people trying to print out applications and/or resumes. Some typefaces cause more problems than others, and you still have this problem with errors introduced into the electronic format of the data.
If your organisation decides to only allow electronic submissions, some means of allowing people who do not have email, Internet access and/or computers needs to be considered. It's entirely possible that there are government offices, libraries, employment agencies or other offices which have facilities to which you can direct people without their own facilities.
The most portable format for electronic transmission of applications is the plain ASCII text format. It works everywhere, but has problems. ASCII is really only meant to support English and its alphabet, support for other languages can be sketchy or non-existant. The most portable formats that are similar in intent to ASCII are to use character sets specific to the language, or multi-purpose characters sets like UTF-8.
There are a number of electronic file formats that are based upon what something looks like on paper. These formats contain data (the information you want to present) and "markup". In terms of presentation on paper, markup contains instructions like:
A newer technology involving markup is a master language for building smaller languages in, called XML. There are 2 XML based languages for describing things related to jobsearch: HR-XML and XML Resume Library. HR-XML is an effort by a consortium of companies to design a language for general use in the HR industry. XML Resume Library is a language designed by a small community of people who are looking for something to describe resumes.
The XML Resume Library format is not likely to contain everything a business may want, as it was designed for people trying to present what they would prefer to present. The HR-XML format could easily be too big, since it seems to have a much larger purpose than just being used for applications. In any event, you might find something to start from with either language.
A properly chosen (or developed) XML language is largely preparsed. A program analysing the data in an application can automatically extract the data it needs and use it. You might have a program which verifies addresses. Addresses can occur at many places in an application, but they all have the same format. A single program just grabs all the addresses that are in the data, and files them appropriately. If you are storing the data into a database, the preparsed structure of the language helps direct all the parts (if present) to the correct tables and columns of tables (you need to have designed the database properly in general).
In the distant past, a man could find employment in a position, and later in life find that his son grew up and found employment in the same position. Few positions seem that stable and non-changing these days.
With a stable, non-changing job, it is easily possible to sit down and write a well defined job description. In some of the technologies we have today, an entire lifecycle for technology might take place in less than 5 years. The 16M DRAM chip had a lifecycle of about 10 years (sigma=1.6 years, 6 sigma=9.6 years). Current automotive design lifecycle is in the range of 24-36 months. Writing a job description in such an environment might be a bit more of a challenge. I suspect doing so is even more important.
I would recommend putting these job descriptions in a public place, like a web site. If somehow a job description is sensitive data, you could provide applicants and employees with passwords (and use password aging) to access this. Any advertising of a vacancy should use either the job description in its entirety, or a significant subset. Be careful consolidating groups of specifications into something ambiguous.
The best things to put in the job description are exacting and precise, directly measurable or can be easily verified. If you are looking for a rough carpenter, asking for the ability to frame a certain size house in 1 day, or to frame a roof of a certain size with a hip on it would probably be precise enough. This assumes that the job involves either framing houses or building hip roofs for houses. In programming, you might ask for experience in some very specific programming, or an example of a program written by the programmer in that environment which could be verified.
Avoid using acronyms in job descriptions, and advertisements of vacancies to be filled.
Some parts of an industry might use an acronym while other parts might never have seen it. What the heck is TDG? After a bit of digging you discover they are talking Transport of Dangerous Goods. Sure, I know the regulations exist, I used to ship radioactive tracers by aircraft. Never heard of them being called TDG though.
Asking for experience is an example of an ambiguous term. Asking for experience in something non-specific is making it even more ambiguous.
A good place to start is to look up definitions of experience in a number of good dictionaries. There is quite a spread of definitions. Some definitions use concepts seemingly at odds with hiring practices, experience by induction is a good example.
I would think a number of points about experience are self-evident:
Different people will reach the point of dimishing returns, or even a peak in experience, after different (long) periods of time. This shows up in differing amounts of fractional retained experience and how much experience they retain at the beginning.
That a person who reaches diminishing returns (or peaks) later will be a person who retains a larger fraction of the experience gathered might be self-evident to some. A very simple modelof this phenomenon adjusted so the point of dimishing returns is about like 50 years, shows that this person is only retaining about 35% of the experience. Two people who retain the same amount of experience won't necessarily retain the same experiences, and so are of different "worth" anyway. At 33% retention, which would be a higher fraction than most people would attain, they are still forgetting twice as much as they retain.
If a particular person is one who reaches diminishing returns early (little retention), a common practice of extending vacations after a certain number of years of service can actually cause the appearance of a peak in the retained experience curve, with a drop off after the peak. Certainly organisations do not seek to decrease the value of employees?
This opinion is probably contrary to general beliefs in the Human Resources (HR) industry, but HR people are in general only qualified to access the qualifications of people applying for HR jobs. There may be some people in HR who had qualifications outside of HR before they entered HR, but in general even that shouldn't be considered carte blanchefor judging qualifications in that general area. It should only be applicable to the special areas of that area that they had experience in, and that exception should be something which decays in time just like any experience does. In jobsearch.pdfI specifically consider an example of chemistry, but it should be obvious from that example that HR people are not generally qualified to assess qualifications.
In general, the only group of people who are capable of assessing the qualifications of applicants for some vacant position, are the various managers of that position (manager, the manager's manager, ...). In some situations, there might be a group like a trade association which might have people in place who have the qualifications to assess applicant's for that position.
The object of grading and ranking, is to produce as short a list of people to be intervewed (or directly offered positions) as is practical. While you can use just about whatever you want to grade applications, the best things to use are criteria from the job description. For example, if spelling is grounds for rejecting applications, it should also be grounds for getting fired.
If the decision is made to recode applications, a computer is inevitably going to be used. The data is probably going into a database of some kind, although an assortment of files is possible to. In either case, computer programs can be used to perform at least partial grading, if the application has the data.
Verifying data presented is important for (at least) two reasons:
Verifying the data in an application is one of the few times where one has an abundance of data which is more or less easily verified as to its truth. Older data is more difficult to verify than newer data; businesses move, get bought or cease to exist, street names change, phone numbers change.
Government and trade associations could help the hiring process by running storehouses for various kinds of "public" information that might be helpful in the data verification process.
Removing irrelevent grading criteria (like spelling) will reduce the ability of grading and ranking to produce a short enough list for interviewing or offers. Adding a small number of tests can more than make up for this. Automated tests need not increase the demands on your staff, if carefully designed.
Many people will "cheat" if they are given the opportunity. Take spelling, for many people the only time they ever check their spelling is for job applications. I think that tests are best developed at the trade association level, which helps to reduce the burden on any member firm of the trade association.
Many people will attempt to find all the questions which have ever been asked, if they know a test is involved. The purpose of this is usually to memorize answers, not to learn material. Depending on the tasks involved in the job to be filled, memorization may or may not be a good idea. For a job on an assembly line, memorization is probably effective. For most jobs, I suspect it isn't effective. Whether you want potential applicants to memorize your process is up to you. Computers and robots are typically far better at memorizing than humans are.
I would recommend that if you are going to test applicants, that you have a much larger number of questions to draw from, than you will show to the applicant. This gets around the memorization problem for the most part (some people can memorize a phenomonal amount of stuff). If you don't have any better information to draw from, you can guess that the standard deviation of a test is going to scale as the square root of the number of questions. If you have 100 questions, the standard deviation is going to be around 10, which happens to be 10% of the number of questions. A person skilled in statistics can better inform you as to the "resolving power" of your tests to differentiate one candidate from another. Having ten thousand questions in a test in order to have a standard deviation on the order of 1% isn't going to happen. At 1 question per second, that is almost a 3 hour test. Having a series of shorter tests at increasing difficulty levels would be much better. If nothing else, you would like tests to be limited to 20 minutes (time between refocusing at distances other than 18 inches mentioned above).
Testing can be automated, but if you choose to do so, you should approach things in a paranoid way. I am assuming that this is being done over the Internet, which makes for much more pessimistic circumstances. The questions to be applied, should be drawn from a much larger population of questions. The questions should be downloaded over a secure (like ssh) connection between the question server and a user program, probably written in Java. For each question, the answer should be remembered, as well as the time it took for the user to answer the question. At the conclusion of the test, all the data should be uploaded to the testing site. The testing software should probably apply partial MD5 sums (or similar) on the series of questions answered, in order to detect tampering. At any given stage, an MD5 sum would be taken from all the questions answered to that point, and the MD5 sum at the last stage. To avoid problems, some random data shuld be downloaded at the same time as the testing program is, which is included in the MD5 sum.
The test server should keep track of how long a question set has been lent out. Any sign of tampering should probably be treated as a reason to reject an application. The MD5 algorithm is no longer considered as secure as it once was, but for the near term it probably should work fine. Rejection could be done for tampering, or for "excess time".
An applicant decides to start a test by downloading it. It is probably best if what is downloaded is a combination of test program and data. Once downloaded, Internet access is not needed again until the test is finished to upload results. The transmission of program and data should be encrypted. Once downloaded, the program starts up, prompting the user for display of the first question. When the user chooses to display the next question, a timer starts. The timer stops for that question, when the question is answered. The download should probably also contain some random data, I would guess one piece per question. When a question is answered; the answer submitted, the time to submit, the random data (for that question), and the MD5 sum up to that point are all run through a new MD5 checksum calculation. Once the test is complete (or abandoned), for each question we send back the answer, the time to answer, and the MD5 sum at that point.
The site the tests is downloaded from, needs to keep track of what questions it sent, and what random data it sent. From that, it can verify that the results received are consistent with what it sent. The results still need to be analysed.
The employer web site needs to verify that the questions shown to the applicant are in fact the questions which are answered (sent back for marking). Answers that take "too long" to be answered might indicate that the answers were being researched. This isn't necessarily a problem, but that would depend on the employer. Answers that don't take long enough, could be evidence of memorization or some kind of fast lookup (even another program answering the questions). Answers that all take the same length of time to answer, might also be suspicious.
The easy thing would be to take all the scores, add them together, and divide by the number of tests to get an average score. However, I really doubt that all the tests are equally important, which is what that average implies.
The first thing to do is to look at the attempts at verifying the factual information in the application. If you're lucky, everything will verify. Another possibility is that enough stuff could not be verified, that you are unwilling to further consider the application. And there is likely to be some middle ground, an amount of data which couldn't be verified, but doesn't look unusual or explainable. Some people are not good at fabricating data, and it looks unusual. Situations like street names changing their name and area codes changing, can make some data difficult to verify, but it is explainable.
If the applicant passes the verification step, you are reasonably sure of their qualities, and reasonably sure of their honesty, accuracy, precision and forthrightness. The employer needs to determine a set of weighting factors for combining the various test results. I would think that this might also be a place where a trade association would be a logical place to look to for advice, as all the employers in the trade association would have somewhat similar ideas as to what makes a good employee. Once the grades are assigned, they are sorted into order.
The object of ranking, is to produce a short list of N people to interview (or offer the position to). The ranking is being done with incomplete information, it is inevitable that any scheme will have potential or real problems.
What would be ideal, is if the employer's plans before the campaign to fill the vacancy began included the desire to interview N people, and a histogram of the grading revealed an uppermost mode containing N people. This assumes that interviewing was desired. Since the distribution had a clear split, your testing, grading and averaging produced the desired result.
If the desire was to interview more people than the number that reported into that uppermost mode, the decision to be made (or postponed) is whether to interview fewer people than desired, or to interview some that are not in that uppermost mode. The decision can be postponed since you could interview this smaller group and re-evaluate after that.
If an upper mode isn't present, or is an inconvenient size, one option before interviewing even takes place, is to adjust the weighting factors to try and produce an uppermost mode of the desired size. If it is possible, is the new set of weighting factors reasonable?
If you are faced with choosing N people to interview out of a distribution containing more than N people, no method will satisfy everyone. The grades on individual tests are estimates, they are not without error. The weighting factors to combine test scores are estimates, they are not without error either. Hence, the histogram of averaged scores has some error itself. There will be some ambiguity in choosing the top N people for further consideration.
One thing that can be done, is to consider some number of the top people that is greater than N, and subject them to further testing to split the distribution or reduce the error in their assigned ranking. It's likely that further tests would need to be of a more advanced nature, since you are dealing with the best of the group. This is one advantage to setting things up so that you can administer tests to applicants, it isn't that much more work to have applicants do more advanced tests to split the top group.
There has been a distinct tendency in the recent past on the part of employers to treat the receipt of an application as a black hole, applications "fall in", but nothing comes out. I can remember this even back in the 1980's. The odd company back then sent postcards back, which I thought was much better than the usual nothing.
The big advantage of electronic submission of applications, is that it is trivial to acknowledge receipt, and the applicant receives that acknowledgement almost immediately. This is true for email and web based submission.
One thing which I would like to see happen in the jobsearch process, is the institution of feedback. Again, with electronic submission of applications, instituting feedback is trivial.
You as an employer might wonder why, but as an applicant there should be no wondering. The object from a system point of view (employers and applicants/workers), is to improve the system. If someone applies for a position, and never hears anything back; the only result is frustration. With feedback, there is the possibility for growth and improvement.
If a person receives feedback saying they weren't strong enough to tighten a bolt enough from a single potential employer, they may or may not think there is a problem. However, if they receive this same feedback from a number of different potential employers, they will probably realise that they should do something to get stronger. Or, at least they would do that if the position being applied for is one which they think they would like. (Some people will apply for positions they don't like.)
If the feedback which comes back from one employer says the applicant was too short, again they can choose to ignore it as it is only a single opinion. If they get this same feedback from a number of employers, they should come to the conclusion that they should quit trying for that kind of position, as there is little they can do about being too short.
If the applications were taken via a web site, the applicant should have the option of receiving email of this feedback, or of being given a UserID and password, so that they can login to get their feedback.
There are a number of places which collect various kinds of information in various ways, who will turn around and sell access to that information. One of the earlier types of businesses in this category are the various credit bureaus. Some of the information they collect is innocuous, and some is quite personal. Many times enough information is available at one of these sites to allow identify theft to easily take place.
These organisations are often not under any pressure to inform people that they are harbouring data about them, and they are typically neither concerned about the data accuracy or have in place any means to correct the data. Usually they do not have to freely disclose to a person, all or even any of the information they have on that person. They have to become just another paying customer, just for the opportunity to find out what information they have.
It's certainly not illegal to make use of these sites, and in some ways they are of some use in the jobsearch process to an employer; but until they take measures to ensure that they do not provide enough information to facilitate identity theft, they should be ignored.
If their information was (nearly) always correct, they might be useful in the desire to validate data. However, since Garbage In equals Garbage Out, all that seeing the same information in both an application and at a data broker means, is that the information is "likely" correct. And if the applicant's data is different, it doesn't mean that the applicant is wrong/lying. It just means they are different, and further work is required to resolve why they are different. For some employers, even if the same information is in the application and at a data broker, they might still choose further investigation, as the data is often questionable.
There are lots of kinds of data that are available from a data broker which are either not likely to be found in an application, or are illegal to find in an application. This information should not be considered during the jobsearch process. The easiest way to do this, is again to do so by computer, where the extraneous data can easily be ignored. It certainly should not be stored (cached) locally.
It would be preferred that if a organisation runs across a data broker that has a problem with providing incorrect information, or information which facilitates identity theft, that they report it.
In the past, some interviewing was done because management felt there were aspects of the job which could not be assessed properly at the application and which required a "hands-on" approach, some interviewing was done because interviewing is supposed to be done, and some interviewing was done because discrimination "needed" to be practiced.
At an interview, the applicant is in the waiting area, or is walking into the interview, and all the prejudices having to do with appearance come into play. When the applicant speaks, any prejudices having to do with speech come into play. If the applicant has a problem with eye contact, these prejudices about lying come into play.
In an environment where discriminatory practices are not permitted in hiring, eliminating the interviewing process and going directly to offers from the ranking process has a lot of merits.
At some point, you may desire hardcopy (dead tree) output. In preparation for interviewing might be a good example. Another possibility is that your organisation is accepting applications in some standard format (like something based upon XML), and has the capability to help applicants either enter application data from scratch, or to (partially) translate data from other formats into your internal format. In which case it might be nice to offer to applicants, the ability to download a copy of the data they just entered, as translated into your format, as well as something meant for hardcopy (like PDF).
Your organisation might actually have many different hardcopy formats that it uses, for different purposes. By extracting data from a database (or XML file), mixing it with a standard markup, and generating the hardcopy format (PDF or other), you provide people who need a hardcopy output, nominally identical (partial) applications to compare. In doing so, you have created a nearly level playing field: the typeface is the same, the point sizes used are the same, whitespace distribution is the same. If one of the people receiving this hardcopy output prefers larger point sizes than everyone else, that is easily accomodated.
A good example of this is the XML Resume Library format. Everyone fills in a standard type of document, with all the different kinds of data easily extracted using standard XML based format. From this standard format, you can generate: