It‘s nice o be able to share HR writing online, based on my days either hiring for my company or hiring on retainer for others. That said, the ways in which my career dovetails with HR these days is mainly via corporate web sites. At my web development agency, we get all sorts of requests from HR professionals, ranging from:
- We need a link to the HR person’s email.
- We need an online form so people can send in resumes.
- We need to completely standardize the HR process, building out forms to take in all of the candidates’ info, stored in the way that we want it.
- We need all of the above, as well as a custom system to manage all of that once we get it in-house.
A web developer’s job is often a balance of (1) doing exactly as the customer asks, and (2) recommending what might be better, based on our experience with others and with users. It’s really a balancing act, and hopefully it comes out well-balanced most of the time.
In any case, I’ll expand on the requests mentioned above, and provide at least my own take on them all.
The Sole Link
This is perhaps the simplest method of all — nothing more than displaying the HR person’s email address. This would be the equivalent of placing an ad somewhere and mentioning “If interested, send an email to HR@MyCompany.com.”
The beauty of this is in its simplicity, of course. What comes in would range wildly — email-only inquiries; emails with resumes as PDFs, Word docs, text files; those with formal cover letters, sometimes also attached to the email; those with links to web-based resumes; those with references, salary requirements; those without — and endless combinations of all of the above.
For smaller companies, this seems appropriate. While it’s so informal, it’s also a good way for HR to gauge how professional candidates are. If they send a well-written inquiry with an attached PDF resume, that alone likely sets them apart from the pack of other oddities that come in. So, although such an approach is rather low-tech, it certainly has its advantages.
For larger companies, I still think this approach has merit. But, they often want a more sophisticated system.
The Basic Form
The next “level” up is usually when the HR department wants to start formalizing things and managing files a little better. For this, they usually want a form to take in the basic candidate contact info (first name, last name, address, phone, email), and perhaps an area for a cover letter and a resume attachment.
Again, this is the basic iteration of automation, so we’re not yet tying this into a system. In other words, these inquiries still come in unattached to any particular position. They’re just a basic way to communicate in some standard way with an HR department.
Usually, the forms simply send an email to the HR rep, and the resume is stored on their web server for retrieval.
This is a bit of a step-up organizationally speaking because at least we’re now storing some info in a database, which makes some things a bit easier down the line. After all, all resumes are now stored online, hopefully in a well-organized manner.
That’s often better than physical copies crammed in a file cabinet — but not always. I still think there’s something to be said for the old, manual systems, where it’s particularly easy to browse at your leisure and mark-up individual resumes as you like.
The Complex Form
What the complex form does is to take in all of the contact information, attaches it to a job ID, and organizes all of the resume content in a standard way. While it still may allow a resume attachment, it’s going to ask for all of the previous experience to be input in separate chunks. For each previous position, it’ll ask for position name, company, dates, description, and perhaps other fields such as salary or reference info. The candidate would typically be allowed the opportunity to input several previous roles. Quite often, such a web site would request candidates to establish an account, as well.
What best separates this from the above “basic” section is searchability. Now, a HR person can run searches (provided such reporting is built into a back-end system) on candidates. Thus, good keyword-rich resumes can easily be identified without having to manually scan each submission.
In fairness, while this approach is great for HR, it’s not exactly much fun from a UX perspective. No one likes having to make an account on a potential employer wen site (and have to maintain a username and password for that.) Also, users have already presumably spent a lot of time developing standalone resumes, and now you’re asking them to dismantle / reformat them as you want them.
So, as a web developer, I’m actually a bit conflicted by such systems. On the tech side, they’re perfect cases for database application development projects. On the UX side, I find them rather annoying. No one likes re-inputting information that’s already in their slick PDF resume.
Of course, many of us have seen some of the more advanced attempts at trying to alleviate such annoyance. I’ve seen a few systems where users can upload resumes, and an AI algorithm will attempt to pre-fill a form with past experience. But, most of the ones I’ve encountered were buggy at best.
I’m not sure if there’s a great solution. Once a company grows to a certain size, it probably legitimately needs a system, based on sheer volume alone. So, candidates at significantly larger companies may have no choice but to jump through the hoops, so to speak.
I mentioned that these forms are generally tied to specific job listings. Each form that comes in is a direct application for a specific position advertised. Naturally, this allows HR to make sense of it all once it comes in.
That said, another benefit of storing all of this data in a proper database system is that, for each position needing to be filled, HR can run a search across all data in the system. This can produce some great hires from candidates who had applied in the past for different applications. (Of course, there should be a policy stated on the form that the company stores data for X weeks / months / years.)
The Complete HR System
To round out the complete possibility of functionality, HR professionals often desire ways to do everything online that formerly would have been done off-line. This would include, for example, functionality for sorting and scoring applications for a given position, and similarly scoring candidates on various desired qualities (and to be able to search on that later via an administration screen).
They would like a means to record interview results (e.g., impressions of the candidates), and perhaps even to schedule interviews. In some such systems, the emails can also be generated and stored within the system, completing the paper trail that’s often desired.
Of course, once one goes that far into such a system, one approaches what is really an entire human resources management system, which would facilitate other functionality within the HR world as well, although tied into the hiring system. (Policy manuals, and personnel records are two big examples of that.)
This brings me to a final note. Similar to how I described a bit of conflict between corporate HR’s needs and User Experience, there also exists perhaps a bit of conflict between HR’s needs and any regulatory concerns that such a system might bring up. That is to say, you may be required to take in more info that you’d like, and/or build out functionality you may not desire — thus further cluttering the UX a bit.
For example, the audit trail as I hinted at earlier for these things may seem like a bit of overkill, but I’ve had situations in which, for example, a candidate claimed to have filled out a form online, but HR never received it. In this case, it was because they had an email-only system in which candidate data was not stored in a database. In this case, the candidate had included some language within her application that set off a spam server on the corporate network. Thus, her application did not arrive, and it caused some potential legal issues. So, I suppose that’s two tricky areas — regulatory concerns and also the areas in which HR and IT can collide.
Why I Like Custom Systems Best
Generally, I like to keep such systems as clean and simple as possible — yet built in a way that’s readily extensible. That way, we’re getting clients the functionality they want, but not bogging down a system with a bunch of functionality that will never be used.
For example, let’s imaging that we allow candidates to input up to 10 previous positions, all with their own start and end dates, descriptions, and other fields. That winds up being a ton of potential fields in a database, much of which will go unused.
Then, on the reporting / administration side, it makes sorting through them much more complicated than it needs to be — at least as compared to, say, a form that allows candidates to paste in their entire resume in one large text area. Keyword / key-phrase searching one database field is a lot easier and quicker than sorting through 10.
I realize, of course, that the more specialized data is, the more robust the possibilities for searching through it. So, if you had the ability to, say, search only through a candidates previous two jobs, ignoring anything past that, that might be pretty neat. But, for most companies, such functionality might never be used or even desired.
So, I don’t personally like a lot of bloat-ware within a system. What I like is a streamlined administration panel that helps me visualize the entire HR function — e.g., a list of open positions that feeds to the web site, a list of closed positions, a list of upcoming interviews, an easy way to update information and edit things that feeds out to the web site and the rest of the system in real-time, a way to search all of my system data to look for candidates, and maybe various visual cues on this dashboard that help me know at a glance the health of the HR operation at a company.
While every HR department is functionally similar, they all seem to have their own in-house processes that vary a bit from company to company. MY dream dashboard panel may well differ from yours. And that’s a-okay!
A web developer’s role, in my view, is often best played by helping a company to automate their own internal process (informed by the experience of the developer). So, really, custom-built systems are what I find works out best — for HR as well as other areas being automated by web technology.
That’s it for now. I’ll leave you with a link that expands on my final point about 100% custom systems, which applies to HR situations for sure.
✍🏻 Jim Dee maintains his personal blog, “Hawthorne Crow,” and a web design blog, “Web Designer | Web Developer Magazine.” He also contributes to various Medium.com publications. Find him at JPDbooks.com, his Amazon Author page, Facebook, Twitter, Instagram, LinkedIn, Medium, or via email at Jim [at] ArrayWebDevelopment.com. His latest novel, CHROO, is available on Amazon.com. If you enjoy humorous literary tales, please grab a copy!